Problem/Motivation
As seen in Social Auth Twitter and Social Auth Google, the callback methods look pretty similar, and it seems that it would be a kind of "standard". Therefore, it would be good if we can implement a 'authenticateUser' method to abstract this functionality from implementers.
Proposed resolution
Create the method which should receive the arguments for plugin id, user's email, user's name, user's id, and picture's url (optional)
API changes
Implementers would probably use this method instead of implementing their own authentication functionality.
Comments
Comment #2
gvsoComment #3
hussainwebFrom experience with #2847914: Attempts to create an user even if it already exists, I'd suggest to differentiate different results of this new method. There might be a case when the user is present but cannot login (if the user is blocked, for example). And then there is the regular case of the user does not exist. The related issue exists because we do not differentiate between these two scenarios. The calling code should know why exactly the login failed and then if it was because of missing user, only then attempt to create the user.
Alternatively, this entire flow seems common among all such modules. We could have a method called something like authenticateOrCreateUser() that does the entire job.
Comment #4
gvsoInitial patch for this issue created. Further testing and suggestions are welcome. I also attached a patch for Social Auth Google to test Social Auth new authenticate method.
Comment #5
hussainwebThis seems to be entirely unrelated to the issue. It is not too much of a change but it is still better in another issue for code cleanup.
This preserves the existing bug in social_auth_google module I filed - #2847914: Attempts to create an user even if it already exists. Please see the patch there.
With the new isApprovalRequired message, the user will get a proper message the first time they login and that's great. But when they try to login next time and admin has still not approved them, then the issue remains. This code flow will try to create the user again instead of giving an error message about it.
Comment #6
gvsoThanks @hussainweb. For suggestiong #2, any ideas on how to check that? We can check if the user is active using the isActive method, but the user can be inactive because his account might have been canceled (no necessarily that it wasn't approved yet).
The only thing I can think of is returning a message like "Your account was canceled or isn't approved yet"
Comment #7
hussainwebI think that message is accurate and helpful. The user can then contact the administrator to fix the issue.
I wouldn't suggest to make a check on isActive or any other conditions. Once it enters the outer if-block, we know that the user is there. Even if the user cannot login under any circumstances, there is no point to try to create the user again at all. If you check my patch in #2847914: Attempts to create an user even if it already exists, it ensures that we exit the method under all circumstances. That is, if the user is already present, we don't try to create it again.
Comment #8
gvsoHere's the new patch
Comment #9
gvsoComment #10
hussainwebI see all concerns are resolved. Thank you!
Comment #11
denutkarsh commentedRTBC+1 We still need to update other implementers, but i don't think it's part of this issue.
Comment #12
denutkarsh commented@gvso I think after this issue is fixed, solving this issue would become a lot easy. #2821853: Provide Social Auth settings: functionality
Comment #13
denutkarsh commentedIMHO We could also set $id default value to NULL. Since $id is only required when setProfilePic() .
Comment #14
denutkarsh commentedI was thinking of something like this.
Comment #15
gvsoThanks @denutkarsh!
But I think $id shouldn't be optional. When creating an username, $id and $pluginId are used to generate a unique filename for the profile picture.
Changing back to RTBC for patch in #9
Edit: After talking to denutkarsh, I realized $id wouldn't be necessary if $picture_url is not set, so patch in #14 is better.
Comment #17
gvsoThanks everyone!