/continue returning 401 - how to catch that error to redirect the user somewhere else

Get Help
, ,
4

Hi Dan,

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:

  1. 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).

  2. 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.

  3. 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?

Thank you.