Autodetect protocol+host behind proxy without AUTH_URL env variable
#10081
Comments
deestt
added
bug
|
Something to do with the const { action, providerId } = parseActionAndProviderId(url.pathname, config.basePath);
// url.pathname '/api/auth/session'
// config.basePath '/auth'
export function parseActionAndProviderId(pathname, base) {
const a = pathname.match(new RegExp(`^${base}(.+)`));
if (a === null)
throw new UnknownAction(`Cannot parse action at ${pathname}`);
const [_, actionAndProviderId] = a;
const b = actionAndProviderId.replace(/^\//, "").split("/");
if (b.length !== 1 && b.length !== 2)
throw new UnknownAction(`Cannot parse action at ${pathname}`);
const [action, providerId] = b;
if (!isAuthAction(action))
throw new UnknownAction(`Cannot parse action at ${pathname}`);
if (providerId && !["signin", "callback", "webauthn-options"].includes(action))
throw new UnknownAction(`Cannot parse action at ${pathname}`);
return { action, providerId };
} |
|
I add in config basePath: "/' and I have new error: |
Try setting the base path to "/api/auth". |
|
I got a error |
|
Had the same problem yesterday and it disappeared after removing |
|
Hey ! I had the same problem, and it resolves after removing Peace |
|
If I delete the AUTH_URL from my environment variables, then I end up getting redirected to localhost in production? I saw on a stack overflow question to add api/auth to the end of the AUTH_URL, but then I end up with this weird bug |
|
I faced the same issue and managed to workaround the issue by setting The cause seems to be that |
|
@ChrisB1123 @bwallberg I tried to deploy in 2 different ways :
=> Deployment on vercel
For those who will tell me that my server is badly configured, no, because with NextAuth 4, I don't have any problems. (but maybe my bad if that's the case) Unfortunately, after a few hours of research yesterday, I couldn't find a solution... Perhaps @ThangHuuVu might have a solution for us ? |
|
I get the same "not a constructor" error in my azure deployment environment (works fine locally). It's coming from reqWithEnvURL However, If I remove NEXTAUTH_URL/AUTH_URL then the This is the incorrect |
|
Thanks it's working. |
|
i can confirm setting custom this issue doesn't relate to any package version issue, neither upstream nor itself |
Did you manage to fix this issue? I'm having the same one. Locally without AUTH_URL/NEXTAUTH_URL works fine, but without it it's trying to redirect to the |
No fix - I just reverted back to v5.0.0-beta.4 as mentioned above. Unfortunately that broke my |
|
@robalmeister, why was this closed? I'm still experiencing on |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Fix available here: #10094 |
because when I remove AUTH_URL it's working |
|
Hi all, quick check-in. We would like to keep things working as before though, so I appreciate the dig-deep in this issue. We will look at the PR. I honestly thought I fixed this via #9955 Explanation: It's technically always been required to have the base path defined as part of the env variable URL (
|
|
@balazsorban44 thank you for the update and for all your contributions. Some additional info: I have removed the env variable and have I am running |
|
@balazsorban44 Is there an alternative solution to setting the AUTH_URL if you are using a subdomain (http://app.localhost:3000)? When the env is not included, the authjs.callback-url cookie is set to http://localhost:3000 even if the sign in comes from the subdomain. |
|
@balazsorban44, thank you for your attention to this issue :)
I am using [email protected] in a Next.js app behind CloudFront + ALB + ECS Fargate. Based on my experience, the protocol/host is not inferred from the request headers. The CloudFront domain (i.e. d3l665bfs8sngd.cloudfront.net) is the "Host" header but the "callbackUrl" generated from next-auth is http://ip-10-0-65-125.ec2.internal (without AUTH_URL) which is tied to the local network (printed by Next.js on start up that looks like "- Local: http://ip-10-0-65-125.ec2.internal:3000"). Hopefully that demonstrates the need for AUTH_URL isn't necessarily "rare". Again, thank you for your time looking into this! |
|
It sounds like all your use cases are legit to use @prim1013 - @oscarmylla - @bestickley - Although, I think we could make these work without the env variable too, if we detect You would still need @bwallberg as such, I think #10094 won't be sufficient in its current form, as it only focuses on |
Fkn awesome response: Helpful & Robust. I'm not even involved but you deserve applause. Thanks @balazsorban44 👏🏻 🎉 |
balazsorban44
added
enhancement
balazsorban44
changed the title
AUTH_URL env variable
|
If this is implemented, it might essentially kill the need for You would only need to tweak |
|
I wouldn't mind investigating using I don't understand why the PR I created would be insufficient though? My PR solves the specific issue related to "cannot parse action at /session" for specifically next-auth and should cover all the different variations of provided However if the intention is that you must suffix the env variable with |
|
late to this party, but where exactly did this land? I am encountering the same issue where my production environment callback is directing to I tried setting I am using the below: "next": "v14.1.1-canary.76",
"next-auth": "^5.0.0-beta.13",UPDATE: "next": "v14.1.1-canary.76",
"next-auth": "^5.0.0-beta.4",I will continue to track this. |
|
Note to anyone else coming across this issue: Currently ( We're investigating detecting the proxy host and path as well so you can completely drop |
|
Sorry if it unrelated to this post but i'm getting the errors on this post here is my copy of the errors: Followed the steps provided |
|
@DuarteMartinho unfortunately we can't reopen it, it's locked. But anyway, have you set the AUTH_SECRET env var too? Make sure you set that and then try the AUYH_URL with path. Make sure youve read and follow all the setup instructions - https://authjs.dev/reference/nextjs#installation |
|
So yeah i can confirm that all the variable are set For more context here is my auth.js And app/api/auth/[...nextauth]/route.ts Can't turn on edge because of db also package.json In localhost everything works fine, the problem is when i set the ENV AUTH_URL that breaks everything let me know if you need anything else that could try help debug |
|
@DuarteMartinho ah okay great 🥳 |
Pour moi à marcher correctement. Merci beaucoup |
|
so what's the final solution for the production behind proxy, in production problem 1 {"credentials":{"id":"credentials","name":"Credentials","type":"credentials","signinUrl":"http://localhost:3000/api/auth/signin/credentials","callbackUrl":"http://localhost:3000/api/auth/callback/credentials"}}problem 2 I got error version "next-auth": "5.0.0-beta.13",also "next-auth": "5.0.0-beta.15", |
|
still getting this issue with beta.20 it just started ocuring out of the blue had it working before, but the working code not working anymore. removing auth_url will direct to localhost in production |
|
We encountered a similar issue and here’s how we resolved it. ` const nextAuthResult = NextAuth(entraAuthConfig); const DEFAULT_AUTH_API_PATH = '/api/auth'; // A work around for the inferred type error TS2742 const proxyHandler = (handler: (req: NextRequest) => Promise) => { }; export const handlers = { GET: proxyHandler(GET), POST: proxyHandler(POST) } as const; export const { signIn, signOut } = nextAuthResult; |
and others
Environment
System:
OS: Windows 11 10.0.22631
CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
Memory: 1.05 GB / 15.91 GB
Binaries:
Node: 18.17.0 - C:\Program Files\nodejs\node.EXE
Yarn: 4.1.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 10.4.0 - C:\Program Files\nodejs\npm.CMD
pnpm: 8.6.1 - ~\AppData\Local\pnpm\pnpm.EXE
Browsers:
Edge: Chromium (121.0.2277.128)
Internet Explorer: 11.0.22621.1
npmPackages:
@auth/core: latest => 0.27.0
@auth/prisma-adapter: ^1.4.0 => 1.4.0
next: latest => 14.1.0
next-auth: 5.0.0-beta.11 => 5.0.0-beta.11
react: ^18.2.0 => 18.2.0
Reproduction URL
https://github.com/robalmeister/next-auth-example/
Describe the issue
How to reproduce
try to signin
Expected behavior
signin page
The text was updated successfully, but these errors were encountered: