Open MoritzKn opened 1 year ago
I could verify that downgrading to 4.22.0 fixes the issue. Before I was using 4.22.1.
Not working for me at 4.22.0. Did you find a fix @MoritzKn ?
@powderham I couldn't find a workaround. To fix the issue in our project I simply downgrade and pinned the dependency to the 4.22.0 version. The obvious solution to the issue upstream would be to revert the commit that introduced the issue. But then that commit had a reason too and I don't know the rational behind it.
@MoritzKn did you do anything in particular when downgrading the version?
I've deleted node_modules
and .next
yet am still being served the version with https://
.
The strange thing is the offending code (as you define it above) is missing from my node_modules, so either I have something cached, or 4.22 doesn't work everywhere - I'm leaning towards the former given that it works for you on 4.22
@powderham Strange. No, I did nothing special. Maybe double-check that ./node_modules/next-auth/package.json
really is 4.22.0
?
The strange thing is the offending code (as you define it above) is missing from my node_modules
How could you tell? If you just looked at the JS you might have missed something. I'm definitely no expert in this code base but my impression was that a lot of functions are defined in multiple places. So just because you saw some JS code that looked like it could have come from the place in the TS code doesn't mean that it necessarily did. When I debugged this, I spent quite some time trying to link up the JS code I was seeing in the dev tool with the TS code from the repo.
Am also running into this issue. Tried downgrading to 4.22.0 however it did not help. Is there another workaround?
I think I've found why this happens. There's a function called detectOrigin
which will change the scheme to https
if either the VERCEL
or AUTH_TRUST_HOST
environment variables are set to a truthy value: https://github.com/nextauthjs/next-auth/blob/next-auth%404.23.1/packages/next-auth/src/utils/detect-origin.ts#L4-L5
In my case, I had VERCEL=1
in my .env file, presumably because it had been generated by the Vercel CLI. Removing this variable altogether made it work again.
Still running into this issue in 4.24.7
. Removing VERCEL=1
form the .env.local
file fixed the issue but IMO this is an ugly solution as this value is automatically generated when running vercel env pull
.
Environment
System: OS: macOS 13.2.1 CPU: (8) arm64 Apple M1 Memory: 85.16 MB / 8.00 GB Shell: 3.1.2 - /opt/homebrew/bin/fish Binaries: Node: 20.1.0 - /usr/local/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 9.6.4 - /usr/local/bin/npm Browsers: Chrome: 112.0.5615.137 Firefox: 111.0.1 Safari: 16.3
Reproduction URL
https://github.com/nextauthjs/next-auth/commit/6f9ca4143d1fbcb744cb14386acc1feebf97d588
Describe the issue
On
http://localhost:3000/api/auth/signin
the form actions usehttps
. E.g.This just started happening to me after updating dependencies. It seems the issue was introduced 3 weeks ago by the following commit:
6f9ca4143d1fbcb744cb14386acc1feebf97d588 set the
req.origin
tohttps://localhost:3000
. Before the origin would have beenundefined
:https://github.com/nextauthjs/next-auth/blob/6f9ca4143d1fbcb744cb14386acc1feebf97d588/packages/next-auth/src/core/index.ts#L80-L84
This
origin
is then used in theinit()
function: https://github.com/nextauthjs/next-auth/blob/6f9ca4143d1fbcb744cb14386acc1feebf97d588/packages/next-auth/src/core/index.ts#L139-L148And the
origin
is then passed toparseUrl()
: https://github.com/nextauthjs/next-auth/blob/6f9ca4143d1fbcb744cb14386acc1feebf97d588/packages/next-auth/src/core/init.ts#L45Because of that
parseUrl()
is not returning thedefaultUrl
as it would have before: https://github.com/nextauthjs/next-auth/blob/6f9ca4143d1fbcb744cb14386acc1feebf97d588/packages/next-auth/src/utils/parse-url.ts#L15-L23Since this URL is then used for
parseProviders()
, the providers now all have the wrong URL: https://github.com/nextauthjs/next-auth/blob/6f9ca4143d1fbcb744cb14386acc1feebf97d588/packages/next-auth/src/core/init.ts#L49-L53This totally breaks local development for me. I assume this would have been reported before but I couldn't find any issue. Maybe this step-by-step explanation still helps.
How to reproduce
I know this is shitty, but hopefully, this step-by-step explanation should be enough to understand the bug.
Expected behavior
I would expect the providers to use
http
when usinglocalhost
withhttp
.