fix(core): handle Request -> Response regressions

[balazsorban44]

#4769 was a major internal refactoring that caused some bugs to surface:

• Set-Cookie headers have been incorrectly split, which is now handled correctly (see: Use case for Headers getAll whatwg/fetch#973). Fixes Set-Cookie header is split in half by comma in Expires section #5989
• unstable_getServerSession overrode the Content-Type header, which broke the rendering of SSR pages (using getServerSideProps). Fixes 4.18.1 causes app to render in a <pre> tag when using unstable_getServerSession #5986
  - [ ] Parsing the host header has introduced some unexpected behavior in production. host detection/NEXTAUTH_URL breaks in some cases #5953 Needs more work, will follow up in a separate PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
next-auth	✅ Ready (Inspect)	Visit Preview	Dec 8, 2022 at 11:30PM (UTC)

[github-actions]

🎉 Experimental release published 📦️ on npm!

pnpm add [email protected]

yarn add [email protected]

npm i [email protected]

[ammmze]

I'm still having some issues with unstable_getServerSession after switching to [email protected].

I get an error page with the error FetchError: invalid json response body at reason: Unexpected token E in JSON at position 0.

To debug further, I modified the unstable_getServerSession function in node_modules adding the following:

console.log('request url =>', urlOrError);
console.log('response body =>', response.body.toString());

The result of these console logs are:

request url => URL {
  href: 'http:https://localhost:3000/sso/api/auth/api/auth/session',
  origin: 'http:https://localhost:3000',
  protocol: 'http:',
  username: '',
  password: '',
  host: 'localhost:3000',
  hostname: 'localhost',
  port: '3000',
  pathname: '/sso/api/auth/api/auth/session',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}
response body => Error: This action with HTTP GET is not supported by NextAuth.js

It looks like the url path is a bit wonky. The path should be /sso/api/auth/session. For some additional context, I am running my application with a base path configured in NextJS of /sso. And as a result I have NEXTAUTH_URL configured as http:https://localhost:3000/sso/api/auth (as described here).

Edit: Looks like duplication in the path isn't necessarily the cause. I temporarily changed the path in the getURL call from /api/auth/session to just /session so the result is the correct path. However, I still get the same error response body from the auth handler (Error: This action with HTTP GET is not supported by NextAuth.js).

Edit 2: But it does look like the base path is likely the main trigger here. I jumped in the AuthHanderInternal and added a console.log({method, action}); which resulted in { method: 'GET', action: 'auth' }. So it looks like it is picking up the wrong action.

[ammmze]

Edit 2: But it does look like the base path is likely the main trigger here. I jumped in the AuthHanderInternal and added a console.log({method, action}); which resulted in { method: 'GET', action: 'auth' }. So it looks like it is picking up the wrong action.

Looks like one option is to update these lines in the getURL method with the following to strip any path from the host variable (which in my case is coming from the NEXTAUTH_URL:

    if (host.startsWith("http:https://") || host.startsWith("https://")) {
      return new URL(`${host.replace(/(https?:\/\/[^/]+)\/?.*/, '$1')}${url}`)
    }
    return new URL(`https://${host.replace(/([^/]+)\/?.*/, '$1')}${url}`)

[ammmze]

Edit 2: But it does look like the base path is likely the main trigger here. I jumped in the AuthHanderInternal and added a console.log({method, action}); which resulted in { method: 'GET', action: 'auth' }. So it looks like it is picking up the wrong action.

Looks like one option is to update these lines in the getURL method with the following to strip any path from the host variable (which in my case is coming from the NEXTAUTH_URL:

    if (host.startsWith("http:https://") || host.startsWith("https://")) {
      return new URL(`${host.replace(/(https?:\/\/[^/]+)\/?.*/, '$1')}${url}`)
    }
    return new URL(`https://${host.replace(/([^/]+)\/?.*/, '$1')}${url}`)

Hmm...though another issue that crops up from stripping the path from the host is that anywhere that we call that getURL with the path we then lose our base path which can lead to some invalid redirects. So I think we also need some updates to that toInternalRequest method that was added that extracts things like the action, which in gist is effectively doing action = url.pathname.split("/").slice(3)[0]. This works fine without a base path, but then add the base path and we get the wrong action...

❯ node
Welcome to Node.js v16.14.2.
Type ".help" for more information.
> '/api/auth/signin'.split('/').slice(3)
[ 'signin' ]
> '/sso/api/auth/signin'.split('/').slice(3)
[ 'auth', 'signin' ]

[ammmze]

I think we also need some updates to that toInternalRequest method

Perhaps we should do something like this in there? So basically first we take just the part of the path starting with the last /api/auth and then do the split and slice. This will give us the consistency we need in extracting the "nextauth" array.

const nextauth = url.pathname.substring(url.pathname.lastIndexOf("/api/auth")).split("/").slice(3);

[balazsorban44]

The custom basepath handling is on my todo list, it's not checked off in the description as you can see in #5991 (comment) 👍

Based on your URL http:https://localhost:3000/sso/api/auth/api/auth/session it's that.

Thanks!

[balazsorban44]

I'll merge this PR for now to fix the two other issues, I did not manage to fix this today, postponing the custom base path fix tomorrow, will follow up in a separate PR.

[ammmze]

I'll merge this PR for now to fix the two other issues, I did not manage to fix this today, postponing the custom base path fix tomorrow, will follow up in a separate PR.

Sounds good! Thank you!

[noclat]

Thanks guys, literally spent the complete past day just trying to debug CredentialsProvider (jwt ofc) not creating session cookie in prod and had absolutely no clue why, and woke up to this fix. At least I know the full NextAuth doc by heart now.