github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-22 06:16:18 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #2962] Authentication cookies not being set on cross-domain requests (307 redirect, no Set-Cookie) #9416

New Issue
Closed
opened 2026-04-13 04:52:18 -05:00 by GiteaMirror · 14 comments
GiteaMirror commented 2026-04-13 04:52:18 -05:00
Owner
Copy Link

Originally created by @RikhiSingh on GitHub (Jun 9, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2962

Originally assigned to: @himself65 on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

I have a scenario where a single hono api serves different frontends
the api is at domain a.com
frontends are at domain b.com, c.com, etc

I set config like this

defaultCookieAttributes: {
  httpOnly: true,
  path: '/',
  sameSite: 'none',
  secure: true,
 },


but no luck. 

Is there anything I'm missing or is this case not possible?

Client has this enabled:
fetchOptions: {
 credentials: 'include',
},

Allowed origins all set

Current vs. Expected behavior

Current Behavior

When I call my Hono API (hosted at a.com) from front-ends on b.com, c.com, etc., with

and my cookie config set to

defaultCookieAttributes: {
  httpOnly: true,
  path: '/',
  sameSite: 'none',
  secure: true,
},

the browser issues a 307 redirect but never stores any Set-Cookie header. The session cookie never appears in devtools → Application → Cookies.

Expected Behavior

  • Browser should follow the 307 redirect and honor the Set-Cookie header on the final response

  • A cross-site cookie with SameSite=None; Secure should be created for better_auth.session_token (or whatever name), so that subsequent requests include the session and keep me logged in.

What version of Better Auth are you using?

1.2.7

Provide environment information

- OS: Windows 11, Fedora, MacOS
- Browser - Brave Browser, Google Chrome, MS Edge

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

Client

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response

Originally created by @RikhiSingh on GitHub (Jun 9, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2962 Originally assigned to: @himself65 on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce I have a scenario where a single hono api serves different frontends the api is at domain a.com frontends are at domain b.com, c.com, etc I set config like this ``` defaultCookieAttributes: { httpOnly: true, path: '/', sameSite: 'none', secure: true, }, but no luck. Is there anything I'm missing or is this case not possible? Client has this enabled: fetchOptions: { credentials: 'include', }, ``` Allowed origins all set ### Current vs. Expected behavior ### Current Behavior When I call my Hono API (hosted at `a.com`) from front-ends on `b.com`, `c.com`, etc., with and my cookie config set to ``` defaultCookieAttributes: { httpOnly: true, path: '/', sameSite: 'none', secure: true, }, ``` the browser issues a 307 redirect but never stores any Set-Cookie header. The session cookie never appears in devtools → Application → Cookies. ### Expected Behavior - Browser should follow the 307 redirect and honor the Set-Cookie header on the final response - A cross-site cookie with SameSite=None; Secure should be created for better_auth.session_token (or whatever name), so that subsequent requests include the session and keep me logged in. ### What version of Better Auth are you using? 1.2.7 ### Provide environment information ```bash - OS: Windows 11, Fedora, MacOS - Browser - Brave Browser, Google Chrome, MS Edge ``` ### Which area(s) are affected? (Select all that apply) Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-13 04:52:18 -05:00
GiteaMirror commented 2026-04-13 04:52:20 -05:00
Author
Owner
Copy Link

@Shorno commented on GitHub (Jun 11, 2025):

Im getting 307, on localhost also production all of sudden. Don't know what happed, tried to use cached cookies, enabled cookies. Is is a bug?

<!-- gh-comment-id:2961471014 --> @Shorno commented on GitHub (Jun 11, 2025): Im getting 307, on localhost also production all of sudden. Don't know what happed, tried to use cached cookies, enabled cookies. Is is a bug?
GiteaMirror commented 2026-04-13 04:52:21 -05:00
Author
Owner
Copy Link

@Rieranthony commented on GitHub (Jun 12, 2025):

I have the same behaviour with a similar tech stack!

<!-- gh-comment-id:2966557441 --> @Rieranthony commented on GitHub (Jun 12, 2025): I have the same behaviour with a similar tech stack!
GiteaMirror commented 2026-04-13 04:52:22 -05:00
Author
Owner
Copy Link

@hubert-itsharkz commented on GitHub (Jun 12, 2025):

I have a hono API running on Cloud Run and a Next.js app on Vercel. I'm also encountering this. I'm using Google social signin.

<!-- gh-comment-id:2966777072 --> @hubert-itsharkz commented on GitHub (Jun 12, 2025): I have a hono API running on Cloud Run and a Next.js app on Vercel. I'm also encountering this. I'm using Google social signin.
GiteaMirror commented 2026-04-13 04:52:22 -05:00
Author
Owner
Copy Link

@Lenghak commented on GitHub (Jun 12, 2025):

Our apps are on Coolify! Also happens all of the sudden!

<!-- gh-comment-id:2966984863 --> @Lenghak commented on GitHub (Jun 12, 2025): Our apps are on Coolify! Also happens all of the sudden!
GiteaMirror commented 2026-04-13 04:52:23 -05:00
Author
Owner
Copy Link

@bohdan-trilitech commented on GitHub (Jun 13, 2025):

Hi!
We're facing similar issue. On the localhost everything seems fine but when app is deployed cookies are not set after successful log in with google.
Tech stack:

  • API server: Hono Deno deployed to Google CloudRun
  • DB: Google Cloud SQL postgres + drizzle orm
  • FE: next.js on Vercel

better-auth config:

export const auth = betterAuth({
  baseURL: env.AUTH_URL,
  secret: env.AUTH_SECRET,
  database: drizzleAdapter(db, {
    provider: "pg",
    schema: {
      //schemas
    },
  }),

  advanced: {
    defaultCookieAttributes: {
      secure: true,
      httpOnly: true,
      sameSite: "none",
      partitioned: true,
    },
    cookies: {
      session_token: {
        name: "session_token",
      },
    },
  },

  socialProviders: {
    google: {
      clientId: env.GOOGLE_CLIENT_ID,
      clientSecret: env.GOOGLE_CLIENT_SECRET,
    },
  },

  trustedOrigins: ["http://localhost:3000", "*.vercel.app"],
});

Package versions:

deno@2.2.9
hono/hono@^4.7.11
better-auth@^1.2.9
drizzle-orm@~0.44.2

next@15.3.3
react:@^19.1.0
<!-- gh-comment-id:2969322356 --> @bohdan-trilitech commented on GitHub (Jun 13, 2025): Hi! We're facing similar issue. On the localhost everything seems fine but when app is deployed cookies are not set after successful log in with google. Tech stack: - API server: Hono Deno deployed to Google CloudRun - DB: Google Cloud SQL postgres + drizzle orm - FE: next.js on Vercel better-auth config: ```ts export const auth = betterAuth({ baseURL: env.AUTH_URL, secret: env.AUTH_SECRET, database: drizzleAdapter(db, { provider: "pg", schema: { //schemas }, }), advanced: { defaultCookieAttributes: { secure: true, httpOnly: true, sameSite: "none", partitioned: true, }, cookies: { session_token: { name: "session_token", }, }, }, socialProviders: { google: { clientId: env.GOOGLE_CLIENT_ID, clientSecret: env.GOOGLE_CLIENT_SECRET, }, }, trustedOrigins: ["http://localhost:3000", "*.vercel.app"], }); ``` Package versions: ``` deno@2.2.9 hono/hono@^4.7.11 better-auth@^1.2.9 drizzle-orm@~0.44.2 next@15.3.3 react:@^19.1.0 ```
GiteaMirror commented 2026-04-13 04:52:27 -05:00
Author
Owner
Copy Link

@naufalw commented on GitHub (Jun 14, 2025):

I am also encountering this!

EDIT: strangely, now it works on mine. for context I'm using hono and tanstack start deployed on cloudflare workers

<!-- gh-comment-id:2972504091 --> @naufalw commented on GitHub (Jun 14, 2025): I am also encountering this! EDIT: strangely, now it works on mine. for context I'm using hono and tanstack start deployed on cloudflare workers
GiteaMirror commented 2026-04-13 04:52:29 -05:00
Author
Owner
Copy Link

@Rieranthony commented on GitHub (Jun 14, 2025):

I have the same issue, this is driving me crazy 🥲 I have been stuck for few days on this for a new project. Everything seems fine on local, but it doesn't work on prod.

<!-- gh-comment-id:2972729096 --> @Rieranthony commented on GitHub (Jun 14, 2025): I have the same issue, this is driving me crazy 🥲 I have been stuck for few days on this for a new project. Everything seems fine on local, but it doesn't work on prod.
GiteaMirror commented 2026-04-13 04:52:32 -05:00
Author
Owner
Copy Link

@Lenghak commented on GitHub (Jun 17, 2025):

Please add nextCookies plugin at the end, for Next app.

<!-- gh-comment-id:2979702842 --> @Lenghak commented on GitHub (Jun 17, 2025): Please add `nextCookies` plugin at the end, for Next app.
GiteaMirror commented 2026-04-13 04:52:33 -05:00
Author
Owner
Copy Link

@RikhiSingh commented on GitHub (Jun 17, 2025):

I have tried that earlier but did not work for me!

<!-- gh-comment-id:2980149632 --> @RikhiSingh commented on GitHub (Jun 17, 2025): I have tried that earlier but did not work for me!
GiteaMirror commented 2026-04-13 04:52:34 -05:00
Author
Owner
Copy Link

@Rieranthony commented on GitHub (Jun 19, 2025):

Doesn't work, adding nextCookies when using better-auth with Hono breaks (cannot use the cookie lib outside of nextjs)

<!-- gh-comment-id:2987756199 --> @Rieranthony commented on GitHub (Jun 19, 2025): Doesn't work, adding `nextCookies` when using better-auth with Hono breaks (cannot use the cookie lib outside of nextjs)
GiteaMirror commented 2026-04-13 04:52:35 -05:00
Author
Owner
Copy Link

@TheOrcDev commented on GitHub (Jun 19, 2025):

I'm sharing a solution to a redirect loop issue (HTTP 307 Temporary Redirect) caused by conflicting session checks between a public route and middleware. This should help others encountering similar problems like I did.

Issue

When checking user authentication on a public route using auth.api.getSession, I redirected unauthenticated users to a login page. However, my middleware was also redirecting users based on session status, causing a 307 redirect loop.

Root Cause

  1. On a public route (e.g., /), I used:

    const session = await auth.api.getSession({
     headers: await headers(),
 });

 if (!session?.user?.id) {
     redirect("/login");
 }

 const currentUser = await db.query.user.findFirst({
     where: eq(user.id, session?.user?.id),
 });

 if (!currentUser) {
     redirect("/login");
 }

 return {
     ...session,
     user: currentUser,
 };

  2. The middleware was configured to redirect authenticated users back to the public route:

    if (!sessionCookie) {
 return NextResponse.redirect(new URL("/", request.url));

}

  1. This created a loop:

    • Unauthenticated user hits / → public route redirects to /login.
    • Middleware detects no session and redirects back to /.
    • The cycle repeats, resulting in multiple 307 redirects.

Solution

To fix the loop, ensure session checks and redirects are handled consistently.

This resolved my issue, and I hope it helps others avoid similar 307 redirect loops!

<!-- gh-comment-id:2988668386 --> @TheOrcDev commented on GitHub (Jun 19, 2025): I'm sharing a solution to a redirect loop issue (HTTP 307 Temporary Redirect) caused by conflicting session checks between a public route and middleware. This should help others encountering similar problems like I did. ## Issue When checking user authentication on a public route using `auth.api.getSession`, I redirected unauthenticated users to a login page. However, my middleware was also redirecting users based on session status, causing a 307 redirect loop. ## Root Cause 1. On a public route (e.g., `/`), I used: ```javascript const session = await auth.api.getSession({ headers: await headers(), }); if (!session?.user?.id) { redirect("/login"); } const currentUser = await db.query.user.findFirst({ where: eq(user.id, session?.user?.id), }); if (!currentUser) { redirect("/login"); } return { ...session, user: currentUser, }; ``` 2. The middleware was configured to redirect authenticated users back to the public route: ```javascript if (!sessionCookie) { return NextResponse.redirect(new URL("/", request.url)); } ``` ``` 3. This created a loop: - Unauthenticated user hits `/` → public route redirects to `/login`. - Middleware detects no session and redirects back to `/`. - The cycle repeats, resulting in multiple 307 redirects. ## Solution To fix the loop, ensure session checks and redirects are handled consistently. This resolved my issue, and I hope it helps others avoid similar 307 redirect loops!
GiteaMirror commented 2026-04-13 04:52:36 -05:00
Author
Owner
Copy Link

@RikhiSingh commented on GitHub (Jun 19, 2025):

I am afraid this might work but will be erratic for other users as the get-session hook offered by better-auth is broken in forementioned version, It doesnt return fresh user if you make any changes, and also sdk should be handling this, doing it on frontend defies the purpose of server creation as it should be aware of the same.

Another know issue, headers and cookies from the next is broken too, if you write them once, and try to append, upsert or modify them in any way they do not work!

In dev you have to delete the .next folder

<!-- gh-comment-id:2988707995 --> @RikhiSingh commented on GitHub (Jun 19, 2025): I am afraid this might work but will be erratic for other users as the get-session hook offered by better-auth is broken in forementioned version, It doesnt return fresh user if you make any changes, and also sdk should be handling this, doing it on frontend defies the purpose of server creation as it should be aware of the same. Another know issue, headers and cookies from the next is broken too, if you write them once, and try to append, upsert or modify them in any way they do not work! In dev you have to delete the .next folder
GiteaMirror commented 2026-04-13 04:52:37 -05:00
Author
Owner
Copy Link

@Rieranthony commented on GitHub (Jun 24, 2025):

Would love to get some insight form @Bekacru maybe on this? I believe this is blocking a lot of folks at the moment :)

We all love better-auth, but this prevents us from using it :/

<!-- gh-comment-id:2999469485 --> @Rieranthony commented on GitHub (Jun 24, 2025): Would love to get some insight form @Bekacru maybe on this? I believe this is blocking a lot of folks at the moment :) We all love better-auth, but this prevents us from using it :/
GiteaMirror commented 2026-04-13 04:52:38 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jan 2, 2026):

