Any sort of error causes a infinite redirect chain

[Empty2k12]

Describe the problem

While implementing the Auth0 SDK, both email being not verified and script-blocker blocking access to the auth0.com domain is causing an infinite redirect chain with changing tokens.

What was the expected behavior?

Fine-grained error handling capabilities being available, so I can alert my users if the domain is blocked, or if the e-mail needs to be verified. If requests are retried, I'd expect an implementation of exponential back-off preventing rapidly sending requests despite them failing all the time.

Reproduction

Implement auth0-react like described here: https://auth0.com/docs/libraries/auth0-react

Way 1

Create a new user, but don't confirm the e-mail. Log-in and see rapid redirections.

Way 2

Install uMatrix and log-in to the React app. See rapid redirections.

Environment

Please provide the following:

• **Version of auth0-react used: 1.1.0
• **Which browsers have you tested in?: Firefox, Chrome
• **Which framework are you using, if applicable (Angular, React, etc): React

[Empty2k12]

The way we're currently working around this issue is parsing URL search params ourselves and when it contains error and/or error_description abort rendering any Auth0 components. That prevents at least the redirect chain from happening.

Looking at the code from this repo, the error is being handled internally and should be made visible to the user. Another nit is that the server is returning an English localized string in error_description instead of an enum which could be used to localize the error cause in the React application.

[adamjmcgrath]

Hi @Empty2k12 - thanks for raising this.

In the event of a login error, the hook will return an error which you can use to handle cases like this.

If the callback url contains error and error_description params, the error object will also contain those properties.

You're probably getting an infinite redirect chain because you're using withAuthenticationRequired which currently ignores errors, so you should guard against them before using it eg

const App = () => {
const { error } = useAuth0();
if (error) {
return <>Oops... {error.error_description || error.message}</>
}
return ;
}

We could look at adding an onError to withAuthenticationRequired, making it:

const App = () => {
const onError = (error) => <>Oops... {error.error_description || error.message}</>;
return <Route component={withAuthenticationRequired(Profile, { onError })}/>;
}

But the first example should prevent the infinite redirects issue for now.

Another nit is that the server is returning an English localized string in error_description instead of an enum which could be used to localize the error cause in the React application.

Are you generating the error on the server from a custom rule (eg https://auth0.com/rules/email-verified)?

[adamjmcgrath]

@Empty2k12 ☝️ I've edited the post above: you shouldn't be redirecting to a protected page because the onRedirectcallback won't fire if handleRedirectCallback errors, and you shouldn't make your callback page a protected page, so you shouldn't be able to get into an infinite redirect after a login error. Do you have an example app or any code I can look at?

[Empty2k12]

you shouldn't be redirecting to a protected page because the onRedirectcallback won't fire if handleRedirectCallback errors, and you shouldn't make your callback page a protected page, so you shouldn't be able to get into an infinite redirect after a login error.

I cannot share code at this time, but the setup is quite simplistic. There's only one route, which is the protected one. Any user which is not authenticated will be redirected to the login-page. Seems like this use-case is not supported at this time, can you suggest any workarounds?

<Auth0ProviderWithHistory>
    <Menu />
    <Route path="/">
        <ComponentWithwithAuthenticationRequired />
    </Route>
</Auth0ProviderWithHistory>

If the callback url contains error and error_description params, the error object will also contain those properties.

Not sure how I missed the error being exported from the useAuth0 hook, sorry! This will simplify the error handling a little.

Are you generating the error on the server from a custom rule (eg https://auth0.com/rules/email-verified)?

This is indeed the case, from the error it looked like this is a feature from Auth0 rather than a script, but I checked back with the person in charge of setting up Auth0. I will initiate a change which - in our case - returns an enum-error which can be localized vs. a complete error string.

[adamjmcgrath]

There's only one route, which is the protected one.

You'll need a route to handle the callback that isn't protected, eg:

const CallbackComponent = () => {
  var { error, isLoading } = useAuth();
  if (isLoading) return <>Logging you in...</>;
  if (error) return <>Verify your email and login again</>;
}

...

<Auth0ProviderWithHistory redirectUri="http://domain/callback">
    <Menu />
    <Route path="/callback">
        <CallbackComponent />
    </Route>
    <Route path="/">
        <ComponentWithwithAuthenticationRequired />
    </Route>
</Auth0ProviderWithHistory>

[adamjmcgrath]

Closing this, feel free to reopen if you have any other questions