I’m looking into the redirect rules in order to redirect the user to a web app right after they signed up to do the following:
Verify their email address by sending an email as soon as they hit our webapp. The email is sent by us and not using the Auth0 mail service so we can alter the link to continue with the flow in our web app.
Once the user clicks on that link, they go back to our web app to get a couple of extra details such as name and terms and conditions acceptance
After getting those details, we set the user as verified and we want to hit the /continue endpoint to finalise the signup flow properly so the user ends up being signed in.
The issue we are facing is if the user opens the link in a different browser or device where they started the flow. That would trigger a 401 when hitting the /continue endpoint leaving the user in a white page where nothing can be done.
The question is: Is there a way of catching that 401 so we can then redirect the user to another page or show a proper error message?
Also, is there any official auth0 documentation on the /continue endpoint and its limitations? I haven’t been able to find it.
My understanding is that we can only call /continue from a browser redirect but not by using an AJAX call where we could potentially catch it and do what we need to do. I got that from this post CORS Error when trying to POST to /continue - #2 by sgo. Is that valid?
Unless you have an explicit reason to use rules, you should check out Redirect Actions, they are the modern equivalent to redirect rules. The continue endpoint is documented there too.
I am not seeing any way to handle that error more elegantly. You could create a Feature Request for it if you’d like.
The redirect flows are meant to be completed during the authentication flow in a series of redirects. Can you give an example of how you are trying to complete the requests? Specifically, “by using an AJAX call where we could potentially catch it and do what we need to do.”
Unless you have an explicit reason to use rules, you should check out Redirect Actions, they are the modern equivalent to redirect rules.
We’d love to use actions instead ha, but the reason why we are looking into rules is because “Actions” is not available for private cloud yet. My company is already in an enterprise plan with Auth0, we have our private tenants and we are starting all the config in a month. Now we are on research stage. Our understanding is that Actions won’t be available till q1 next year and that we should consider possible delays. Is that right?
Can you give an example of how you are trying to complete the requests? Specifically, “by using an AJAX call where we could potentially catch it and do what we need to do.”
We’d need to redirect the user to either the login page so they can log in again, or to a web page hosted by us and display a proper error message with some instructions for the user to continue using our app. A white page with the text “unauthorized” and without being able to go anywhere else is just … terrible haha sorry for being so direct.
FYI, the reasons why the user could get a 401 when hitting the /continue endpoint could be:
Auth0 recommends hitting /continue within an hour (see Action Coding Guidelines). As we are using the redirection rule so the user can verify their email address, it might happen they take a little extra time to continue the flow (sometimes the email takes some time to arrive or the user might get distracted by something).
When verifying their email address, it might happen the user opens the link in a different browser or device. We want to allow the user to continue the flow in a different device (knowing they’ll need to sign in again after completing the flow), but if they trigger the /continue from there, they’ll get a 401. We could potentially avoid that by a simple check if there is a cookie in the browser meaning the flow started there but as we already need to address reason 1, it would be nice to have the same approach here.
Any kind of unexpected browser behaviour could trigger that 401. We cannot risk the user landing on that white page.
Is there anything that can be done to address a 401 when using /continue call?
Ah I see, that makes sense. I don’t have the answer to that at the moment, but I would be happy to reach out to your account manager. I’m going to send you a DM for more info.
Also, thanks for adding some more context to your question. That info is very helpful. I can’t seem to find a way to handle this type of error, but I am going to reach out to our field team to see if I can find another strategy. I’ll update here when I have a response.
