Broken password reset on staging

[bethschechter]

Steps to reproduce the error

1. Forget password (optional)
2. Click link to Reset Password
3. Go to inbox, where the reset link is
4. Click the link
5. Attempt to create new password

Actual behavior

I would expect this would result in a successful reset.

Expected behavior

I did not get to reset my password. Instead, I got the error messages shown in the image below.

In addition to refreshing multiple times and clicking the link again from my inbox, none of the following passwords worked:

QWErty123$%^
QwErTy1@3$5^
M00C0wmaps123
MMM@@@pppsss123

[clash99]

@bethschechter looks like you are meeting all the Upper/Lower/Number/Character requirements but the conflict is coming from your username and/or email. Can you provide those combos you tried?

[bethschechter]

Sure @clash99. It was from the email [email protected]

[wonderchook]

@clash99 I was having the same problem with user "kate11"

[clash99]

@wonderchook - on the forgotten password page or on the registration page? I'm able to recreate it from the emailed password link but not on the registration page.

[clash99]

@oliverroick - looks like the username and email values aren't getting passed through to the password reset by key page (via email link). I will look at it more tomorrow.

[clash99]

Fixed error message in pull request #986

[oliverroick]

@clash99 I recovered the original solution before my cleanup from here and tested to reset the password. The problem is when the user is not signed in {{user.email}} and {{user.username}} are empty and the validation fails both with your and with my approach.

[oliverroick]

I addressed the issue (PR #988) by removing client-side validation from the password reset view. Let me explain: I had a PR ready that adds the user's username and email to the template and enables client-side validation. In this particular case, however, we might open a security hole, when we make the user's credentials public. If someone gets hold of the password reset link, they will get the username associated with the account and the new password, i.e. all information necessary to hijack the account. I checked back with @amplifi, and we decided to move validation entirely to the back-end for this view because it's too risky.