-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting redirect_uri at runtime on the callback handler just like it's allowed on the login handler #298
Allow setting redirect_uri at runtime on the callback handler just like it's allowed on the login handler #298
Conversation
…ndler just as it's currently allowed on the login handler
@mariano is attempting to deploy a commit to the Auth0 Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, just need to add it to the Next handler options
Just did, sorry I've missed that |
Thanks @mariano! |
D'oh sorry @mariano, could you raise this against |
@adamjmcgrath sorry to keep bugging you, but are there plans for releasing a new npm version containing this fix? It is a limitation that prevents multi-tenant nextjs apps from working with auth0, so imho maybe it deserves a release? I did try forcing
and while yarn does install it properly it fails during build time while trying to resolve the |
@mariano - no worries, I'll do a release early next week
You need to build the $ git clone https://github.com/auth0/nextjs-auth0.git
$ cd nextjs-auth0
$ npm install
$ npm version 1.0.0-mariano.0 --no-git-tag-version # give it a unique version name so your npm install wont hit the cache for `1.0.0`
$ npm pack # this will build the src and package it in a tgz for you
$ cd ../your/next/app
$ npm install ../path/to/auth0-nextjs-auth0-1.0.0-mariano.0.tgz |
@adamjmcgrath Of course that did it. You are awesome. I don't play with frontend often, so pardon my cluelessness :) |
Description
While there is currently a way to specify at runtime the
redirect_uri
used within the login handler (thus overridingprocess.env.AUTH0_BASE_URL
), the same cannot be done from within the callback handler, resulting in anunauthorized_client
bad request error indicating the mismatch between both URLs.This lack of consistency is evident in login.ts where
LoginOptions.authorizationParams.redirect_uri
takes precedence over building the redirect URL withurlJoin(config.baseURL, config.routes.callback)
, while on callback.ts there is no possibility of modification: the redirect url will always beurlJoin(config.baseURL, config.routes.callback)
.This PR introduces a new option on
CallbackOptions
: the optionalredirectUri
. With it, one can specify a different URL at runtime in[...auth0].tsx
by overriding thelogin
andcallback
handlers. In the following example, assume that the redirect URI is different fromAUTH0_BASE_URL
, and that its definition might depend on custom headers or other data coming fromNextApiRequest
, thus rendering the alternative of customizinginitAuth0
not viable.References
Other issues (#108, #154, #295) either directly or indirectly reference this limitation, mostly within the context of a Vercel deployment. We have experienced this ourselves while developing a multi-tenant nextjs auth0 app.
Testing
I've introduced a test case to ensure
CallbackOptions.redirect_uri
can be specified at runtime.To replicate this in a real application just set your
AUTH0_BASE_URL
environment variable to a specific host (for examplehttp://localhost:3000
), and then define a different URL inauthorizationParams.redirect_uri
on the login handler (such ashttp://messi:3000
), which should resolve to the same nextjs app. After logging in on auth0 and being sent back to the nextjs app to handle the oauth callback, it'll consistently fail with a bad requestunauthorized_client (The redirect URI is wrong. You sent http://localhost:3000, and we expected http://messi:3000)
. Applying this PR and utilizingCallbackOptions.redirectUri
as shown before solves the problem.