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.

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

[SharadKumar]

Server has a todo flagged: https://github.com/nextauthjs/next-auth/blob/12a5d6b1f42707e9b5da289e58b2ec5b4de2a60c/src/server/index.js#L47-L50

JWT. GetToken can be custom though: https://github.com/nextauthjs/next-auth/blob/8115a7c66cdb1d86b0d2a0d76b9aa33c2bfaa33b/src/lib/jwt.js#L94-L103

And, for the client: https://github.com/nextauthjs/next-auth/blob/8115a7c66cdb1d86b0d2a0d76b9aa33c2bfaa33b/src/client/index.js#L24-L26

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: https://github.com/skilesare/next-auth/commit/86ea3de736d566737c2e3d9082480e30309fd5fe

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.

[balazsorban44]

To anyone reading this, please stop +1 issues, it is really not helpful, and creates noise. 😕

If you have nothing constructive to add, do click "👍" on the original comment instead.

[stale[bot]]

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!

[balazsorban44]

Could someone please confirm that this new option resolves this issue?

https://next-auth.js.org/configuration/options#nextauth_url_internal

[Robert-OP]

Hey @balazsorban44

I cannot think or figure out how https://next-auth.js.org/configuration/options#nextauth_url_internal would resolve handling multiple domains, for example, having 3 domains [.com, .io, .dk] and switching between these signing into each of them.

Do you think this may be possible with NEXTAUTH_URL_INTERNAL? 🤔

BTW I started some work regarding multi-tenancy based on what has been discussed here and @skilesare 's work in https://github.com/nextauthjs/next-auth/issues/969#issuecomment-797283379.

[balazsorban44]

I see, thanks for the update! To be honest, I haven't really looked into this use-case yet, so I wasn't entirely sure what was needed. So I am not going to close this for now.

[Robert-OP]

@balazsorban44 - is there a place to talk (besides GitHub, like a Slack/Discord) for NextAuth community? Also, could you point me out to docs on how to best test, build, and package my solution to do something in my current environment? I was thinking of building the fork and just upload it to GitHub packages.

[balazsorban44]

Either GitHub packages or npm would do. We use semantic release for automatic releases based on commit messages. The best place for community discussions are here in issues or alternatively discussions, as these are the public places where everyone can see any part of the discussion.

[Robert-OP]

I already posted a multi-tenant version (incomplete, work in progress) on npm that seems to work for my use case to some extent, still working on it and will improve. With this you need to set MULTI_TENANT="true" in environment variables (.env) such that it's picked up by the library and goes into multi-tenant mode. NOTE that the domains whitelisting still need to be included.

[andresgutgon]

Hi @Robert-OP thanks for your work. I don't see a PR for these changes in this repo, did you opened it?

[andresgutgon]

For the whitelisting couldn't be inferred from i18n config in next? https://nextjs.org/docs/advanced-features/i18n-routing ?

I guess this list is not useful for the Vercel preview use case but as @thulstrup commented could be a regexp check (option 2)

So whitelisting could be in these 2 ways:

1. i18n Next config (developer change these URL for their dev env or their staging or production)
2. Check a regexp like this: https://{process.env.VERCEL_APP}\-*.\-{process.env.VERCEL_TEAM}\.vercel\.app

I never worked with Vercel but I guess setting app and team as fixed is safe.

[Robert-OP]

Hey @andresgutgon hope you are well!

I didn't open a PR because the work is not finished yet, I didn't add the whitelisting of domains and I see that https://github.com/nextauthjs/next-auth/issues/969#issuecomment-808707545 it's not that of a good idea at least for Vercel.

The solution above works, but I think still needs a review from the next-auth team since I might overseen some important matters. 😬

[andresgutgon]

Hey! @Robert-OP I'm doing ok : )

How about this?

Regarding with next-auth team reviewing your work, wouldn't make sense to open the PR even if not finished?

I would be easy to review and give you feedback. And maybe they can point you in the right direction if your approach can be improved. I don't know Next Auth internals but I checked your commits and looks good. I don't know just an idea :)

[Robert-OP]

Hey! @Robert-OP I'm doing ok : )

How about this?

Regarding with next-auth team reviewing your work, wouldn't make sense to open the PR even if not finished?

I would be easy to review and give you feedback. And maybe they can point you in the right direction if your approach can be improved. I don't know Next Auth internals but I checked your commits and looks good. I don't know just an idea :)

I'll think about it and maybe submit a PR, needs more time to look into it and include latest changes.

Do you need this for a project?

[andresgutgon]

I mean, you already has the work started. Open the PR is just pointing to your branch :)

[tgeorgiadis]

Any update on this?

[franfj]

Hey! @Robert-OP I'm doing ok : ) How about this? Regarding with next-auth team reviewing your work, wouldn't make sense to open the PR even if not finished? I would be easy to review and give you feedback. And maybe they can point you in the right direction if your approach can be improved. I don't know Next Auth internals but I checked your commits and looks good. I don't know just an idea :)

I'll think about it and maybe submit a PR, needs more time to look into it and include latest changes.

Do you need this for a project?

Hi @Robert-OP!

Will you finally open the PR? Thanks!