-
Notifications
You must be signed in to change notification settings - Fork 9
Home
Quick thoughs about user management:
As pointed by Stof, the OAuth provider might not have a way to retrieve a user's username. In that case, what should we do? We can consider the authentification process is over as soon as we have the access token, thus returning an authenticated token based on it and set the username either to the access token or to some predefined constant (the DaoAuthenticationProvider
uses NONE_PROVIDED
as a temporary value for example).
Either way, we need an easy way for the developpers to hook into the authentication process and be able to fetch the user's data, possibly updating the security token. I'm not sure yet what's the best way to achieve that, but I feel the UserProvider
is the key here again.
So right now, the bundled UserProvider
just creates instances of Knp\OAuthBundle\Security\Core\User\OAuthUser
, but this is sufficient only if you don't plan on using ACLs or do advanced stuff with your users.
So the question is: what's the best way to support local user persistance? The problem is that if you use a UserProvider
that — for example — fetches user from the database, when a non-existent user logs in, the UserProvider
won't find it in the database, and thus will consider the authentification attempt a failure.
I have 3 leads to fix that right now:
- use the
SecurityEvent::INTERACTIVE_LOGIN
event to hook up on the auth process and create the users on the fly and reinject the correct user into the security token - use a
SuccessHandler
to achieve the exact same result - bundle the user creation in the
UserProvider
Actually, I think only the 3rd option is viable, since the event and the success handler happen too late in the process, but I'm not 100% sure yet. I also don't like the fact that a UserProvider
creates users, but I'm not sure we have a better solution here.