Odd stuff going on with Lost Password link

[lesliekirk]

I have a store that has a very odd and difficult to repeat issue.

Customer requests the lost password email. When they click on the link, they are taken directly to the LOGN login page and not the page that displays the temporary password along with the link to reset the password. I am able to duplicate the issue. I am not being taken to the page (ACRT) that displays the temporary password. I'm taken straight to the LOGN screen with no idea what my password was changed to. The store only is getting complaints from other customers that are having the same issues. The link is taking them straight to the LOGN screen.

From a customer:

"There is no temporary password in the link. Clicking on it just takes me back to the sign in page!"

I get the same result if I click on the link or if I copy and paste a link into the browser. I've sent number of reset requests to myself to test various browsers. I do not seem to have an issue with Safari, Google gave me an issue, then the next morning I retested Google and it worked. Firefox refuses to work for me. I have tried completely clearing my cache, it did not help.

Now to add to the oddity - this issue is not happening at all in the dev site.

I do have a ticket open with Miva and they cannot repeat the issue. Here is the link to the site.

[new_user2018]

It's my understanding that some email clients/antivirus programs/possibly browser extensions may access web links for whatever purpose (checking to see if a page is 'safe', for preview purposes, etc.) which then causes miva's password recovery link to be invalid. There was a previous thread about it but I can't seem to find it after a quick google search. If your dev site is behind a server password, that'd at least make sense why that link wouldn't be invalidated in the same way your live site is if it's due to an email client or whatever, as those things wouldn't be able to access the page.

[lesliekirk]

I wish it were something like that. I can copy the link from the email, enter it into either Safari or Chrome and works as expected. Well, Chrome sort of had to sit overnight and chill before it would. Firefox absolutely refuses to work for me. I even cleared my cache, restarted the app and it still would not work.

Now when I do the same request for the dev site all browsers work and I can click the link in the email too.

Since I'm on a Mac I don't have an overabundance of "protection". You do present an interesting theory, but then how are customers going to get past this issue?

[AHerb]

https://www.miva.com/forums/forum/on...sword-recovery

[lesliekirk]

I discovered that on a Mac using Firefox, I will not get a temp password. If I try on a PC it works...

[studio6t6]

Hi Leslie,

I found this post from last year and was wondering if you ever found out any more info on this. I'm having similar problems. It seems to only occur on stores under a particular domain. The other hosting environment I manage with another domain doesn't appear to be affected. It's a difficult problem to troubleshoot because it only seems to occur with Chrome on Windows 10 I believe. For me, anyway. Not sure if the email client being used has anything to do with it as is indicated in this post.

The problem is exactly the same though. When clicking on the password reset link in the email, it takes the user to the login screen instead of the CSTR page. Even though I can see the CSTR page being called in the URL. It's almost as though the user has clicked on the link a second time which would trigger a similar behavior I believe.

Let me know (or anyone else) if you've found anything out more on this.

Thanks!

Tony Pavao
studio6t6

[lesliekirk]

Hi Tony,

There are some updates that have fixed this. I need to find the link for the code you'll need to tweak.

Leslie

[lesliekirk]

Read through these changes and make sure you have them in place (for the Password stuff)

https://www.miva.com/mm9.13_template_changes.html

[studio6t6]

Hi Leslie,

Thanks so much for hunting this down! I will give it a try.

Tony

[studio6t6]

Hi Leslie,

Sorry, I referenced the wrong page. It's the ACRT page (as you correctly pointed out earlier in the post) that the shopper should be directed to that displays the temporary password. The CSTR page is for the password reset. I don't see any code changes for ACRT in the template changes page referenced.

Thanks,

Tony
studio6t6

[lesliekirk]

Okay, wow, 2 years later and this is still an issue. I am going to go back through and at least make sure the template code is up to date but I don't think that is the issue. It almost seems like the link is being "spoiled" by an email client. The complaints seem to be the link takes them to the login screen. This is true if the link has already been used. Is it possible that some sort of anti-virus application or something in an email account is "using" the link? I've been going rounds with this for too long for a couple of stores now.

[studio6t6]

That's what I first suspected that the email client and/or AV is interfering with it somehow. Not sure about your experience, Leslie, but this only seems to be a problem when using the old style temporary password link. Doesn't seem to occur when the user is prompted to reset their password.

[lesliekirk]

That's what I first suspected that the email client and/or AV is interfering with it somehow. Not sure about your experience, Leslie, but this only seems to be a problem when using the old style temporary password link. Doesn't seem to occur when the user is prompted to reset their password.

What is the difference? How do I change it"

[studio6t6]

Under Customers > Customer Settings > Password Reset Style: Select "Require Password Change"

By doing that, once the customers clicks on the password reset email, it will take them to the CSTR page instead of the ACRT page where they enter in their own password instead of being issued one.

These two should be checked:

Require Customers to Reauthenticate when Changing Passwords
Require CSRF Token for Customer Actions

Hope this helps!

[lesliekirk]

Thanks, Tony. I've made the change, lets see if that helps.

Leslie