Hoh man what a journey. And I love that this incredibly complex situation is the only reason that status would return. What a fun time debugging that would have been
The type of error where you have to give up trying to understand the user.
It's quite simple actually: The user wanted to delete their account, but forgot their password so they requested a password reset. Before the password reset email was delivered, the user remembered their password and deleted their account. The password reset email is finally delivered and apparently some email clients open all the links in the background for whatever reason, so it wasn't actually the user who clicked the password reset link.
apparently some email clients open all the links in the background for whatever reason
What? Really??
Yes, e.g. outlook replaces links in mails so they can scan the site first. Also some virusscanners offer nail protection, checking the site that's linked to first, before allowing the mail to end up in the user's mail client.
Thats why you never take actions on a GET request, but require a form with button for the user to do a POST.
It can be worse, we had to add a captcha for those link scanners cause they'd submit the forms and invalidate tokens too:(
Wow. That sounds terrible. Good to know.
e.g. outlook replaces links in mails so they can scan the site first. Also some virusscanners offer nail protection, checking the site that’s linked to first, before allowing the mail to end up in the user’s mail client.
Proofpoint does this too, but AFAIK they all just change the link rather than go to it. The link is checked when the user actually clicks on it. Makes sense to do it on-demand because the contents of the link can change between when the email is received and when the user actually clicks it.
Yep. Apparently outlook does this and afaik because some kind of link sniffing/scam detection/whatever, but it does it by changing the first characters of each query argument around.
We spent amazingly long time figuring that one out. "Who the hell has gotten Microsoft service querying our app with malformed query args and why"
Not really the only reason. It would be better to just return "token invalid".
It could occur by someone messing with the URL from the reset password email, like accidently adding an extra character before pressing enter
Or a poor email client that wraps the URL and doesn't send the complete one when clicked.
Or someone attempting to find a weakness in the reset password system and sending junk as the token.
Or an email client where you double click the link text to select it and press copy, and somehow this puts the link plus a trailing space in the clipboard to be pasted into a browser.
Yeah that error status code seems like an odd way to reflect such a scenario.
Hoh man what a journey. And I love that this incredibly complex situation is the only reason that status would return. What a fun time debugging that would have been
The type of error where you have to give up trying to understand the user.
It's quite simple actually: The user wanted to delete their account, but forgot their password so they requested a password reset. Before the password reset email was delivered, the user remembered their password and deleted their account. The password reset email is finally delivered and apparently some email clients open all the links in the background for whatever reason, so it wasn't actually the user who clicked the password reset link.
What? Really??
Yes, e.g. outlook replaces links in mails so they can scan the site first. Also some virusscanners offer nail protection, checking the site that's linked to first, before allowing the mail to end up in the user's mail client.
Thats why you never take actions on a GET request, but require a form with button for the user to do a POST.
It can be worse, we had to add a captcha for those link scanners cause they'd submit the forms and invalidate tokens too:(
Wow. That sounds terrible. Good to know.
Proofpoint does this too, but AFAIK they all just change the link rather than go to it. The link is checked when the user actually clicks on it. Makes sense to do it on-demand because the contents of the link can change between when the email is received and when the user actually clicks it.
Yep. Apparently outlook does this and afaik because some kind of link sniffing/scam detection/whatever, but it does it by changing the first characters of each query argument around.
We spent amazingly long time figuring that one out. "Who the hell has gotten Microsoft service querying our app with malformed query args and why"
Not really the only reason. It would be better to just return "token invalid".
It could occur by someone messing with the URL from the reset password email, like accidently adding an extra character before pressing enter
Or a poor email client that wraps the URL and doesn't send the complete one when clicked.
Or someone attempting to find a weakness in the reset password system and sending junk as the token.
Or an email client where you double click the link text to select it and press copy, and somehow this puts the link plus a trailing space in the clipboard to be pasted into a browser.
Yeah that error status code seems like an odd way to reflect such a scenario.