geoffrey edited this page Dec 19, 2011 · 4 revisions
Clone this wiki locally

Quick thoughs about user management:

Base problem

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.

Local user persistence

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:

  1. 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
  2. use a SuccessHandler to achieve the exact same result
  3. 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.