Closed grikomsn closed 3 years ago
Submitted #1168 which proposed defining NEXTAUTH_URL
via Next.js runtime configuration.
It's currently an environment variable to simplify configuration.
This is so that it only needs to be defined in one place, which covers Server Side Rendering of pages, Client Side Rendering of pages and API routes and works across platforms (Vercel, Netlify, Heroku, AWS Lambda, inside a Docker container, etc) and that as long as it's configured everything should "just work" with as few caveats as possible.
We are interested in exploring options to move some configuration out (e.g. into a file like nextauth.config.js
) but we'd want to be careful with what information we exposed from the client to the server if we did that (i.e. so that people don't inadvertently end up creating a client side bundle that included sensitive credentials for a provider and/or database).
Automatic detection and/or dynamic configuration isn't as helpful as people often suppose as the majority of OAuth providers require specific callback URLs to be configured for use. In some cases, like GitHub, only a single host is valid for a given set of credentials.
Different CLIENT/SECRET OAuth credentials should be used for development instances vs live, meaning setting NEXTAUTH_URL as well doesn't make much of a difference as to what's required. Setting up a pre-live site like staging.example.com
(and, optionally, having it wired to a Git branch like staging
) is a straightforward one-time thing.
The problem it addresses - improving support for testing on pull request environments - which typically cannot be used with OAuth providers, for reasons not to do with NextAuth.js - is something we've discussed though and would like to provide some sort of support for, and have ideas around.
It would be easier to do something as a SAAS solution, I think we could create something very slick there and would very much like to explore that in future. Thee isn't a way to support OAuth with dynamic hostnames without running some sort of service.
Currently, given the limitations of OAuth providers, having a conditional switch in [...nextauth].js
to configure an Email provider on is one way of providing a sign in experience on test instances with dynamic hostnames. The fallback to VERCEL_URL is explicitly support this sort of flow. Hard coding some account details in a Credentials provider (that is only configured on those instances) is also an option that may work for some folks.
I realize our use case is probably outside the norm, but we are building a multi-tenant front end mapped to multiple hostnames, and were planning on having a provider registered for each tenant (so per callback URL).
Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!
Hi there! It looks like this issue hasn't had any activity for a while. To keep things tidy, I am going to close this issue for now. If you think your issue is still relevant, just leave a comment and I will reopen it. (Read more at #912) Thanks!
Hi there, thanks for next-auth btw. it’s awesome :) Can this please just be a runtime config? What if I use ngrok tunneling and get another address every time? How can I update the env variable dynamically then? Seems like overcomplicating things, why not be able to optionally pass that variable in all places where it is needed to avoid using .env variables? Thank you!
Summary of proposed feature Adding options to define
NEXTAUTH_URL
not via environment variables but via server handler creation parameters or client default parameters.Purpose of proposed feature Allow custom and dynamic
NEXTAUTH_URL
value assignment via function parameters instead of environment variables, where in some cases cannot set environment variables or requires dynamic assignment.Detail about proposed feature Some edge cases (especially Vercel multi-domain deployments) requires different values for
NEXTAUTH_URL
(e.g.example.com
andstaging.example.com
), but sinceNEXTAUTH_URL
needs to be defined via environment variable and the value retrieval is mostly hardcoded insidenext-auth
, currently there is no way to use different values.Potential problems If adding a way to define
NEXTAUTH_URL
but still keep the option to define via environment variables, possible issues would be changing how assigning and using the default parameters work. Notable lines:https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/client/index.js#L25-L26
https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/client/index.js#L313-L314
https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/lib/jwt.js#L105-L108
https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/server/index.js#L16-L20
https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/server/index.js#L50
Describe any alternatives you've considered Some alternative approaches would be either automagically detect the URL, or use Next.js runtime configuration to store various default values including
NEXTAUTH_URL
(probably not the best approach since it's incompatible with automatic static optimization).Additional context This proposal issue was created because I am currently developing a Next.js based application which requires multiple subdomain and deployed using Vercel and we can't set dynamic env vars for
NEXTAUTH_URL
for different branches on Vercel.Another context is that I've tried recreating the
next-auth
codebase using tsdx but since there's Docusaurus and various sources that I'm not familiar with, I didn't continue working on the rewrite (for now).Please indicate if you are willing and able to help implement the proposed feature.
I am willing to help in any way, unless if https://github.com/nextauthjs/next-auth/pull/516#issuecomment-763126791 is on the way, I can help rewrite some TypeScript stuff and include this proposed feature if considered.