Allow server-side calls to use a different URL other than NEXTAUTH_URL
Closed this issue · 17 comments
Summary of proposed feature
Allow server-side calls to use a different URL other than NEXTAUTH_URL.
Purpose of proposed feature
We'd like to use NextAuth in an environment where Pods running Next.js apps don't have access to call into NEXTAUTH_URL.
Detail about proposed feature
I am not sure - however, if you can give me a few pointers, I'd be happy to take a stab at this.
Potential problems
Not sure
Describe any alternatives you've considered
I cannot think of any
@balazsorban44 would this approach make sense? #1123
I like that approach and the PR in #1123 . It also solves on paper a problem we have. Need a way to have a different serverside vs client side NEXTAUTH_URL.
The use case where we have problems is next.js in a Kubernetes cluster. Calling back serverside the production website doesn't work, whether calling back (in our case localhost:3000) would work.
I like that approach and the PR in #1123 . It also solves on paper a problem we have. Need a way to have a different serverside vs client side NEXTAUTH_URL.
The use case where we have problems is next.js in a Kubernetes cluster. Calling back serverside the production website doesn't work, whether calling back (in our case localhost:3000) would work.
This is our exact use-case as well
@sfourdrinierlark for the time being it's published as @gergelyke/next-auth@1.0.0, in case you want to play around with it
@balazsorban44 feel free to assign this issue to me - I'll take care of it, either with that PR I sent, or if you folks have a different proposal, I'd be more than happy to take a stab at that as well
I'm proposing not to have an ENV var at all. I think having to declare an ENV var for a library is the wrong level of responsibility for a library. I should be able to configure the library with arbitrary values at runtime and those values may come from ENV vars.
I think you should add two options to the NextAuth() configuration object:
export type NextAuthProps = {
// ...
url?: string
serverURL?: string
}I'm proposing not to have an ENV var at all. I think having to declare an ENV var for a library is the wrong level of responsibility for a library. I should be able to configure the library with arbitrary values at runtime and those values may come from ENV vars.
I think you should add two options to the
NextAuth()configuration object:export type NextAuthProps = { // ... url?: string serverURL?: string }
that ship I think has already sailed - except, if we'd consider a breaking change
Hey guys 👋 I would love to see the feature landed in a future release. Is there any way I can help?
hey folks 👋 I abandoned my original PR - please feel free to take this on
Many thanks for the work already done :). @balazsorban44 so what would be the next step? Should we prioritize the dynamic NEXTAUTH_URL or the "server URL" ? (or nothing - what's your view on this ? )
🎉 This issue has been resolved in version 3.9.0 🎉
The release is available on:
Your semantic-release bot 📦🚀
Well that was fast ! I'll test it Monday. Thanks everyone, I really appreciate your work and all the effort put in this package.
Working like a charm! Double thanks !
🎉 This issue has been resolved in version 4.0.0-next.5 🎉
The release is available on:
Your semantic-release bot 📦🚀
Is there anything like this for non-NextJS applications? Ideally this would be a config option for signIn()?
This solution works for me #9785 (comment)