auth0/auth0-vue

Preserve `error` and `error_description` query params when using `errorPath`

dahu33 opened this issue · 4 comments

dahu33 commented

Checklist

  • The issue can be reproduced in the auth0-vue sample app (or N/A).
  • I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

Shouldn't the errorPath option preserves the error and error_description query params to keep context on the error (https://auth0.com/docs/authenticate/login/auth0-universal-login/error-pages#parameters)?

The issue is here:

auth0-vue/src/plugin.ts

Line 185 in bd61487

router.push(this.pluginOptions?.errorPath || '/');

Reproduction

Probably, the easiest way to reproduce this is to have a Post Login action that denies access.

Additional context

No response

auth0-vue version

2.3.1

Vue version

3.3.6

Which browsers have you tested in?

Chrome

frederikprijck commented

Hello,

We have an example on how to handle errors in our repository: https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#error-handling

We wrap most methods and put the entire error on the error property: https://github.com/auth0/auth0-vue/blob/main/src/plugin.ts#L203

Can you help me understand what doesn't work for you in this case?

dahu33 commented

After trying to use the authGuard, the errorPath option, and the error handling method mentioned above, it appears that the authGuard creates an infinite redirection loop as it doesn't handle the error case and just call loginWithRedirect blindly. Please advise...

frederikprijck commented

https://github.com/auth0/auth0-vue/blob/main/FAQ.md#4-getting-an-infinite-redirect-loop-between-my-application-and-auth0

You should not redirect back to a protected route. A protected route means you can only access it when logged in, but when being redirected back from Auth0 we are either:

  • Not yet logged in as we still need to fetch a token, so you are only logged in asynchronously after exchanging the code for tokens.
  • Will never be logged in because of an error

Therefor, you need to ensure you redirect back to a non-protected route to handle the callback.

Your setup should look like this:

  • Have a route that is not protected, let's call it /callback.
  • Use that url as the redirectUri when configuring the SDK

There are now two situations to account for:

When accessing a route (/protected-route) that is protected by our AuthGuard, you will be

  • Redirected to Auth0
  • Redirected back to /callback after loggin in on Auth0
  • Redirected back to /protected-route after getting tokens and being considered logged in, or errorPath in case of an error

When calling login explicitly
When you call login explicitly, you want to ensure you configure the url to be used for the last step above by setting appState.target. Let's say you want the user to end on /dashboard after clicking login and being logged in, you use:

loginWithRedirect({
  appState: {
    target: '/dashboard'
  }
})

Then the following will happen:

  • Redirected to Auth0
  • Redirected back to /callback after logging in on Auth0
  • Redirected back to /dashboard after getting tokens and being considered logged in, or errorPath in case of an error

Hopefully that helps.

frederikprijck commented

Closing as I think this has been answered. Feel free to ping me if not.