In 7.79, because of https://www.drupal.org/node/3205476, now is not possible to alter user_pass_reset form. Specifically, in the module prlp we not able to login properly after a password reset.
Here is the issue: https://www.drupal.org/project/prlp/issues/3208362
In a plain Drupal 7.79, install the latest prlp module version, reset the password and click in the email link.
After the patch I've created in the prlp module, I need to move the unset for the unset($_SESSION['pass_reset_hash'])
Review possible issues that I'm missing after moving this piece of code.
N.A.
N.A.
N.A.
N.A.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3208600-2.patch | 992 bytes | isholgueras |
Comments
Comment #2
isholgueras commentedHere is the change I'm proposing to fix the issue. I hope you can check if I'm missing something because of lack of context.
Thanks!
Comment #3
isholgueras commentedComment #4
jitesh doshi commentedThank you @isholgueras for the patch.
I will try to test it. But that might take some time.
So any testing by the community would be very welcome.
Comment #5
steveganz commentedComment #6
mcdruid commentedThanks, will take a look at this ASAP.
Comment #7
mistergroove commentedThis works for me. Thanks again @isholgueras.
Comment #8
loze commentedThis works for me also.
Comment #9
sveldkamp commentedApplying both patches fixed the issue for me too.
Comment #10
roderikRemoving the session value immediately (as Core 7.79 does) is in itself nicer, in the sense that no unnecessary values stick around in the session when the user moves away from the user/reset form without submitting it.
It is still possible to alter the form, by setting the session value back during the form_alter. As demonstrated in a new PLRP patch at #3208362-14: One-time login not working with drupal 7.79. It's tricky, but... this form has always been hard to override. And the new patch isn't much more complicated than the original one.
I think that can make this issue a "won't fix".
Comment #11
gerzenstl commentedThe patch doesn't work for me. I tested with Core 7.80.
One thing I noticed is that after the user is redirected to
user/reset/<user-id>/<timestamp>/confirm, the $_SESSION variable doesn't have any value stored (with or without this patch), I've tried adding values with custom keys other thanpass_reset_hash.Currently, I'm looking at how is initialized the session when this function is called during
user/reset/<user-id>/<timestamp>/<hash>Comment #12
izmeez commentedComment #10 makes a case for why this patch is not needed for drupal core and issues that arise should maybe be patched in the contrib module(s) where they arise. This requires posts to be clearer in describing what issue(s) they are experiencing. Thanks.
Comment #13
gerzenstl commentedI found what caused the issue on our sites. It was affecting the new Support for SameSite attribute on cookies.
On our settings.php we used
$conf['samesite_cookie_value'] = 'None';, once I changed toLax, the user_pass_reset form started working.I know this is an issue about altering the user_pass_reset form. But I was able to reproduce this on a brand new Drupal 7.80 site without any contrib or custom module installed. When you click on the one-time login link on the recover password email, the user ends on the recover password page (instead of the other form with the one-time login button).
Comment #14
asierrajr commentedI'm on Drupal 7.80
Upgrading the PRLP module to version 7.x-1.4 and applying the patch in comment #2 did fix the issue for my installation.
Comment #15
mcdruid commentedClosing this per #10 on the basis that it can be fixed in any affected contrib (/ custom) code.
We do try to keep disruption like this to a minimum :)
Comment #16
q11q11 commentedPosting here for history.
Drupal 7.80 + patch from #2 + PRLP 7.x-1.4 = I'm still having
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ... for key 'PRIMARY': UPDATE {sessions} ... in drupal_session_regenerate() (line 431 of ... /includes/session.inc)