Password reset links not working

[AmaniKrayemRCPCH]

We've had three reports of this, this morning.

1. First user had a new account created Monday 11am. Clicked on the link 1pm today. "This link did not work, and there was no response when I clicked to reset password"
2. Second user had a new account created yesterday. Emailed us today "My password reset field is invalid. "
3. Third user's link didn't work yesterday, so i resent the email at 2pm yesterday. 8am today he said ". I have used this morning for the first time and this is what I got ." and attached the below picture

[pacharanero]

Thanks for reporting @AmaniKrayemRCPCH - we will look into this issue as a priority matter.

[eatyourpeas]

The password tokens only last for 72 hours, after which they are invalidated. I think this explains user 1. If you have not confirmed your account by resetting your password with the original link, I don't think it is possible to reset your password. For this person I would suggest deleting the account and recreating, ensuring they click on the email link within 72 hours.

Second and third users also not clear but I am not sure what is reported is the whole story. Perhaps we can catch up together and run through each one and troubleshoot?

[anchit-chandran]

This has been sorted. Closing

[pacharanero]

I have had the same thing happen in local testing and it is annoying that password reset functionalioty seems only partial. I suspect that once a password reset token has been generated for a user, Django seems to refuse to create any further resets. This is going to cause us a lot of pain down the line if users can't simply reset passwords, even if they have already done it once.

I know of people who don't actually ever try to remember passwords they just use the password reset link every time they log into something! I'm not saying it's a good idea but we have to be ready for it.

If the PW reset is clicked when there is already an active password reset token, then all but the latest password reset token should be invalidated, but it should continue to let you reset the password as many times as you like.

[dc2007git]

Hi @AmaniKrayemRCPCH , I've been testing the password reset functionality and looking at edge cases and I think I've figured out a workflow to minimise how many users encounter this password reset email problem:

For users who have not yet logged in and are not deemed 'active':

This user should get in touch with the E12 team, who will then be able to 'Resend Email' by accessing that user's details in the User View. They will receive a password reset link that will expire in 259200 seconds (72 hours) as set by PASSWORD_RESET_TIMEOUT in settings.py. Note that even if the user has clicked on the link in the 72 hour window, but then 72 hours elapses before they press 'reset password', it will fail.

I have tested this behaviour myself in development, and it does seem that the link sent by Resend Email is fully functional and able to set the user's password for the first time, even if they missed the first link.

For users who have previously logged in (even without 2FA verification) and so are deemed 'active':

This user can reset their own password using the reset password link. They must have previously set their password in order to do this. Again, the same conditions apply. They have 72 hours to submit their new password. @eatyourpeas and I have both tested this behaviour in development and it performs as expected.

Note for debuggers

When you are testing this functionality in development, you will likely set PASSWORD_RESET_TIMEOUT to a shorter timespan, so as to not wait 3 days to test the use case! Be warned however, that you must have opened and submitted the password reset form in order for it to successfully submit and reset your password. That is to say, PASSWORD_RESET_TIMEOUT is not a timeout for the email link, but for the form submission itself.

@AmaniKrayemRCPCH If any further cases of this pop up please let me know and we can look into it. It seems to be fully functional now.

@pacharanero it seems like when we were debugging together, we fell into the trap I've described above of being able to submit the form in time. Simon and I tested it extensively and it is behaving normally.

[pacharanero]

Discussed in E12 SPM today and @AmaniKrayemRCPCH @nikyraja agreed we could close this issue as we have had no further reports of problems.