github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 15:42:09 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #4722] Nuxt SSR: useFetch integration causes session to return undefined after OAuth redirect in v1.3.10/v1.3.11 #27359

New Issue
Closed
opened 2026-04-17 18:19:26 -05:00 by GiteaMirror · 22 comments
GiteaMirror commented 2026-04-17 18:19:26 -05:00
Owner
Copy Link

Originally created by @cwandev on GitHub (Sep 17, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4722

Originally assigned to: @himself65 on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

1、Use Nuxt SSR with better-auth
2、Use const { data: session } = await authClient.useSession(useFetch)
3、Login with GitHub OAuth
4、Session data is available initially
5、Page auto-refreshes after successful login
6、Session becomes null (but cookies are still present)

https://github.com/nuxt-one/nuxt-one

Current vs. Expected behavior

Current:

  • Session data available initially after login
  • Page auto-refreshes
  • session becomes null (cookies still exist)
  • Using authClient.useSession() without useFetch works fine

Expected:

  • Session should return user data, not null

What version of Better Auth are you using?

1.3.10

System info

{
  "system": {
    "platform": "darwin",
    "arch": "arm64",
    "version": "Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000",
    "release": "24.6.0",
    "cpuCount": 8,
    "cpuModel": "Apple M1 Pro",
    "totalMemory": "16.00 GB",
    "freeMemory": "0.34 GB"
  },
  "node": {
    "version": "v22.17.0",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.9.2"
  },
  "frameworks": [
    {
      "name": "vue",
      "version": "^3.5.21"
    },
    {
      "name": "nuxt",
      "version": "^4.1.2"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "drizzle",
      "version": "^0.44.5"
    }
  ],
  "betterAuth": {
    "version": "^1.3.10",
    "config": null
  }
}

Which area(s) are affected? (Select all that apply)

Client

Auth config (if applicable)

Additional context

Related: Not sure if this is related to #4578

Originally created by @cwandev on GitHub (Sep 17, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4722 Originally assigned to: @himself65 on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1、Use Nuxt SSR with better-auth 2、Use const { data: session } = await authClient.useSession(useFetch) 3、Login with GitHub OAuth 4、Session data is available initially 5、Page auto-refreshes after successful login 6、Session becomes null (but cookies are still present) https://github.com/nuxt-one/nuxt-one ### Current vs. Expected behavior Current: - Session data available initially after login - Page auto-refreshes - session becomes null (cookies still exist) - Using authClient.useSession() without useFetch works fine Expected: - Session should return user data, not null ### What version of Better Auth are you using? 1.3.10 ### System info ```bash { "system": { "platform": "darwin", "arch": "arm64", "version": "Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000", "release": "24.6.0", "cpuCount": 8, "cpuModel": "Apple M1 Pro", "totalMemory": "16.00 GB", "freeMemory": "0.34 GB" }, "node": { "version": "v22.17.0", "env": "development" }, "packageManager": { "name": "npm", "version": "10.9.2" }, "frameworks": [ { "name": "vue", "version": "^3.5.21" }, { "name": "nuxt", "version": "^4.1.2" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "drizzle", "version": "^0.44.5" } ], "betterAuth": { "version": "^1.3.10", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Client ### Auth config (if applicable) ```typescript ``` ### Additional context Related: Not sure if this is related to #4578
GiteaMirror added the locked label 2026-04-17 18:19:26 -05:00
GiteaMirror commented 2026-04-17 18:19:31 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 17, 2025):

Hi @cwandev! I'm Dosu and I’m helping the better-auth team.

This is a known issue with Nuxt SSR and better-auth's useSession when used with useFetch. After an OAuth redirect, useFetch may return undefined or null for the session, even though cookies are present. This happens because Nuxt's SSR data deduplication expects a value from useFetch, and better-auth's internal useFetch integration can interact poorly with this logic, especially if the /get-session endpoint returns an empty body when not logged in. This can cause duplicate client-side requests and session data inconsistencies [source].

Workarounds include:

  • Creating a custom useFetch wrapper that intercepts the /get-session response and always returns { session: null, data: null } instead of undefined when not logged in [source].
  • Using an auth middleware hook on the backend to ensure the /get-session endpoint always returns a consistent JSON response, even when no session exists [source].
  • Explicitly forwarding cookies from the client to the auth backend in SSR contexts, for example via a proxy or server action, to avoid redundant network requests and session loss [source].
  • Double-checking cookie settings: set sameSite: "none", secure: true, and use credentials: "include" on client fetch calls to ensure cookies are sent and received correctly, especially in cross-domain setups [source].

Recent better-auth updates (PR #3578) fixed a bug where session data from cookies was not added to the context, which could cause hooks to receive a null session after OAuth redirects. Upgrading to the latest version may help if you are affected by this bug [source].

If you want to avoid this issue entirely, using authClient.useSession() without useFetch works because it relies on a reactive store rather than an HTTP fetch, which sidesteps Nuxt's SSR data deduplication quirks [source].

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3303372134 --> @dosubot[bot] commented on GitHub (Sep 17, 2025): <!-- Greeting --> Hi @cwandev! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This is a known issue with Nuxt SSR and better-auth's useSession when used with useFetch. After an OAuth redirect, useFetch may return undefined or null for the session, even though cookies are present. This happens because Nuxt's SSR data deduplication expects a value from useFetch, and better-auth's internal useFetch integration can interact poorly with this logic, especially if the /get-session endpoint returns an empty body when not logged in. This can cause duplicate client-side requests and session data inconsistencies [[source](https://github.com/better-auth/better-auth/issues/2178)]. Workarounds include: - Creating a custom useFetch wrapper that intercepts the /get-session response and always returns `{ session: null, data: null }` instead of undefined when not logged in [[source](https://github.com/better-auth/better-auth/issues/1707#issuecomment-2751842135)]. - Using an auth middleware hook on the backend to ensure the /get-session endpoint always returns a consistent JSON response, even when no session exists [[source](https://github.com/better-auth/better-auth/issues/1707#issuecomment-2751842135)]. - Explicitly forwarding cookies from the client to the auth backend in SSR contexts, for example via a proxy or server action, to avoid redundant network requests and session loss [[source](https://github.com/better-auth/better-auth/issues/1752#issuecomment-2958390860)]. - Double-checking cookie settings: set `sameSite: "none"`, `secure: true`, and use `credentials: "include"` on client fetch calls to ensure cookies are sent and received correctly, especially in cross-domain setups [[source](https://github.com/better-auth/better-auth/issues/3401#issuecomment-3139743392)]. Recent better-auth updates (PR #3578) fixed a bug where session data from cookies was not added to the context, which could cause hooks to receive a null session after OAuth redirects. Upgrading to the latest version may help if you are affected by this bug [[source](https://github.com/better-auth/better-auth/pull/3578)]. If you want to avoid this issue entirely, using `authClient.useSession()` without useFetch works because it relies on a reactive store rather than an HTTP fetch, which sidesteps Nuxt's SSR data deduplication quirks [[source](https://github.com/better-auth/better-auth/issues/1070#issuecomment-2995761701)]. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/abb0cb26-b510-49a2-b30a-74aa716b31f3?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4722)
GiteaMirror commented 2026-04-17 18:19:32 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 17, 2025):

does it same when disable SSR?

<!-- gh-comment-id:3304835572 --> @himself65 commented on GitHub (Sep 17, 2025): does it same when disable SSR?
GiteaMirror commented 2026-04-17 18:19:33 -05:00
Author
Owner
Copy Link

@cwandev commented on GitHub (Sep 18, 2025):

does it same when disable SSR?

It works fine when SSR is disabled.

<!-- gh-comment-id:3305970647 --> @cwandev commented on GitHub (Sep 18, 2025): > does it same when disable SSR? It works fine when SSR is disabled.
GiteaMirror commented 2026-04-17 18:19:35 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 18, 2025):

Thanks, I will have a try

<!-- gh-comment-id:3309696044 --> @himself65 commented on GitHub (Sep 18, 2025): Thanks, I will have a try
GiteaMirror commented 2026-04-17 18:19:37 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 18, 2025):

Hello, I've tried and it works well

Image
<!-- gh-comment-id:3309720770 --> @himself65 commented on GitHub (Sep 18, 2025): Hello, I've tried and it works well <img width="1512" height="905" alt="Image" src="https://github.com/user-attachments/assets/8bb54ec2-ed61-4ae5-836b-73ef20772410" />
GiteaMirror commented 2026-04-17 18:19:39 -05:00
Author
Owner
Copy Link

@cwandev commented on GitHub (Sep 19, 2025):

Hey! @himself65 Thanks for taking the time to look into this issue! 🙏

Did you upgrade better-auth to the latest version when testing?

The reason I’m still on 1.3.9 is because that version works fine without the problem.

The behavior after 1.3.10 is as follows:

Image

<!-- gh-comment-id:3310174975 --> @cwandev commented on GitHub (Sep 19, 2025): Hey! @himself65 Thanks for taking the time to look into this issue! 🙏 Did you upgrade `better-auth` to the latest version when testing? > The reason I’m still on 1.3.9 is because that version works fine without the problem. --- The behavior after `1.3.10` is as follows: ![Image](https://github.com/user-attachments/assets/9747603e-fb9c-44d7-9d12-858660b01d67)
GiteaMirror commented 2026-04-17 18:19:41 -05:00
Author
Owner
Copy Link

@Q16solver commented on GitHub (Sep 19, 2025):

Yes, having the same issue, so pinned better-auth to v1.3.9 for now

<!-- gh-comment-id:3310334763 --> @Q16solver commented on GitHub (Sep 19, 2025): Yes, having the same issue, so pinned better-auth to v1.3.9 for now
GiteaMirror commented 2026-04-17 18:19:42 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 19, 2025):

Oh I didn't see it's 139. let me try again

<!-- gh-comment-id:3310465424 --> @himself65 commented on GitHub (Sep 19, 2025): Oh I didn't see it's 139. let me try again
GiteaMirror commented 2026-04-17 18:19:43 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 19, 2025):

