Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.suppose for a user, Password expiraiton is checked, and last password reset is less than current date.
If I log in to user account via a password reset link... the message shows " Your password has expired, please update it"
if I switch to another browser and try to log in with the new password. Still the message "Your password has expired, please update it" shows.
Last password reset field is not updated or is there anything else going wrong?
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | password_policy-2856878-expired-on-reset.patch | 804 bytes | Steven Jones |
| |||
| #13 | password_expired-2856878-13.patch | 1001 bytes | gargsuchi |
| |||
| #5 | password_expired-2856878-5.patch | 812 bytes | LiamPower |
| #4 | password_expired-2856878-4.patch | 804 bytes | JayKandari |
Comments
Comment #2
JayKandariWhen user updates their password thru password reset link, it never clears
if ($uid && $current_pass && $new_pass) {in_password_policy_user_profile_form_submit()method. I think Instead of checking for both passwords, only the new password should be checked.This will update the field_password_expiration & field_last_password_reset with recent data.
Added a patch against this. Kindly review.
Comment #4
JayKandariAdded a condition to check if password is saved using reset link.
Comment #5
LiamPower CreditAttribution: LiamPower as a volunteer commentedI've noticed that the $uid isn't passed through on the password reset form when submitting as the user. This would cause loading the user to fail and the values would still not be updated.
I have added a patch to add the check for $uid, but there still needs to be the $uid to be passed through in the form submission as it still isn't currently updating field_last_password_reset or field_password_expiration.
Comment #6
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commentedI'm getting this during pre-live testing today :-}
Will try the patch here and look into it.
Additional info:
Submitting a password reset does give the message that the changes were saved - which is a bit misleading.
Going 'back to site' was trying to load /user/1 (not sure why, as I was testing with a lower-level user/3) and this produced infinite redirect loops and an unhappy browser and 50 messages in the log.
Most recent patch does not solve the issue yet. But did apply clean...
Comment #7
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commentedI found that http://cgit.drupalcode.org/password_policy/commit/?h=8.x-3.x&id=8ee51e4e... seems to have fixed it!
So a fix was made #2852312: Password expiration not set to false on update
but it's not in 8.x-3.0-alpha3.
This is critical - makes the normal use case un-usable - so it would be good to get another tagged release out with this.
Comment #8
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commentedSorry - unless I am TOTALLY misguided and mis-interpreted this issue for that one. ... I'm not sure I grabbed the right issue here now...
Comment #9
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commentedRIghty, it's both issues.
#2852312: Password expiration not set to false on update is still in dev, and resolves half the problem.
But reported here, the email password reset process failed with the same sort of symptom.
The patch #5 applies to -dev good, and looked like it fixed that second situation... But on re-testing manually I found there may have been some session/cookies that made it look like it was working... Still WIP I guess. I'm trying to see what can be done. Testing this email cycle is a pain...
I wonder if drush ULI is the same method...
Comment #10
LiamPower CreditAttribution: LiamPower at Reading Room commentedI believe this still needs work?
Comment #11
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commentedMost likely "needs work" yeah. ... the cycle of steps required to test a success or replicate a fail was so long I think I got misguided.
Apologies for the stream-of-consciousness style of bug reporting previously. I'd got in too deep trying to untangle/replicate a reported issue, and was tripping over my own conclusions.
Patch so far is an *improvement* however. It did solve some of the problem :]
Comment #12
dman CreditAttribution: dman as a volunteer and at Sparks Interactive commented"related" issue #2884567: UX: It's possible to enter a frustrating loop if resetting an expired password. was clouding things for me when attempting to test the solution here.
Comment #13
gargsuchi CreditAttribution: gargsuchi at Salsa Digital for Department of Premier and Cabinet - Victoria, Australia commentedRerolled the patch against the latest dev and also added in a comment.
Steps for testing:
Comment #14
Steven Jones CreditAttribution: Steven Jones as a volunteer commentedSetting to the correct status.
Comment #15
Steven Jones CreditAttribution: Steven Jones as a volunteer commentedAh sorry, I see that you feel like this patch still needs work. Anywho, the patch in #13 works for our use case and allows people to change their passwords on the password reset page and not end up in a loop.
Setting to needs work as per #10.
Comment #16
Steven Jones CreditAttribution: Steven Jones as a volunteer commentedActually the patch in #2881213: Fails updating password reset date and flag password was reset on resetting password by using one time login link was the superior implementation for this fix. Checking
$form_statemeans that the token is actually checked for validity, and not simply for existence.Here's the patch from #2881213-2: Fails updating password reset date and flag password was reset on resetting password by using one time login link re-rolled for latest dev.
I think this also can be reviewed.
Comment #17
daggerhart CreditAttribution: daggerhart at Hook 42 commentedPatch applies cleanly and fixes this specific issue.
Let's credit @alunyov if possible since it was his patch that was copied over to this issue.
Comment #19
nerdsteinAdding alunyov to this issue.
I've reviewed #16 and it looks good. And, thanks to everyone who helped with this :)
Comment #21
nerdstein