You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My team is using redirect_uri within the handleLoginauthorizationParams in order to make sure that users end up on the right page post-login in different environments that our app is deployed in. I found the info on how to do that here. See exact code in the Reproduction section of the issue.
However, within a support ticket a while back about overriding AUTH0_BASE_URL I was told that using that redirect_uri was not the documented way to do this, and I should use the returnTo property of the LoginOptions object instead. I want to use the documented "correct" way to do this. Unfortunately, returnTo does not appear to be overriding the behavior of AUTH0_BASE_URL. In deployed environments we get redirected to the url in AUTH0_BASE_URL instead of the one in returnTo.
This seems like a bug to me, but maybe the difference in behavior between redirect_uri and returnTo is intentional and this is more of a documentation issue. Or I'm just using one or both of them incorrectly! Thanks very much in advance for taking the time to look at this, let me know what other information I can provide!
Reproduction
I cannot share the whole repo since it's not open source but here is our current [...auth0].ts:
When we use that version, returnTo does not seem like it's respected -- our staging environment login redirects users back to our test environment instead (that's the value in AUTH0_BASE_URL). The advice in a similar issue here to not use a fully qualified URL didn't seem to make a difference for me.
Additional context
No response
nextjs-auth0 version
v2.2.2
Next.js version
v12.3.2
Node.js version
v14.17.0
The text was updated successfully, but these errors were encountered:
Your second code snippet looks good, except you should should set authorizationParams .redirect_uri to match the domain of the returnTo (as you've done in the first code snippet)
The general rule of thumb is:
redirect_uri - registered on the AS, we can trust it - but you're limited to how many urls you can register returnTo - provided by the user, we can't trust it - you can link to whatever url you like, as long as it matches the domain of the redirect_uri
I think I finally understand, thank you so much @adamjmcgrath !
So it sounds like we can use returnTo if needed to generate urls with different paths on the fly (i.e. to different pages in the app), but we would use it in conjunction with redirect_uri not as a replacement.
Is this documented somewhere that I can link to in our codebase? If not, if you can point me toward where it should be I'd be happy to help with a PR!
Checklist
Description
My team is using
redirect_uri
within thehandleLogin
authorizationParams
in order to make sure that users end up on the right page post-login in different environments that our app is deployed in. I found the info on how to do that here. See exact code in the Reproduction section of the issue.However, within a support ticket a while back about overriding
AUTH0_BASE_URL
I was told that using thatredirect_uri
was not the documented way to do this, and I should use thereturnTo
property of theLoginOptions
object instead. I want to use the documented "correct" way to do this. Unfortunately,returnTo
does not appear to be overriding the behavior ofAUTH0_BASE_URL
. In deployed environments we get redirected to the url inAUTH0_BASE_URL
instead of the one inreturnTo
.This seems like a bug to me, but maybe the difference in behavior between
redirect_uri
andreturnTo
is intentional and this is more of a documentation issue. Or I'm just using one or both of them incorrectly! Thanks very much in advance for taking the time to look at this, let me know what other information I can provide!Reproduction
I cannot share the whole repo since it's not open source but here is our current
[...auth0].ts
:This configuration is working for us in all environments. The following configuration is not:
When we use that version,
returnTo
does not seem like it's respected -- our staging environment login redirects users back to our test environment instead (that's the value inAUTH0_BASE_URL
). The advice in a similar issue here to not use a fully qualified URL didn't seem to make a difference for me.Additional context
No response
nextjs-auth0 version
v2.2.2
Next.js version
v12.3.2
Node.js version
v14.17.0
The text was updated successfully, but these errors were encountered: