NEXTAUTH_URL_INTERNAL=http://nextjs:3000 fails in docker using next-auth 4.20.1

[redimongo]

Question 💬

I am having issues with this with the latest version 4.20.1 and while running in a docker container.

I am using

NEXTAUTH_URL_INTERNAL=http://nextjs:3000

as my docker name is nextjs it was working find when using 4.10.3. Tried to upgrade and bam things broke.

How to reproduce ☕️

create a docker image with a project using next-auth and start with version 4.10.3 then try and upgrade it and you run into issues

NEXTAUTH_URL_INTERNAL=http://nextjs:3000

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[stevejay]

I am also seeing this when running in Docker and with a NEXTAUTH_URL_INTERNAL value set. I use the Keycloak provider. When logging in, the redirect_uri is now being set to that internal url.

I believe the cause is the PR to priortize NEXTAUTH_URL_INTERNAL, which was merged into the v4 branch a couple of weeks ago. If I patch out that change then the redirect_uri parameter is set as it used to be.

[redimongo]

The problem is that on the client end I am seeing when I visit https://(SITEURL).com/api/auth/signin?callbackUrl=https%3A%2F%2F(SITEURL).com%2Fstaff

<form action="http://nextjs:3000/api/auth/callback/credentials" method="POST">

clearly that is meant to be my NEXTAUTH_URL

how can I fix this?

<div class="card">
    <img src="https://storage.googleapis.com/radiomedia-images/station_logos/v2/DRN1_small.png" alt="Logo" class="logo">
   <div class="provider">
<form action="http://nextjs:3000/api/auth/callback/credentials" method="POST">
    <input type="hidden" name="csrfToken" value="(REMOVED)_"><div><label class="section-header" for="input-username-for-credentials-provider">Username</label><input name="username" id="input-username-for-credentials-provider" type="text" placeholder="" label="Username"></div><div><label class="section-header" for="input-password-for-credentials-provider">Password</label><input name="password" id="input-password-for-credentials-provider" type="password" placeholder="" label="Password"></div><button type="submit">Sign in with DRN1</button></form></div></div>

[nilskaspersson-imtf]

We get a similar issue too. We use NEXTAUTH_URL_INTERNAL to facilitate communication from our Next.js application in one Docker container, to an auth provider in another container in the same Kubernetes cluster.

Since one of the latest patches, users are redirected to <podname>/api/auth/callback/<provider>?state=... when attempting to sign in, instead of to the provider's sign in page.

[genox]

Our docker based app also breaks since the PR mentioned above has been introduced. Redirects to a docker-compose service name instead of the actual hostname. Will try to downgrade to next-auth@4.19.2 and see how it goes.

Seems to break every docker based deployment.

[redimongo]

It's broken from 4.11.0 and above.

[stevejay]

@redimongo FYI we were successfully running v4.19.2 with a Next.js app in Docker without encountering the problem you described in this issue. It was only when I upgraded us to v4.20.1 that the problem occurred.

[redimongo]

@redimongo FYI we were successfully running v4.19.2 with a Next.js app in Docker without encountering the problem you described in this issue. It was only when I upgraded us to v4.20.1 that the problem occurred.

interesting, this is my .env.local

NEXTAUTH_URL_INTERNAL=http://nextjs:3000
NEXTAUTH_URL=https://drn1.com.au

could you tell me if this is the same in yours?

Should not we use our own database login and not a 3rd party login service like Google or Apple etc. Maybe that's the difference?

[soulchild]

This is breaking our app. The login button redirects the browser to the internal URL now. NextAuth 4.19.2 is the last working version.

[redimongo]

This is breaking our app. The login button redirects the browser to the internal URL now. NextAuth 4.19.2 is the last working version.

What is your .env.local file.

Trying to work out why ours is breaking from 4.11.0 and up vs other people it seems to work all the way to 4.19.2

Any assistance with why yours is working would be great.

[soulchild]

@redimongo, for us the problem only occurs on our Kubernetes environment, because the API container using next-auth needs to talk to the Kubernetes service directly, not via the FQDN. But basically our environment looks similar to yours:

NEXTAUTH_URL=https://application.my-company.net
NEXTAUTH_URL_INTERNAL=http://application-service-name

I think, the client-side of Next-Auth is not supposed to use the internal URL when the user clicks the provider "Sign in" button. In our case, hitting "Sign in" sends the browser to http://application-service-name/..., which is of course unreachable.

[soulchild]

Even weirder and worse is that with NextAuth 4.20.1 I was able to use our application without being logged-in at all!

So basically, the mechanism of using a Next middleware.ts with just:

export { default } from 'next-auth/middleware';

which is supposed to redirect the user if they're not logged in, wasn't working anymore 😱

[redimongo]

So can anyone open this as a bug and see if we can get it fixed. Otherwise am stuck using an old version

[soulchild]

I agree with @redimongo.

