the new useSession should use basePath settings for redirect

[Naddiseo]

Description 🐜

Follow-up for #2236 , as I was browsing the code changes I noticed that the redirect in useSession doesn't use the basePath settings that are set from NEXTAUTH_URL. We use a slightly different url paths in our project (/api/v1/auth/...) so we rely on everything being parsed from from NEXTAUTH_URL

EDIT: I'm also providing basePath to the SessionProvider to match the NEXTAUTH_URL

Is this a bug in your own project?

No

How to reproduce ☕️

• Change NEXTAUTH_URL to have a different path to usual: eg: NEXTAUTH_URL=http://localhost:3000/api/v1/auth
• Go to an authentication required page, the redirect will redirect to an invalid/404 page

Screenshots / Logs 📽

No response

Environment 🖥

next-auth@next

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[balazsorban44]

So I'm fairly sure that this is also the current behavior, and that this issue is a duplicate of #1713, but at least related.

UPDATE, on second read, I now know what you mean. You could easily use a custom `onUnauthenticated method though, if you saw rest of the PR.

UPDATE2: We could probably utilize the _apiBaseUrl though. Feel free to open a PR! 😊

[mahieyin-rahmun]

I tested this out at my local machine. Let me know if I got something wrong, but here is what I understood:

Assuming OP's description, this is sort of his folder structure:

.
├── pages
│   ├── api
│   │   └── v1
│   │       ├── auth
│   │       │   └── [...nextauth].js
... other files

and, he has set NEXTAUTH_URL in his .env file to be:

NEXTAUTH_URL=http://localhost:3000/api/v1

Now, with the way environment variables work, they won't be available client-side. If we take a look at the parseUrl() implementation, which is what _apiBaseUrl() relies on:

// Default values
const defaultHost = 'http://localhost:3000'
const defaultPath = '/api/auth'

if (!url) { url = `${defaultHost}${defaultPath}` }

This right here is the problem. The hardcoded values should instead refer to the environment variable. But, since we do not have an environment variable access client-side, initially I thought

"maybe we can use window.location.pathname as the value of defaultPath",

but this will break other parts of the application that rely on _apiBaseUrl(), e.g. the following snippet will break, since it tries to ping http://session

// We should always update if we don't have a client session yet
// or if there are events from other tabs/windows
if (storageEvent || __NEXTAUTH._session === undefined) {
  __NEXTAUTH._lastSync = _now()
  __NEXTAUTH._session = await getSession({
    broadcast: !storageEvent,
  })
  setSession(__NEXTAUTH._session)
  return
}

So, the only real solutions would be:

1. Use a prop in Provider to pass the client-side baseUrl
2. Use NEXT_PUBLIC_ prefix to declare a second variable in .env.local file

Then, parseUrl() needs to use process.env.NEXT_PUBLIC_NEXTAUTH_URL if the url parameter it got is undefined, because then it is on the client side.

[Naddiseo]

@mahieyin-rahmun, Sorry, I also missed in my description that I'm also setting basePath in the Provider. I'll edit my original to reflect that.

I do agree that the "best" way of fixing this is to use NEXT_PUBLIC_NEXTAUTH_URL though, and your PR would accomplish what I'm looking for! I think there are a few other bugs asking for NEXT_PUBLIC_NEXTAUTH_URL

[mahieyin-rahmun]

@mahieyin-rahmun, Sorry, I also missed in my description that I'm also setting basePath in the Provider. I'll edit my original to reflect that.

I see. Even if you do that, as you pointed out, the current signin flow doesn't make use of the passed prop. Whether we go with solution 1 or 2, a refactor of the core client module is needed to make this work 😅

I believe if the core team agrees to introduce the new environment variable, the necessary refactors could be done. But, that would be something that should only go live with v4, as it would be a big breaking change, and several parts of the documentation will require review and hence change.

[lenzi-e]

Are there any updates on this? I believe I'm running into the same issue and am very blocked. I need my next-auth REST calls to use /app/api/auth instead of /api/auth. I have the basePath and baseUrl set in the SessionProvider. I also have the NEXTAUTH_URL set properly. But the redirects after login are still going to: /api/auth.

[Naddiseo]

@lenzi-erickson Possibly setting the pages: {} config in your backend? You may also need to duplicate the env variable and create a NEXT_PUBLIC_NEXTAUTH_URL. It depends on your setup. I've been dynamically setting the NEXTAUTH_URL depending on the referrer header (after matching against a whitelist), and also pulling the "next-auth.callback-url" cookie to verify the redirect go where I want them to.