Ok, I see the issue now. let me double check

<!-- gh-comment-id:3310472944 --> @himself65 commented on GitHub (Sep 19, 2025): Ok, I see the issue now. let me double check
GiteaMirror commented 2026-04-17 18:19:44 -05:00
Author
Owner
Copy Link

@aveliino88 commented on GitHub (Sep 20, 2025):

import { authClient } from "@/lib/auth-client";
export default defineNuxtRouteMiddleware(async (to, from) => {
const { data: session } = await authClient.getSession();
if (!session?.user) {
if (to.path.startsWith("/dashboard")) {
return navigateTo("/login");
}
}
if (session?.user) {
if (to.path === "/login" || to.path === "/signup") {
return navigateTo("/dashboard");
}
}
});

if I use this method getSession it works .

Update: I need to clarify because I couldn't get my middleware to work properly on a nuxt ssr app latest version + latest better-auth. until I move away from the method suggested in official docs to getSession() method. Basically useFetch that is used by nuxt will break your better auth.

<!-- gh-comment-id:3314611837 --> @aveliino88 commented on GitHub (Sep 20, 2025): > import { authClient } from "@/lib/auth-client"; export default defineNuxtRouteMiddleware(async (to, from) => { const { data: session } = await authClient.getSession(); if (!session?.user) { if (to.path.startsWith("/dashboard")) { return navigateTo("/login"); } } if (session?.user) { if (to.path === "/login" || to.path === "/signup") { return navigateTo("/dashboard"); } } }); if I use this method getSession it works . Update: I need to clarify because I couldn't get my middleware to work properly on a nuxt ssr app latest version + latest better-auth. until I move away from the method suggested in official docs to getSession() method. Basically useFetch that is used by nuxt will break your better auth.
GiteaMirror commented 2026-04-17 18:19:45 -05:00
Author
Owner
Copy Link

