Evict user from auth-cache on reset password #3407
Conversation
idanovo
requested review from
nopcoder,
ortz,
johnnyaug,
arielshaqed,
guy-har and
shimi9276
There was a problem hiding this comment.
This seems like an easy way to resolve many of our issues when changing user passwords. I think it will be OK: after logging in the user gets a JWT and authenticates with it. So the password is never really used again for a significant period of time!
(However other auth information for the user, such as group memberships and groups and their policies, are re-used on each call and must remain cached!)
Co-authored-by: arielshaqed <ariels@treeverse.io>
| This is why the simpler solution here might be just to not use auth cache for email-password authentication. | ||
| This way, we still won't need to authenticate when a user uses API calls that use access-key and secret for authentication and won't need to do the effort of evicting the user auth from all the auth cache instances. | ||
| In case we decide to go with this solution, we have to enable email/password authentication only through the UI. | ||
| Otherwise, user might try to use email/password authentication with our Python/Java client and won't have their credentials cached. |
There was a problem hiding this comment.
And why is that so bad?
We already state in the docs that email+password should be used only for the UI.
If the user decides to use them for the API, an extra DB call will happen for every request - I think it will not cause a bottleneck. If it does in the future - we can solve it.
There was a problem hiding this comment.
Think of a Spark app reading from multiple workers. One user in one org makes a mistake, and all users get rate limited.
A shared auth server will have this problem in trumps, even more so if it fails to protect its DB access.
Co-authored-by: johnnyaug <yoni.augarten@treeverse.io>
idanovo
added
the
exclude-changelog
idanovo
changed the title
…4-evict-user-from-auth-cache-on-reset-password
No description provided.