Hi, @RikhiSingh. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that cross-domain requests to a Hono API cause 307 redirects, preventing browsers from storing Set-Cookie headers for authentication cookies.
  • Despite correct SameSite and Secure cookie settings, session cookies do not appear, impacting authentication flows.
  • Multiple users have confirmed the issue across different deployments, often involving Google social sign-in and Next.js frontends.
  • Suggested workarounds like the nextCookies plugin or middleware adjustments have been tried but either fail or introduce other problems.
  • This issue is currently blocking adoption of Better Auth v1.2.x and awaits input from maintainers.

Next Steps:

  • Please confirm if this issue is still relevant with the latest version of better-auth by commenting here to keep the discussion open.
  • If no response is received within 7 days, I will automatically close the issue.

Thank you for your understanding and contribution!

<!-- gh-comment-id:3705701246 --> @dosubot[bot] commented on GitHub (Jan 2, 2026): Hi, @RikhiSingh. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that cross-domain requests to a Hono API cause 307 redirects, preventing browsers from storing Set-Cookie headers for authentication cookies. - Despite correct SameSite and Secure cookie settings, session cookies do not appear, impacting authentication flows. - Multiple users have confirmed the issue across different deployments, often involving Google social sign-in and Next.js frontends. - Suggested workarounds like the nextCookies plugin or middleware adjustments have been tried but either fail or introduce other problems. - This issue is currently blocking adoption of Better Auth v1.2.x and awaits input from maintainers. **Next Steps:** - Please confirm if this issue is still relevant with the latest version of better-auth by commenting here to keep the discussion open. - If no response is received within 7 days, I will automatically close the issue. Thank you for your understanding and contribution!
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#9416
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?