Do not force 'social auth' based user to change password

Please review the patch.
Thanks!

Uploading a patch here for an older version of the module. This can be ignored ignored.

@ankithashetty, what is the current behaviour when change_pwd_page module is not enabled, but we have password_policy + social_auth only?

Please add helper comment on before line
$valid_list = array_diff($valid_list, $social_auth_user_ids);

@marcelovani, the issue exists even w/o change_pwd_page. It's observed when a user is logged in via social_auth and has password_policy set.

Let me rewrite the scenario again w/o change_pwd_page.
Second scenario:
We have a password_policy module + social_auth module (w/o change_pwd_page module)

• User Signed in via social login - Google for ex via social_auth
• Due to the password_policy module & its config, password expiration gets enabled for the user after a few days. (based on the expiration duration set by admin)
• The User tries to sign up again via social login. He is logged in but gets redirected to the user/%/edit page (w/o the password field)
• The user will be blocked again.

Addressed the comments made in #6 in the MR:https://git.drupalcode.org/project/password_policy/-/merge_requests/61

CC: @rashid_786

Hmm... I don't love that we are adding special cases for specific modules in different spots. If we are going to check for certain modules, then it would be nice to put them all together in one check, e.g.

function usesExternalLogin() {
  // Check all the different modules here and return true or false.
}

This would require refactoring the other logic too.

But, it's unclear how this can work if we are grabbing data from these different systems.

IMO this needs deeper thought at the architectural level. I didn't build this module though... was just added as a co-maintainer.

I would like more feedback from those more familiar with the architecture.

Expanding on Kristen's idea to keep this functionality in one place rather than special cases popping up for each module, I believe a custom hook would be more appropriate. This would allow developers to override the list of users that are set to have their passwords expire by calling a hook like HOOK_password_policy_expired_list_alter($valid_list), doing their own checks on a per user ID basis, and then returning the $valid_list of users to have their passwords expire.

This would let any third party module take care of special cases, whether that means modules such as externalauth decide to handle it natively, or an in-shop developer creates a private custom module to handle their specific use case for their organization.

Setting status to needs review so that the maintainer can decide if they still need more info

I like the idea of some sort of hook(s) where other modules could opt-out or opt-in as needed.

We could then have our own submodules if we did want to support these additional services (or the other service modules could integrate).

Then developers could decide if they needed the submodules or not. This would keep the main/core code cleaner and provide better performance and easier maintenance.

I'd still like others to chime in on this though so I'm moving back to postponed for now.