Need to set NEXTAUTH_URL dynamically as an Option for multi-domain/multi-tenant use

[SharadKumar]

Your question
How to dynamically work with Passwordless/Email auth, without setting NEXTAUTH_URL.

What are you trying to do
I am working on a use-case where NEXTAUTH_URL is not fixed at deploy-time or build-time, but run-time, for a multi-domain (single codebase) scenario. This is to have Email passwordless only.

I have had good success with next-auth other providers for usual scenarios, and absolutely love the simplicity.

Feedback
I tried to browse around the code to get a sense of dependency of the deploy-time NEXTAUTH_URL, and it seems that it is use only to define the Url for sendVerificationRequest. If there was a way to pass it as an option, it would do it.

Please advise, whats the best approach.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[SharadKumar]

Server has a todo flagged:

next-auth/src/server/index.js

Lines 47 to 50 in 12a5d6b

	// @todo refactor all existing references to site, baseUrl and basePath
	const parsedUrl = parseUrl(process.env.NEXTAUTH_URL || process.env.VERCEL_URL)
	const baseUrl = parsedUrl.baseUrl
	const basePath = parsedUrl.basePath

JWT. GetToken can be custom though:

next-auth/src/lib/jwt.js

Lines 94 to 103 in 8115a7c

	const getToken = async (args) => {
	const {
	req,
	// Use secure prefix for cookie name, unless URL is NEXTAUTH_URL is http://
	// or not set (e.g. development or test instance) case use unprefixed name
	secureCookie = !(!process.env.NEXTAUTH_URL || process.env.NEXTAUTH_URL.startsWith('http://')),
	cookieName = (secureCookie) ? '__Secure-next-auth.session-token' : 'next-auth.session-token',
	raw = false
	} = args
	if (!req) throw new Error('Must pass `req` to JWT getToken()')

And, for the client:

next-auth/src/client/index.js

Lines 24 to 26 in 8115a7c

	const __NEXTAUTH = {
	baseUrl: parseUrl(process.env.NEXTAUTH_URL || process.env.VERCEL_URL).baseUrl,
	basePath: parseUrl(process.env.NEXTAUTH_URL).basePath,

These are the references I found. @iaincollins I can try to fork and attempt a hack on my side, since I really need to solve this. If you can advise how to go about it, it would be awesome. It seems you intend to refine/refactor this at some point, as stated above. Above three are the only references I found.

Any help is really appreciated.

[SharadKumar]

Okay, so I managed to fork and make server-side work! Looking into the client side now...

I added to server:

    const { origin } = absoluteUrl(req)

    // @todo refactor all existing references to site, baseUrl and basePath
    const parsedUrl = parseUrl(process.env.NEXTAUTH_URL || origin || process.env.VERCEL_URL)

and lib/parse-url.js: (I couldn't find a way to get protocol with NextJS req object:

export const absoluteUrl = (req) => {
  var protocol = "https:"
  var host = req
    ? req.headers["x-forwarded-host"] || req.headers["host"]
    : window.location.host

  if (host.indexOf("localhost") > -1 || host.indexOf(".local") > -1) {
    protocol = "http:"
  }
  return {
    protocol: protocol,
    host: host,
    origin: protocol + "//" + host,
  }
}

[iaincollins]

Hi Sharad,

If you are seeing this error there is likely problem with your build process or how you are linking to the libraries. You'd need to post and link to the repo before we can help with that.

Regarding the wider question of supporting domains dynamically, this is something we don't support currently. I don't have an update on this I'm ready to share right now, but I hope there will be an update on this at some point in the coming weeks.

[SharadKumar]

Thanks Iain, yes I am trying to get my head around this.
I've been able to work with multiple-domains dynamically, and to do that I forked... modified server to work with origin (as above) based on current request. At the moment, my main use case is Email provider.

I also started my own Adapter, based on your prisma adapter... to support multi-tenancy in database. Pretty much everything you have as-is, plus associating users with a Business (tenant) record.

Excellent work with next-auth. So helpful.

[dhalbrook]

We really need this as well, as we have a multi-tenant Next app in the works.

It seems like you could take in a callback function in the userSuppliedOptions of server/index.js that would pass the req object in, like userSuppliedOptions.baseUrlSupplier(req), to allow everyone to specify the base URL as needed from the request (in our cases tenancy has more than one potential marker). Not sure of the best way to get the derived value to jwt.js:99 though.

[dolie]

Our application is multi-tenant as well. We also need(ed) this feature.
We decided to deploy one environment for each tenants to resolve this issue.

[ChuckJonas]

I also need this to be able to properly setup salesforce as a custom oAuth2 provider:

https://${instanceUrl}.salesforce.com/services/oauth2/token

There are cases where the user will need to specify their "subdomain" in order to be able to login.

[skilesare]

I've tried to address this here: skilesare@86ea3de

It may need some changes....and I only really focused on the session call back because I needed to get some data based on the domain in the session, but the pattern should be easy to follow for the other callbacks. Basically the request (req) just needs to be passed to these callbacks so that you can key in on the domain/sub domain. The other potential gotcha is the http vs https so if anyone has a suggestion for that, let me know.

If any one wants to walk me through how to get this set up so that it can eventually be pulled in, let me know as well...haven't contributed to projects this big before and don't want to step on any toes.

[trollr]

Our application is multi-tenant as well. We also need(ed) this feature. I would like to be able to simply set the redirect_url in the provider options

[ramiel]

One good reason to think to support multi-tenant is that nex-auth is likely to be deployed on vercel. On vercel each deployment has several domains (a lot more if the user defined aliases). Since this is a project for next.js, supporting Vercel looks natural to me.

[specialfae]

+1 for multi-tenant support

[slumbering]

+1

[jukbot]

same here

[highflying]

+1, I need this too.