@sonicoder86 commented on GitHub (Sep 21, 2025):

I try to use it but still SSR is not working https://github.com/sonicoder86/nuxt-travel-log/pull/59
On the client it returns with getSession but not with useSession

<!-- gh-comment-id:3316072301 --> @sonicoder86 commented on GitHub (Sep 21, 2025): I try to use it but still SSR is not working https://github.com/sonicoder86/nuxt-travel-log/pull/59 On the client it returns with `getSession` but not with `useSession`
GiteaMirror commented 2026-04-17 18:19:46 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 22, 2025):

Hi, I will try to try this again

<!-- gh-comment-id:3320183061 --> @himself65 commented on GitHub (Sep 22, 2025): Hi, I will try to try this again
GiteaMirror commented 2026-04-17 18:19:46 -05:00
Author
Owner
Copy Link

@sonicoder86 commented on GitHub (Sep 22, 2025):

Temporary workaround is to call the session endpoint:

export default defineNuxtRouteMiddleware(async (to) => {
  if (to.path === "/dashboard") {
    const result = await useFetch("/api/auth/get-session");

    if (!result.data.value) {
      return navigateTo("/");
    }
  }
});
<!-- gh-comment-id:3320538089 --> @sonicoder86 commented on GitHub (Sep 22, 2025): Temporary workaround is to call the session endpoint: ```typescript export default defineNuxtRouteMiddleware(async (to) => { if (to.path === "/dashboard") { const result = await useFetch("/api/auth/get-session"); if (!result.data.value) { return navigateTo("/"); } } }); ```
GiteaMirror commented 2026-04-17 18:19:47 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 22, 2025):

