-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App specific token_auths #15410
App specific token_auths #15410
Conversation
@diosmosis applied the feedback now eg no longer removing the token_auth column. Also fixed the merge issues with 4.X and updated tests |
@tsteur looks like omnifixture might need an update? The UI tests are failing but I'm not sure why... |
…re attempting a db insert
@diosmosis updating omnifixture will likely change nearly all screenshots, due to various changes in tracked visits. Planning to do that in #15520. Will try to finish that somewhen this week. Might make more sense to update the omnifixture here afterwards to see if any test fails due to some changes here... |
@sgiehl makes sense, there was an odd error for this build but it seems unrelated to omnifixture (unless I forgot about another test). I'm in the process of fixing it. |
…-b1 migration removes unique index that is no longer used, use defaults extra file in SqlDump to get test to run on travis
Thanks for your help on this @diosmosis 💯 |
@diosmosis @tsteur I'm getting an error now in the browser when the update is triggered (after checking out 4.x-dev branch). Guess the problem might be, that I'm not logged in. Doing a
|
The annotated method was updated in matomo-org#15410 and token_auth was removed from the return array, but the note was not altered. Since no sensitive information is returned any more I believe it's enough to remove the note instead of updating it.
The annotated method was updated in #15410 and token_auth was removed from the return array, but the note was not altered. Since no sensitive information is returned any more I believe it's enough to remove the note instead of updating it.
fix #6559
user
table but hashed in a new tableuser_token_auth
piwik.token_auth
basically now storing in the session an extra token auth which is randomly generated when a user logs in. This random token is basically just like annonce
and because we need to store it in the session, it is stored in plain text in the database (base64 encoded in the session table). The plain text storage is not an issue though since it is not really a token auth but more annonce
and it only works if you also have the sessionID. And if you have the sessionId, you are authenticated anywaylogin
and the weakly hashedtoken_auth
from the cookie.CoreArchive
and this request has to be authenticated. In this caseCoreArchive
generates a token auth that is valid for say 2 days and it can use this generated token to authenticate the archiving requests.sha512
. Was going to usesha3-512
but so farsha512
seems more "proven". There is a column in the table storing the algorithm for future migrations.Todo before release