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

gvso created an issue. See original summary.

gvso’s picture

Issue summary: View changes
hussainweb’s picture

From 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.

gvso’s picture

Status: Active » Needs review
StatusFileSize
new13.62 KB
new2.45 KB

Initial 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.

hussainweb’s picture

Status: Needs review » Needs work
  1. +++ b/src/Form/SocialAuthSettingsForm.php
    @@ -78,7 +78,7 @@ class SocialAuthSettingsForm extends ConfigFormBase {
    -      $form['social_auth']['disabled_roles']['#description'] = t('No roles found.');
    +      $form['social_auth']['disabled_roles']['#description'] = $this->t('No roles found.');
    
    +++ b/src/SocialAuthUserManager.php
    @@ -57,15 +66,92 @@ class SocialAuthUserManager {
    -    $this->configFactory      = $config_factory;
    -    $this->loggerFactory      = $logger_factory;
    -    $this->eventDispatcher    = $event_dispatcher;
    -    $this->entityTypeManager  = $entity_type_manager;
    ...
    -    $this->token              = $token;
    -    $this->stringTranslation  = $string_translation;
    -    $this->transliteration    = $transliteration;
    -    $this->languageManager    = $language_manager;
    

    This 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.

  2. +++ b/src/SocialAuthUserManager.php
    @@ -57,15 +66,92 @@ class SocialAuthUserManager {
    +    if ($drupal_user) {
    +      // If user could be logged in.
    +      if ($this->loginUser($drupal_user)) {
    +        return $this->redirect('user.page');
    +      }
    +    }
    

    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.

gvso’s picture

Thanks @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"

hussainweb’s picture

I 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.

gvso’s picture

Status: Needs work » Needs review
StatusFileSize
new12.11 KB

Here's the new patch

gvso’s picture

StatusFileSize
new2.63 KB
hussainweb’s picture

Status: Needs review » Reviewed & tested by the community

I see all concerns are resolved. Thank you!

denutkarsh’s picture

RTBC+1 We still need to update other implementers, but i don't think it's part of this issue.

denutkarsh’s picture

@gvso I think after this issue is fixed, solving this issue would become a lot easy. #2821853: Provide Social Auth settings: functionality

denutkarsh’s picture

Status: Reviewed & tested by the community » Needs work

IMHO We could also set $id default value to NULL. Since $id is only required when setProfilePic() .

denutkarsh’s picture

Status: Needs work » Needs review
StatusFileSize
new12.09 KB

I was thinking of something like this.

gvso’s picture

Status: Needs review » Reviewed & tested by the community

Thanks @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.

  • gvso committed 1ad56b5 on 8.x-1.x
    Issue #2848144 by gvso, denutkarsh, hussainweb: Create authenticate...
gvso’s picture

Status: Reviewed & tested by the community » Fixed

Thanks everyone!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.