Hi all, I deployed the demo here, and I still didn't see the issue

https://github.com/himself65/next-one-demo

Please give me more context

<!-- gh-comment-id:3320596440 --> @himself65 commented on GitHub (Sep 22, 2025): Hi all, I deployed the demo here, and I still didn't see the issue https://github.com/himself65/next-one-demo Please give me more context
GiteaMirror commented 2026-04-17 18:19:48 -05:00
Author
Owner
Copy Link

@Mateleo commented on GitHub (Sep 22, 2025):

I will check that brb

<!-- gh-comment-id:3321301285 --> @Mateleo commented on GitHub (Sep 22, 2025): I will check that brb
GiteaMirror commented 2026-04-17 18:19:50 -05:00
Author
Owner
Copy Link

@sonicoder86 commented on GitHub (Sep 24, 2025):

@himself65 I've used the middleware example from the Nuxt BetterAuth documentation page

<!-- gh-comment-id:3326649635 --> @sonicoder86 commented on GitHub (Sep 24, 2025): @himself65 I've used the middleware example from the Nuxt BetterAuth documentation page
GiteaMirror commented 2026-04-17 18:19:50 -05:00
Author
Owner
Copy Link

@Mateleo commented on GitHub (Sep 24, 2025):

@sonicoder86 @himself65
When upgrading better-auth from 1.3.9 to 1.3.10 (and persisting through 1.3.16), sessions stop working. Specifically, using authClient.useSession(useFetch) no longer provides a valid session.

Repo Used
https://github.com/himself65/next-one-demo

Steps to Reproduce

  1. Clone the repo above.
  2. Run pnpm up better-auth@1.3.16.
  3. Call const { data: session } = await authClient.useSession(useFetch);.
  4. Observe that session is null / not working.

Expected Behavior

  • On 1.3.9, the session is returned correctly.
  • On 1.3.10 and later, no session is available.

Regression

  • ✅ Works on 1.3.9
  • ❌ Broken since 1.3.10

Environment

  • Package manager: pnpm
  • better-auth: 1.3.16 (broken)
  • better-auth: 1.3.9 (working)
