The Auth package is based on a local users table, so if no entry in that table exists, in needs to be created.
The reason why a login is asked is that there is no way to determine that my facebook login and by github login are actually the same user. By the login the new OAuth provider is linked to the existing account. So after I've done that, I can login via facebook or github, and the system knows I'm local user "Harro".
Technically, if you don't use multiple providers, and you don't expose your local users at all (no username/password login), you could get away with generating a dummy local user after a match on nickname.
You can do that in your controller when you get "register" back, and then call link_provider() to link the created dummy user to the provider uuid used to login with.
With this process, for the first time, a new user has to register in classical way. Then we lose the "two click" sign in.
From my point:
A new user ask to sign in with twitter and "francois_maujean" as screen_name,
We check if we already have credentials for him in authentications table, if yes we are done.
If not, we check if 'francois_maujean" exists as username, if not, we create this user.
If it exists, we inform the user his username already exists and offer him to register in the classical way. We can also inform him that if it's his account he can login with the social account he used when he has been logged in for the first time.
If a user is logged in, we link that new social account to his local account.
As far as I saw, that's the process I encountered on most websites I signed in with my social account.
Don't get me wrong, it is not my intention to argue with you, just trying to make things better.
if there is an authenticated local user, the login is joined, and you're done. If there is no authenticated local user, you get "register" back.
You can decide in your applications auth controller how to handle that.
In our applications we support multiple OAuth logins for a single local user, so we offer the option to either register for a new local account, or to login using an existing local account. After success the OAuth login is joined to that local account.
If you don't want to provide the second option, and want a one-to-one between a local account and OAuth login, only present the registration option. Or first check for a local account, and if it doesn't exist create one and do a force_login() on that account, instead of prompting for registration.
It's entirely up to you, Auth doesn't force you to use any specific method. But if you do that you have to provide the generated local account with a dummy password, which means local login will never work (as the user doesn't know the generated password).
This might be ok for your applications, it isn't for ours.
If this process was handled inside the Auth Opauth class, developers would not have this choice of implementation anymore. Which is why it isn't implemented in there.
Your suggestion doesn't make it better, it restricts developers in wanting to do it differently than you.
Donate
