I had two Hotmail users tell me today that they keep getting the ouch page (Either your confirmation link has expired or you have visited a URL that's not valid) when they reset their password.
I signed up for a new Hotmail account (ugh) and ran into the same issue when testing.
Since Hotmail will fetch your page and preview it or check for spam, I suspected it was "clicking" on the link which made it invalid.
I ran a few more tests and it started working so I suspected it was cached (or verified) and wasn't prefetching the link anymore.
To prove my theory, I set up a pr_clicks column at the end of my table. Then in the Account.php file, in init_reset_password(), I added this line immediately after setting the password to empty:
I used a different app so the link wouldn't be cached and after opening the email message in Hotmail (and not clicking the link yet), sure enough it registered as a click:
I'm considering a workaround where I send only Hotmail users to another page where they enter a 6-digit number so it doesn't matter if the link is prefetched.
Any better ideas?
Members module: issue with hotmail prefetching reset password confirmation links
2 years ago
2 years ago
#1
2 years ago
#2
Ah yes, providers sometimes “scan” mails and follow links & redirects. Some mail clients and antivirus do so too.
In the past I’ve gotten around Hotmail, GMail and the like by checking the user agent header and skipping app logic and returning http 204.
You may want to add
I added bot,crawler,spider at the end & checking for typical antivirus header as a little bit of a fallback safety net.
A bit outside scope of this answer, but worthwhile mentioning..
In addition you could also perform a reverse dns lookup
and check if the tld of the hostname belongs to a provider.
If you decide this is necessary too, be aware that, if you’re hosting your app with a reverse proxy in front, kubernetes for instance. Then the request ip will likely be the internal IP, but the real IP may be passed using the X-Forwarded-For header.
In the past I’ve gotten around Hotmail, GMail and the like by checking the user agent header and skipping app logic and returning http 204.
You may want to add
I added bot,crawler,spider at the end & checking for typical antivirus header as a little bit of a fallback safety net.
A bit outside scope of this answer, but worthwhile mentioning..
In addition you could also perform a reverse dns lookup
and check if the tld of the hostname belongs to a provider.
If you decide this is necessary too, be aware that, if you’re hosting your app with a reverse proxy in front, kubernetes for instance. Then the request ip will likely be the internal IP, but the real IP may be passed using the X-Forwarded-For header.
2 years ago
#3
Hey sasin91
I checked the access logs and added the user-agent microsoftpreview to my pattern.
I'd prefer a solution where I don't have to update the pattern every time I find a new email provider issue but in the meantime, this is a good alternative!
Thank you!
I checked the access logs and added the user-agent microsoftpreview to my pattern.
I'd prefer a solution where I don't have to update the pattern every time I find a new email provider issue but in the meantime, this is a good alternative!
Thank you!
2 years ago
#4
Happy to help ?
Yeah, I fully understand that it?s annoying. Luckily, it doesn?t change that often.
Another solution could be to add an "enter code from mail" prompt along with the token. That would add a bit more protection and prevent crawlers & bots. :)
Yeah, I fully understand that it?s annoying. Luckily, it doesn?t change that often.
Another solution could be to add an "enter code from mail" prompt along with the token. That would add a bit more protection and prevent crawlers & bots. :)
2 years ago
#5
Here is a very simple fix that works 100% of the time for me.
I still have users running into issues due to other providers such as Outlook not sending any user-agent in the headers.
Since the problem is with prefetching a preview of the link within the email message, I use a landing page for that link instead.
The email message in _init_password_reset sends the user to confirm_reset_password first:
The landing page method in Account.php captures the code in segment(3):
The user simply has to click the link on that page to go to members-account/init_reset_password.
Here is my confirm_reset_password view file:
I hope this helps other users who may run into the same issue.
I still have users running into issues due to other providers such as Outlook not sending any user-agent in the headers.
Since the problem is with prefetching a preview of the link within the email message, I use a landing page for that link instead.
The email message in _init_password_reset sends the user to confirm_reset_password first:
The landing page method in Account.php captures the code in segment(3):
The user simply has to click the link on that page to go to members-account/init_reset_password.
Here is my confirm_reset_password view file:
I hope this helps other users who may run into the same issue.