We’ve implemented a flow whereby a user is supposed to be able to change the email address of their account. For this purpose we use the management api like so:
await ctx.auth0.users.update(
{ id: oldUser.sub },
{ email, verify_email: true },
);
This works as expected. We log the user out. They receive an email to verify their new email address. However, when they click the link (and we have tested this across different email providers) they are informed that the verification failed.
But seconds later they receive another email informing them of their successful verification and checking the user in the auth0 dashboard also reveals that their new email is now verified.
In the logs I see the verification is run twice: once successfully and another time it fails. But the user only sees the failed attempt even though it was actually successful.
For the failed attempt it gives “invalid result url” though the result url should be the exact same as the one for the successful verification. Why is this run twice? How do I prevent it?
The same thing does not happen for the first verification email that users are sent upon signing up for the first time.
I would add screenshots but it won’t let me embed media items in a post, I always get an error.
Hi @anna.fasching
Welcome to the Auth0 Community!
Could you please let me know if in your logs the Failed Verification appears first or the Successful Verification?
By any chance, do you test this with users creating in the dashboard or with users which signed up?
The issue might be caused by the fact that an user created within the dashboard have an empty value for {{ application.callback_origin }} resulting in an invalid redirect_url. You can read more about that in this community post.
Also, this issue could be caused by multiple requests. Did you by any chance click the link multiple times when verifying the new mail?
Alternatively, if you are using an email template, you can attempt to delete the Redirect To attribute.
You can also double check if the email instance you are testing with automatically click the user’s link for them or if they are using click tracking. This can be an issue specifically with Office 365. You can check if you receive the Successful Verification message prior to clicking the link. You can try using an email client which does not send the email to the end-user inbox such as mailtrap.io.
Let me know if the information above was helpful or if you have any other questions regarding the matter!
Kind Regards,
Nik
1 Like
Hi Nik, thank you for the prompt response.
I can add screenshots now 
I tried it again just now with a freshly signed up user that was not created via the dashboard. I still have the same problem. As you can see, I get the success first and mere milliseconds later I get a failed response with a very odd result url.
I did not click the link twice. When I do, the error is still invalid result url but the result url changes to this:
The error page I see after clicking the click is still “Email could not be verified” which in this case is also not true because the actual error message should be “Email has already been verified” or something of the sort.
This is what our Redirect To attribute looks like in the email template:
Deleting it entirely does work but that’s not really our preferred solution. Is there a way to fix the behaviour of the redirect?
Hi again,
Could you try providing a default route inside the Redirect To field to see if the issue persists?
{{application.callback_domain | default: "https://default-domain.com"}}/account?email_activation=1
Kind Regards,
Nik
1 Like
Hm… providing the default route like so:
{{ application.callback_domain | default: "http://127.0.0.1:3000" }}/account?email_activation=1
does redirect to the specified default. But that also means that the user is just redirected to the login without feedback as to whether or not the performed action worked.
Hi @anna.fasching
I have taken a look at your tenants and I could not find an application which points to the specified url in the default option.
Just so you know, the {{application.callback_domain}} will use the first URL in the list of the Allowed Callbacks URLs of the application. Is the http://127.0.0.1:3000 the first one in the list of the application that you are using or is it a different one?
Kind Regards,
Nik
1 Like
Hey Nik,
thank you for sticking with me. I do know that the {{application.callback_domain}} will use the first URL in the list of the Allowed Callbacks URLs but when I use the first one from that list (http://localhost:3000/api/auth/callback) as the default it also does not redirect correctly. Then I just end up with a 404.
For obvious reasons we haven’t tested this in our staging and production tenants yet so I am wondering if the development environment might be causing problems here that would not occur in stage or production but I don’t know.
Hi,
Thanks for the additional info.
The dev environment might cause the issue since the specific webpage might not be configured. Just to double check with you, the initial default route that you have configured, is that the URL that you wish to redirect the user to after the email has been changed?
If so, would the URL be something like http://127.0.0.1:3000/account?email_activation=1?
If not, is the first URL in your Allowed Callback URL list the one that you want to redirect to? If you want to redirect the user to the homepage, have you tried using http://localhost:3000/account?email_activation=1 or http://localhost:3000/callback/account?email_activation=1?
Let me know what is the behaviour when trying those URLs instead.
Kind Regards,
Nik
Hey Nik, in the end I stuck with the default option and configured a page to show the users the response of the verification (error or success) and made that page accessible outside of being authenticated (since users are logged out by the email change flow).
Thanks for your help!
Thanks for the update!
Glad to help and know you found a solution on the matter!
If you have any other questions, feel free to leave a reply or post again on the community!
Kind Regards,
Nik
