Allow contrib modules to alter the redirect and ignored routes

Thank you for the patch.

Wouldn't the "change password page" module have it's own configuration? Why would we need to change the schema of this module? I'm hesitant to do so, as the current configuration form changes the current schema values.

I would also recommend some checks for this module. e.g. "if( module_enabled('change_pwd_page')) {"

I'm moving back to "needs work"

Having just encountered this on a development site, it appears 3 years after it was first brought up, it appears there's been no movement on this. The people that I'm working for find the default Drupal change password form on the user edit page too confusing. They even find having to enter their current password to change their email address confusing. So, I'm required to have the change password on a separate page.

Not being able to set a configuration value for the location of the password change form (defaulted to user/###/edit) means that I cannot use this module to increase the password security on the site. This is very frustrating for me, and I'm sure many others out there. This patch seems like it would do what needs to be done, why not add it, or something that does the same thing, to the module?

I do agree with @nikunjkotecha. I faced the same issue on a project and ended up with the same conclusion. I searched for existing issue before creating mine and found this one.

I would actually go further and make the list of $ignore_route an independent config. I can see the module has "recently" been updated to add jsonapi routes to the list. I suspect there is more use case we actually want to allow some urls to be accessed despite an expired password.

In short, I would make $ignore_route and $url (the one we redirect to) configs.

#patch 8 following the workflow of patch #3 for version: 3.0-beta1

Adding patch #9 following the workflow for stable release 3.0.0 version

Patch #9 throws:
Warning: Cannot use a scalar value as an array in Drupal\password_policy\EventSubscriber\PasswordPolicyEventSubscriber->checkForUserPasswordExpiration() (line 127 of /mnt/www/html/alshaya505uat/docroot/modules/contrib/password_policy/src/EventSubscriber/PasswordPolicyEventSubscriber.php)

This patch fixes it. Supports password_policy 3.0.0.

Re-rolling patch for Password Policy 4.x

This patch works well for changing the redirect url.

But I agree that the $ignore_routes should be configurable or alterable with a hook,

Although it's easy to have a configurable redirect destination replace the hardcoded redirect to entity.user.edit_form, I am leaning towards #4's reasoning.

As far as password_policy (and any other module) is concerned, the password edit fields are in entity.user.edit_form as implemented in core. The change_pwd_page module replaced that location, so change_pwd_page should be in-charge of redirecting everyone to this new location, not the other way around where everyone has to adapt to change_pwd_page.

From a dependency perspective, this approach would have both modules not know of each other. password_policy only knows to send the user to entity.user.edit_form, while change_pwd_page only knows that it needs to redirect requests from entity.user.edit_form to its new page. This is kinda like how change_pwd_page is currently replacing user.reset from core's original path to its own. Maybe something similar can be done for entity.user.edit_form. But this work would have to be on change_pwd_page's side.

My 2c.

I have a custom module that creates its own page/form for changing the password similar to change_pwd_page, the entity.user.edit_form is still a valid path for editing other user fields. There is no way for me to know the intent of why a user ends up on entity.user.edit_form without checking for an expired password when on the entity.user.edit_form route a second time and then issuing a second redirect to my change password form.

It feels like it would be a lot easier if both the redirect route and the routes excluded from redirection were either configurable settings or alterable in a hook or event subscriber.

If they were alterable, we wouldn't need to change the schema and any module could define its own redirect route an exclusion routes for not checking for expired passwords.

MR!91 adds an alter hook. hook_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes); This allows contrib modules to change these two variables.

in my use case I am using it like this

/**
 * Implements hook_password_policy_routes_alter()
 */
function MYMODULE_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  // Our custom change password form.
  $change_password_route = 'entity.user.edit_form.change_password';

  // Ignore commerce checkout routes.
  $ignored_routes = array_merge($ignored_routes, [
    'commerce_checkout.form',
    'commerce_checkout.checkout',
  ]);
}

It also appears that with change_pwd_page, #2933747: Integration with password_policy added some changes that rely on the patch here in #12.

If the approach I propose here is accepted, that commit could be reverted and all that change_pwd_page would need to do is implement the hook as follows

/**
 * Implements hook_password_policy_routes_alter()
 */
function change_pwd_page_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  $change_password_route = 'change_pwd_page.change_password_form';
}

Instead of introducing all those update hooks that their solution added. It seems like a much simpler approach to me.

Re-rolling patch for 4.0.2+