<!-- gh-comment-id:3328807644 --> @Mateleo commented on GitHub (Sep 24, 2025): @sonicoder86 @himself65 When upgrading `better-auth` from `1.3.9` to `1.3.10` (and persisting through `1.3.16`), sessions stop working. Specifically, using `authClient.useSession(useFetch)` no longer provides a valid session. **Repo Used** [https://github.com/himself65/next-one-demo](https://github.com/himself65/next-one-demo) **Steps to Reproduce** 1. Clone the repo above. 2. Run `pnpm up better-auth@1.3.16`. 3. Call `const { data: session } = await authClient.useSession(useFetch);`. 4. Observe that `session` is `null` / not working. **Expected Behavior** * On `1.3.9`, the session is returned correctly. * On `1.3.10` and later, no session is available. **Regression** * ✅ Works on `1.3.9` * ❌ Broken since `1.3.10` **Environment** * Package manager: `pnpm` * `better-auth`: `1.3.16` (broken) * `better-auth`: `1.3.9` (working)
GiteaMirror commented 2026-04-17 18:19:51 -05:00
Author
Owner
Copy Link

@dvanmali commented on GitHub (Sep 24, 2025):

Hi @Mateleo, I ran @himself65 example and it appears to be working. Aside from hydration warnings in the console, the session is available.

<!-- gh-comment-id:3330490075 --> @dvanmali commented on GitHub (Sep 24, 2025): Hi @Mateleo, I ran @himself65 [example](https://github.com/himself65/next-one-demo) and it appears to be working. Aside from hydration warnings in the console, the session is available.
GiteaMirror commented 2026-04-17 18:19:51 -05:00
Author
Owner
Copy Link

@Mateleo commented on GitHub (Sep 24, 2025):

Hi @dvanmali, thanks for checking. I can confirm that the endpoint itself is fine, if I open http://localhost:3000/api/auth/get-session directly in the browser, I see the correct JSON session.
BUT the session is still null for me

The regression started with this commit: https://github.com/better-auth/better-auth/commit/90ea912d020e80f9417651e7f83f3cbc2dd297c1.

After this change, the Vue client calls useFetch (${baseURL}/get-session) directly.
In Nuxt SSR, that means it ends up hitting an absolute URL. Nuxt only forwards cookies automatically for relative, same-origin URLs, so on the server those cookies are dropped and the session is always null even though the endpoint is valid.

Right now, the only way I can get the session to resolve correctly is to wrap useFetch and strip the origin so it always calls a relative path:

import { useFetch } from '#app'

const relativeFetch = ((url: string, opts?: any) => {
  try {
    if (url.startsWith('http')) url = new URL(url).pathname
  } catch {}
  return useFetch(url, opts)
}) as any

const { data: session } = await authClient.useSession(relativeFetch)

This ensures Nuxt sees a same-origin relative URL, forwards cookies, and the session works as expected.

In 1.3.9, the client didn’t use baseURL way. Instead it pulled out just the .pathname with fallbacks:
(from what I understand)

let authPath = baseURL ? new URL(baseURL).pathname : "/api/auth"
authPath = authPath === "/" ? "/api/auth" : authPath
authPath = authPath.endsWith("/") ? authPath.slice(0, -1) : authPath
return useFetch(`${authPath}/get-session`, { … })
<!-- gh-comment-id:3330643270 --> @Mateleo commented on GitHub (Sep 24, 2025): Hi @dvanmali, thanks for checking. I can confirm that the endpoint itself is fine, if I open `http://localhost:3000/api/auth/get-session` directly in the browser, I see the correct JSON session. BUT the session is still null for me The regression started with this commit: [https://github.com/better-auth/better-auth/commit/90ea912d020e80f9417651e7f83f3cbc2dd297c1](https://github.com/better-auth/better-auth/commit/90ea912d020e80f9417651e7f83f3cbc2dd297c1). After this change, the Vue client calls `useFetch` (${baseURL}/get-session) directly. In Nuxt SSR, that means it ends up hitting an **absolute URL**. Nuxt only forwards cookies automatically for **relative, same-origin** URLs, so on the server those cookies are dropped and the session is always `null` even though the endpoint is valid. Right now, the only way I can get the session to resolve correctly is to wrap `useFetch` and strip the origin so it always calls a relative path: ```ts import { useFetch } from '#app' const relativeFetch = ((url: string, opts?: any) => { try { if (url.startsWith('http')) url = new URL(url).pathname } catch {} return useFetch(url, opts) }) as any const { data: session } = await authClient.useSession(relativeFetch) ``` This ensures Nuxt sees a same-origin relative URL, forwards cookies, and the session works as expected. In `1.3.9`, the client didn’t use `baseURL` way. Instead it pulled out just the `.pathname` with fallbacks: (from what I understand) ```ts let authPath = baseURL ? new URL(baseURL).pathname : "/api/auth" authPath = authPath === "/" ? "/api/auth" : authPath authPath = authPath.endsWith("/") ? authPath.slice(0, -1) : authPath return useFetch(`${authPath}/get-session`, { … }) ```
GiteaMirror commented 2026-04-17 18:19:52 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 24, 2025):

Hi @dvanmali, thanks for checking. I can confirm that the endpoint itself is fine, if I open http://localhost:3000/api/auth/get-session directly in the browser, I see the correct JSON session. BUT the session is still null for me

The regression started with this commit: 90ea912.

After this change, the Vue client calls useFetch (${baseURL}/get-session) directly. In Nuxt SSR, that means it ends up hitting an absolute URL. Nuxt only forwards cookies automatically for relative, same-origin URLs, so on the server those cookies are dropped and the session is always null even though the endpoint is valid.

Right now, the only way I can get the session to resolve correctly is to wrap useFetch and strip the origin so it always calls a relative path:

import { useFetch } from '#app'

const relativeFetch = ((url: string, opts?: any) => {
try {
if (url.startsWith('http')) url = new URL(url).pathname
} catch {}
return useFetch(url, opts)
}) as any

const { data: session } = await authClient.useSession(relativeFetch)
This ensures Nuxt sees a same-origin relative URL, forwards cookies, and the session works as expected.

In 1.3.9, the client didn’t use baseURL way. Instead it pulled out just the .pathname with fallbacks: (from what I understand)

let authPath = baseURL ? new URL(baseURL).pathname : "/api/auth"
authPath = authPath === "/" ? "/api/auth" : authPath
authPath = authPath.endsWith("/") ? authPath.slice(0, -1) : authPath
return useFetch(${authPath}/get-session, { … })

This should get fixed in a208c09894.

And if you think baseURL is set wrong. Could you just change the options.baseURL to see if it works?

<!-- gh-comment-id:3330756071 --> @himself65 commented on GitHub (Sep 24, 2025): > Hi [@dvanmali](https://github.com/dvanmali), thanks for checking. I can confirm that the endpoint itself is fine, if I open `http://localhost:3000/api/auth/get-session` directly in the browser, I see the correct JSON session. BUT the session is still null for me > > The regression started with this commit: [90ea912](https://github.com/better-auth/better-auth/commit/90ea912d020e80f9417651e7f83f3cbc2dd297c1). > > After this change, the Vue client calls `useFetch` (${baseURL}/get-session) directly. In Nuxt SSR, that means it ends up hitting an **absolute URL**. Nuxt only forwards cookies automatically for **relative, same-origin** URLs, so on the server those cookies are dropped and the session is always `null` even though the endpoint is valid. > > Right now, the only way I can get the session to resolve correctly is to wrap `useFetch` and strip the origin so it always calls a relative path: > > import { useFetch } from '#app' > > const relativeFetch = ((url: string, opts?: any) => { > try { > if (url.startsWith('http')) url = new URL(url).pathname > } catch {} > return useFetch(url, opts) > }) as any > > const { data: session } = await authClient.useSession(relativeFetch) > This ensures Nuxt sees a same-origin relative URL, forwards cookies, and the session works as expected. > > In `1.3.9`, the client didn’t use `baseURL` way. Instead it pulled out just the `.pathname` with fallbacks: (from what I understand) > > let authPath = baseURL ? new URL(baseURL).pathname : "/api/auth" > authPath = authPath === "/" ? "/api/auth" : authPath > authPath = authPath.endsWith("/") ? authPath.slice(0, -1) : authPath > return useFetch(`${authPath}/get-session`, { … }) This should get fixed in https://github.com/better-auth/better-auth/commit/a208c0989455cba0843cd34679618c457fe05c62. And if you think baseURL is set wrong. Could you just change the options.baseURL to see if it works?
GiteaMirror commented 2026-04-17 18:19:53 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 24, 2025):

I guess you have NUXT_PUBLIC_BETTER_AUTH_URL or NUXT_PUBLIC_AUTH_URL. Please unset the variable for the single domain app

<!-- gh-comment-id:3330897459 --> @himself65 commented on GitHub (Sep 24, 2025): I guess you have `NUXT_PUBLIC_BETTER_AUTH_URL` or `NUXT_PUBLIC_AUTH_URL`. Please unset the variable for the single domain app
GiteaMirror commented 2026-04-17 18:19:54 -05:00
Author
Owner
Copy Link

@cwandev commented on GitHub (Sep 25, 2025):

I guess you have NUXT_PUBLIC_BETTER_AUTH_URL or NUXT_PUBLIC_AUTH_URL. Please unset the variable for the single domain app我猜您设置了 NUXT_PUBLIC_BETTER_AUTH_URL 或 NUXT_PUBLIC_AUTH_URL 变量。请为单域名应用取消该变量设置。

Thanks! After removing it, it indeed works. That’s why the same demo behaved differently — the environment variable files were not the same.

<!-- gh-comment-id:3331306124 --> @cwandev commented on GitHub (Sep 25, 2025): > I guess you have `NUXT_PUBLIC_BETTER_AUTH_URL` or `NUXT_PUBLIC_AUTH_URL`. Please unset the variable for the single domain app我猜您设置了 `NUXT_PUBLIC_BETTER_AUTH_URL` 或 `NUXT_PUBLIC_AUTH_URL` 变量。请为单域名应用取消该变量设置。 Thanks! After removing it, it indeed works. That’s why the same demo behaved differently — the environment variable files were not the same.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#27359
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?