Preserve `error` and `error_description` query params when using `errorPath`
dahu33 opened this issue · 4 comments
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:
Line 185 in bd61487
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
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?
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...
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
fortokens
. - 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.
Closing as I think this has been answered. Feel free to ping me if not.