Universal login change password doesn't trim email address

Help
1

We use the universal login flow, and we customize the prompts for the forgot password UI. We found that if a user types a space after the last character of their email address, the UI complains that it is an invalid email address instead of just trimming the space off and proceeding with the request. This has caused confusion to some of our users because they don’t realize they have a space at the end, and they know their email address is accurate…

Is there anyway to force trim the email address so the user doesn’t get this error?

image

3

Hi @chris.bohn ,

Thank you for posting this topic on the Auth0 Community!

I could not repeat this error in the forgot password UI. What prompts were updated in your UI? And did this error start after the update? Could you please provide additional context? Thanks!

4

We have a custom database, but even when I just tried on the default app using the default “Username-Password-Authentication” database that isn’t using the custom database, I get the same behavior. We’ve of course customized the universal login to have our logo and such, but when I put any password in the reset password screen with spaces after it, I get a 400 on the POST to /u/reset-password/request/Username-Password-Authentication?state=<long state> indicating the email is invalid.

If I simply remove the spaces after, I get a 200 on the same API call. I thought it was our custom database script until just doing the test above and realizing it isn’t from our custom script.

5

Could you please repeat this issue and send the HAR file to me via DM? Thanks!

6

@lihua.zhang Attached is the requested file

healthos-dev.us.auth0.com.har (377.2 KB)

7

This topic was automatically closed after 11 days. New replies are no longer allowed.

9

Thank you for providing the HAR file. I searched internally and found a bug ticket regarding the whitespaces before and after the email address not trimmed in the signup and forgot password page. Then I did more testing with two other tenants and could repeat this issue. Not sure why I don’t see this behavior in the tenant I tested initially.

I will watch out for the updates for the bug ticket and provide updates here once it’s solved.

Please let me know if any other concerns meantime. Thanks!

1 Like