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.
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”
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.
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.
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??
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”
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.