'Force password change on next login' causing infinite loop

My guess is that their UID is in the {password_policy_force_change} table twice. After trying to change that user's password twice, could you attach the database table that you have? Use query SELECT * FROM password_policy_force_change WHERE uid=<uid>\G

I am having the same issue, the user is not in the password_policy_force_change twice. I have checked. Although my scenario is different. users were being constantly blocked so I took one and updated the last password_policy_history entry to have the created time to now. I could then unblock them but now whenever that user updates the password, it will say that it updated the password but then any attempt to leave that page will result in the error 'Your password has expired. You must change your password to proceed on the site'.
When I check the DB the force_change is not on so I assuming this has something to do with how the history table is checking/updating this information.

Actually looking at the account array the 'force_password_change' seems to set to '1' all the time.

@pandabrand: So you're seeing the database doesn't appear to be setting this, but rather code?

I don't have any new information but I can confirm that I've experienced this issue exactly as brantwynn described in the summary.

Same here, had to stop using it obviously... a pitty

I had the same issue. I think it's because of the hard-coded constraint that the new password must be different from the current password in password_policy_user_update:

  // If the current user is being forced to change their password and is
  // changing their password, toggle the force_change field off.
  if (isset($account->force_password_change) && $account->force_password_change && ($account->pass != $account->original->pass) && $user->uid == $account->uid) {

Which would explain why it worked for one of my users, but not the other one. The restriction kind of makes sense because we are forcing the user to change their password, but in my case the only reason we are forcing the change is to enforce more secure passwords. If the user's old password is already secure then they should be able to reuse it.

The enforcement should be optional configuration.

Also I suspect the Force password change on next login checkbox should probably be a hidden field since ticking or unticking the checkbox has absolutely no effect whether the passwords are the same or not.

I think it's common behavior that a forced password change should require users to create a new password.

On the other hand, I suppose we could remove the check for a different password and rely on the history constraint to kick-in if you don't want the user to repeat a password. That may solve both of these problems.

#9: password_policy-force_change_loop-1623138-9.patch queued for re-testing.

@erikweeb
Please comment out/remove the following line from your patch:

+ dsm('Change me!');

I'm having this problem. Does the latest version 7.x-1.3 fix this problem or do I need the patch.

@jh81 - I haven't had a chance to fix the test problems and haven't received other patches, so there's nothing completed that has been included in the module yet.

(Changing priority back to major. This does not render the entire module unusable, just one feature.)

This might have been fixed be partially solved by #1570122: Expired passwords stuck.

Could I get some new feedback on this issue?

I've recently run into this issue with version 1.4 so the issue above doesn't seem to have fixed it.

I can actually replicate this by inserting a (uid, 1) pair into password_policy_force_change then logging in with that user, upon logging in you are presented with the " Your password has expired. You must change your password to proceed on the site." message and changing the password does not result in this being cleared. Eventually I get a page with the entire form duplicated on the page, I am only able to get rid of the message by updating the db table.

The issue is that $account in hook_user_update for some reason has force_password_change always set to 0.

EDIT: Confirmed by adding

$account = user_load($account->uid);

Just above the first conditional in hook_user_update, this stopped the infinite "expiration"

This is a similar problem to what we're trying to address here - #2008282: user_load in hook_init is not performant

Maybe we should be looking at a more general way to ensure our properties are added as early as possible.

Yeah or could we not directly query the db in hook_user_update for now as this is a pretty serious bug, I currently can't find what's causing it but the only way to fix it is manually altering the force_change table.

The cause of this issue is from hook_user_login when a user does not have an entry in the password_policy_history table. The user logs in and since they have not changed their password since the policy was enabled they get force_change set to 1. The user then attempts to update their password and because of the issues explained above the user is never able to get out of the infinite loop. Any db changes directly to the force_change table get overwritten upon next login.

EDIT: Furthermore, the password changes aren't even being saved into the history table. Debugging in the submit handler is showing it's not even running

EDIT 2: The save issue was caused by a pesky custom submit handler doing a drupal_goto that I was unaware of

Changing to version 1.4 as --dev is behind stable...

Here's a patch that fixes the user_update issue in any case.

I can confirm that the same patch submitted by acbramley applies cleanly to 7.x-1.5, but it would be great if the maintainers of Password Policy would apply the patch as a bug fix for the next release.

I'm currently still having this issue in 7.x-1.5. The patch in #25 doesn't seem to resolve the issue and the "loop" is still occurring.

@dan_lennox, can you please provide details of how to reproduce this issue from a fresh install using the patch in #25

My fix did not take into account that when a user is blocked by cron (i.e the password_policy_expiration table has a blocked timestamp and the password_policy_force_change table has force_change = 0) the $account->force_change property might be 0, but it is set to 1 on hook_user_load if the user has an expired password.

This means if the user hits the site when they are expired by cron, they are redirected to the user edit page subsequently when they save the new password the following check fails in hook_user_update() and the expiration is never deleted from the db.

As I've said above, the main issue here is that the $account object does not have the correct value for the force_change_password property when the hook initiates. Strangely enough $account->original->force_change_password seems to be correct. Patch attached. I've tested with expiring users and forcing them to change passwords and both have correctly work and been able to be unblocked by changing the password :)

The patch in #29 works for me.

Thanks!

Patch #29 seems to have fixed the looping issue for me, but I still get the duplicate page/form displayed as described in the original description.

Patch #29 solved it for me as well with Password Policy 7.x-1.5.

Looks like we have consensus!