Password expires (Password Reset Days) does not work

I have the same problem. But I have not tested yet the patch from this issue: https://www.drupal.org/node/2867089
It also concerns expiry so maybe it could fix the problem.

There is a bug in the _password_policy_user_profile_form_submit method. Upon submition of the user profile form, the code tries to get the uid from the form_state. This returns null, so the condition to reset the field_last_password_reset and field_password_expiration fields is never met.

Edit: when an admin user edits an other users password, the current pass field is not set, so the condition will also not hold. Also in this case, the
storage user object is not set. So it's better to fetch the actual account being used in the form, from the build info.

Don't have time to cook up a path, but code should be:

function _password_policy_user_profile_form_submit(array &$form, FormStateInterface $form_state) {
  $new_pass = $form_state->getValue('pass');
  $user = $form_state->getFormObject()->getEntity();

  // Update if the new password fields is filled out.
  if ($user->id() && $new_pass) {
    $date = date('Y-m-d\TH:i:s');
    /** @var \Drupal\user\Entity\User $user */
    $user->set('field_last_password_reset', $date);
    $user->set('field_password_expiration', '0');
    $user->save();
  }
}

Here's a patch for #5

This patch did not fix the error, the password resets every 24hrs irrespective of Password Reset Days set to 60.

niteshchawathe which version are you using ?

If it's 3.0.0-alpha4, it appears that an equivalent fix to the patch in #6 has been incorporated in that version.

What you may be experiencing is this issue: https://www.drupal.org/project/password_policy/issues/2860671

If you're using version 3.0.0-alpha4 try patch 2860671-password-policy-cron-fix-2.patch provided in the above issue.

patch#6 is not working and getting the below error

$ patch -p0 -b < password_policy-expire-password-reset-2917622-6.patch
can't find file to patch at input line 8
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: modules/contrib/password_policy/password_policy.module
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|--- modules/contrib/password_policy/password_policy.module (date 1510662267000)
|+++ modules/contrib/password_policy/password_policy.module (revision )
--------------------------
File to patch: password_policy.module
patching file password_policy.module
Hunk #1 FAILED at 292.
1 out of 1 hunk FAILED -- saving rejects to file password_policy.module.rej

Hello,

I made some changes for https://www.drupal.org/files/issues/2860671-password-policy-cron-fix-2.p... and created a new patch for it https://www.drupal.org/files/issues/cron_expire_date_format-2860671-7.patch.
It solve the issue with wrong Cron behavior and date format.

imen, patch #9 is working.

The patch in #19 works for me but does not apply after work done in https://www.drupal.org/project/password_policy/issues/2860671. It seems the last chunk of the diff was included in that issue. I've removed it from the patch, this revision applies with composer.

the patch in #20 seems to resolve the issue for me. in our case, there was still a password reset that had to occur due to the age of the password, but afterwards it no longer is constantly requiring it.

In my situation, 8.x-3.0-Alpha4 with the #20 patch and the patch from #2860671: Inconsistent date format and timezone usage leads to infinite password resets. fixed the password always being expired problem.

HOWEVER, resetting the password via the user edit form always resulted in the password being mangled somehow. E.g. you could never login with the password you entered. I had to reset the account password with the Drush pwd command. Triple checked everything was being entered correctly, saw that the password hashes were different between a form reset and a Drush reset.

Removing this patch fixed the password reset problem and the always expired problem was still fixed.

Could consistently reproduce by:

1. Logging in as an admin user (not #1)
2. Going to the user//edit page
3. Resetting the password with the edit form
4. Logging off the user /user/logout
5. And trying to log back in /user/login
6. Password used in #3 never worked
7. Reset with a drush upwd --password=xxxx
8. Login worked

Any updates on this? I've tried patch #20 but it hasn't made any difference. Currently this module is impossible to use as I have to reset my password constantly.

Thanks.

@steveedson, I guess you could use the 8.x-3.0-DEV version which seems to have these fixes...
or apply a patches from a few separate issues which seem to solve it for me (the password expire issue, and another patch regarding the policy_roles which i think caused an issue/error for me: so think patches from these 2 sources rolled up into 1 patch... https://www.drupal.org/project/password_policy/issues/2863169 https://www.drupal.org/project/password_policy/issues/2902597).
Note: I'm using password_policy's 8.x-3.0-alpha4 version.
The git patch file is attached.

I'm using 8.x-3.0-alpha4 with the patch in #25 as well as the patch on https://www.drupal.org/project/password_policy/issues/2771129#comment-13... and everything's working fine.

I'm not getting any errors about a password being expired before the correct time, and as a user I can change my password and re-log in successfully.

Setting to "Needs review" to run tests on #25.

Edit: Apparently setting to "Needs review" doesn't trigger tests for the most recent patch in prior comments to run. So I manually ran the tests for #25.

#25 doesn't apply.

Neither security nor data loss bug, so not blocking beta.

Was something finalized for this issue? It looks as if the last patch is failing to even apply

From the conversation, it almost seems like people fixed their issue with a patch and just moved on. This still seems to be an issue in the last version.

If you compare the code in patch #25 to alpha5, it appears the fix has been committed.

According to previous comment.