I discovered that the whole detectHost() stuff which was introduced by #6814 and is probably responsible for the current behavior has already been removed since 4.20.1 was released? This suggests that these areas are currently in flux anyway. I suppose the client parts (e.g. react) of next-auth should never need to use NEXTAUTH_URL_INTERNAL when constructing URLs because those URLs are almost never reachable from the public internet.

Can you shed some light on this, @balazsorban44? 🙏

[jaymefSO]

We are experiencing this issue as well running nextjs app in Docker container via AWS ECS

[clueleaf]

Here's my workaround to make v4.20.1 work the same as before.
In the Dockerfile, after yarn install or npm install:

RUN sed -i '11,14d' node_modules/next-auth/utils/detect-host.js

Note that there is no guarantee this works for future versions. Make sure the installed version of next-auth is fixed to 4.20.1

[jvineveld]

Experienced issues with the redirectURI going to the NEXTAUTH_INTERNAL url instead of the NEXTAUTH url. Took me way too long to find the cause of this redirect because it only happend one of the pipelines, where this structure was required. Have currently fixed the version to 4.19.2.

[soulchild]

I find it weird that we haven't seen a response by one of the maintainers for 2 weeks now given that multiple users are experiencing the upgrade to 4.20.1 as a breaking change. Can one of the maintainers please at least acknowledge/label this as a bug/unintended behavior?

[acidjunk]

Same error here. Wrong redirect after login, with keycloak as IDP. Pinning it to 4.19.2 fixed it

Considering this was a minor upgrade; in our case Next auth was automatically upgraded -> so kinda hard to debug...

[baptisteArno]

Yep, same issue here, wrong redirects after login and signout after updating from 4.19.2 to 4.20.1

[acidjunk]

Can someone label it as a bug?

[tungv]

I think this change causes the problem #6814

This is probably a breaking change @ThangHuuVu. If you have both NEXTAUTH_URL and NEXTAUTH_URL_INTERNAL logging in successfully will redirect you to the internal one instead of the canonical one like before.

[tungv]

it's hard to believe that the PR didn't pass checks and has no regression tests. The checklist in the template wasn't even checked.

[Kiborgik]

RUN sed -i '11,14d' node_modules/next-auth/utils/detect-host.js

thank you, this fixed issue, waiting for developers fix this in their release

[ThangHuuVu]

Hi all, we're very sorry for the change in #6814 causing so much frustration for you 🙇‍♂️. We're aware of this and are actively working on a solution!

[balazsorban44]

Hi, we reverted the breaking change, you can upgrade to 4.21.0!

We agree that the undocumented change was not ideal and will try to avoid similar changes in the future. 🙏💚

Have a nice day!

[julortiz]

I just added ENV HOSTNAME 0.0.0.0
And that fix the trouble to resolution the host names in the internal network of docker for NEXTAUTH_URL_INTERNAL

[smehdux]

Hi,

I'm running into the same issue, without @julortiz's tip (thanks a lot by the way) I couldn't resolve the problem

Versions used:

    "next": "^14.0.4",
    "next-auth": "^4.24.5"

[murillo-vx]

i'm use this version, but same problem. Can you share your .env?

NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_URL_INTERNAL=http://checkout_next:3000

[smehdux]

i'm use this version, but same problem. Can you share your .env?

NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_URL_INTERNAL=http://checkout_next:3000

I've just:
NEXTAUTH_URL=http://localhost:3000

[murillo-vx]

I don't know why, but i get this error when i run with docker, but with npm run works

POST http://localhost:3000/api/auth/callback/credentials 401 (Unauthorized)

My DockerFile

FROM node:20-alpine

WORKDIR /var/www/checkout-frontend

COPY --chown=node:node package*.json ./

RUN npm install


COPY --chown=node:node . .

EXPOSE 3000

USER node

ENV HOSTNAME 0.0.0.0

CMD ["npm", "run", "dev"]`

my docker-compose

services:
  next-app:
    container_name: checkout_next
    working_dir: /var/www/checkout-frontend
    restart: always
    ports:
      - 3000:3000
    build:
      context: ./
      dockerfile: .docker/Dockerfile
    image: checkout_next
    volumes:
      - ./:/var/www/checkout-frontend
    networks:
      - checkout-network

networks:
  checkout-network:
    driver: bridge

My .env

NEXTAUTH_URL=http://localhost:3000 NEXTAUTH_URL_INTERNAL=http://checkout_next:3000 NEXTAUTH_SECRET=testeSecret

[smehdux]

Are you using oidc with a IDP like keycloack?

[murillo-vx]

No, i'm using credentials by next-auth

[yuggysaputra7]

No, i'm using credentials by next-auth

have you found the solution?

[benjaminnkem]

Have you found the solution? @murillo-vx

[Tekaichi]

This does not appear to be solved, why was it closed ? Is there an workound ?

[baptisteArno]

Please open a new issue if you think there is a bug :)