Reports of issues with password reset on Portal

We seem to get quite a lot of reports from customers that they are not able to reset their password from the ‘Forgot password’ option.

Having done a lot of testing I’ve found that this appears to only be on certain types of email address where the link within the reset email sent to the customer doesn’t appear as a link but as plain text which then has to be copied and pasted. This does open the password reset page but when submitted the page says ‘Failed to authenticate’.

I wondered if anybody had come across the same issue with customer password resets and if anybody had any ideas for a solution.

Hi Cathy, I’m sorry to hear that your are having issues. I shall pass this on to a colleague who should be able to assist you further.

Regards - MP

Hi Cathy, could you please clarify if this is a Community login issue or an issue with one of your Create Apps?

Thanks - MP

Hello Mark
This is logging onto our Portal (Central) rather than an app.

We’re still struggling with this.
We decided we would try using the option of Authentication code so created a new Authentication Flow which is basically a copy of the default and then we have changed the Credential Source on step 2 to Auth code from email. When tested this doesn’t send an email at all so we tried setting the Credential Source back to Auth link from email and an email is still not sent.

Any ideas on this would be appreciated.

Hi Cathy,

This will likely be due to an optional, but defaultly enabled security setting that enforces that the user resets their password only from the originating browser (The one they clicked password reset within).

The setting is called Enforce completion in the same broswer and is on Step 3 of the Default password reset flow.

It is designed to prevent a user whose email inbox may be compromised from having their password reset by a user on a different computer.

Often users may open their email on their mobile device or their email application may open a different browser. In these scenarios the reset will fail as there is an absence of the originating session cookie present.

Instead of disabling it, you could first try being more explicit about the request in the email, which is sent in Step 2 of the Default Password Reset Flow by explicitly requesting the password reset link is used within the originating browser.

Hope this helps.


Thank you for your help so far, we’ve tried adding wording about opening the email in the same browser and are hopeful this will help.

We would still like to explore the possibility of using a code instead of the link in the email or even removing the requirement to open the email in the same browser but I’m not able to test this. We have created a duplicate of the log in and password reset authentication flows and set the system to use these as default, everything looks OK on screen but the customer never gets an email. As a first test I have checked all the details on the copies and, other than their names, they look identical to the default but no email is received. Until I am able to get an email from the copy in our build environment I won’t be able to explore the possibility of changing the authentication flow.

Any ideas on what I can try next would be very much appreciated.