Problem:

I have a client that uses the Forced Password Change module. Occasionally I need to access the User 1 account on production (which I do via drush uli. However, I often find that I get stuck in a loop requiring me to change their root user password. This is non-ideal, as then I need to share temporary passwords with the client that I created.

This could happen in other situations, such as developers/technical support need to use Drush to login to a user's account to debug an issue and may not want to be forced to change someone's password.

To Reproduce:

  1. Install forced_password_change.
  2. Set "Check for pending password change" to be "on every page load."
  3. Enable password expiration. Set all authenticated users to have a 1 hour expiration.
  4. In one hour, log-out of the Drupal UID 1 account and attempt to do a one-time login. Use command drush uli --browser=0. Copy and paste the link into a browser.
  5. Do not reset the password. Try to navigate to another page and you will be redirected back to the user/1/edit page, prompting you to change the password.

Proposed Solutions:

  1. Create functionality that drush uli logins bypass the force_password_change.module functionality. This way third-party developers are not forced to change user passwords for accounts that may not be theirs.
  2. Create a Drush/FPC admin ui function that allows administrators to reset the clock on a user's last password reset. That way if an administrator must access an account that is triggering a password reset, the admin can change the clock to one day until reset, vs resetting the password themselves. While this strikes me as a little less ideal than the drush uli-bypass method described above, I suspect this would be easier to code.

Thank you for considering this feature request!

Comments

kmonty created an issue. See original summary.

Jaypan’s picture

Jaypan CreditAttribution: Jaypan at Jaypan commented
Status: Active » Postponed (maintainer needs more info)

Can you please provide steps to recreate the issue?

kmonty’s picture

kmonty
Location San Francisco, CA
CreditAttribution: kmonty as a volunteer commented
Issue summary: View changes

I updated the issue summary.

Here are the steps again:

  1. Install forced_password_change.
  2. Set "Check for pending password change" to be "on every page load."
  3. Enable password expiration. Set all authenticated users to have a 1 hour expiration.
  4. In one hour, log-out of the Drupal UID 1 account and attempt to do a one-time login. Use command drush uli --browser=0. Copy and paste the link into a browser.
  5. Do not reset the password. Try to navigate to another page and you will be redirected back to the user/1/edit page, prompting you to change the password.
kmonty’s picture

kmonty
Location San Francisco, CA
CreditAttribution: kmonty as a volunteer commented
Status: Postponed (maintainer needs more info) » Active
Jaypan’s picture

Jaypan CreditAttribution: Jaypan at Jaypan commented
Status: Active » Closed (won't fix)

I see.

To be honest, I don't see a way around this. The Drush ULI simply generates a Drupal one-time login link, same as when recovering a user's password. This allows a login without having to actually log in. Drupal has no knowledge of the fact that the one time login link was generated through Drush. It simply has a link that was generated using the Drupal API to allow a login without username and password.

So what needs to be done on the technical side is to temporarily not force a password change for a given user. And there is already a way to do this:

1) Create a new role - call it something like 'Password Non-expiry'
2) Go to the Force Password Change admin page, and in the role table, drag the row to the top. Ensure that the time for the role is set to zero.
3) Assign the role to the user that you will be generating the one time login link for.
4) After the user has finished using the one-time login link, remove that role from the user.

kmonty’s picture

kmonty
Location San Francisco, CA
CreditAttribution: kmonty as a volunteer commented
Status: Closed (won't fix) » Active

I tried those steps and they actually won't work on our setup. The way it is configured is all Authenticated Users have a password expiry. This included UID1, as it's an auth user. Even when assigning it a role that doesn't require password resets, the Auth User setting supersedes it.

I believe we can do a workaround as I outlined in #2. I see the technical limitations of #1. I'll submit a patch when I can.

Jaypan’s picture

Jaypan CreditAttribution: Jaypan at Jaypan commented

Even when assigning it a role that doesn't require password resets, the Auth User setting supersedes it.

Did you drag the role without a password expiry to the top of the list?

If so, then that's a bug. The highest role in the list should take priority. I'll need to fix that if it's not working.

Jaypan’s picture

Jaypan CreditAttribution: Jaypan at Jaypan commented
Status: Active » Closed (works as designed)

I just confirmed that this is a bug. I've fixed the bug, and pushed it to 8.x-1.x. I need to write automated tests for the bug, and once I do, I'll release a new version. I may be able to do it in the next few hours.

Once that has been released, you can go through the steps I outlined in #5 to handle your issue.

kmonty’s picture

kmonty
Location San Francisco, CA
CreditAttribution: kmonty as a volunteer commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Closed (works as designed) » Patch (to be ported)

I am on the 7.x branch so I cannot test it. Leaving this open, as the 8.x patch still needs to be backported.

That said, glad we found a bug in this process! But still doesn't completely solve my issue. I'm going to continue writing the drush patch. I believe it's a valuable feature that doesn't force admins to hack around the problem (in fact, even when fixing the bug, I cannot re-arrange the order as I still get trapped in the cycle, so the module isn't even fully working as designed).

Jaypan’s picture

Jaypan CreditAttribution: Jaypan at Jaypan commented
Status: Patch (to be ported) » Closed (works as designed)

I'm closing this, as there is another way around your issue. If you use the Masquerade module, you can log into other user's accounts. The module is now set up to not require masquerading users to reset the password.

Note that this new functionality is only part of -dev at the moment, but will be part of the next release whenever it happens.