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

[GH-ISSUE #4483] 2 URLs one without www and one with I'm not getting token back after social login #18582

New Issue
Closed
opened 2026-04-15 17:05:59 -05:00 by GiteaMirror · 21 comments
GiteaMirror commented 2026-04-15 17:05:59 -05:00
Owner
Copy Link

Originally created by @MariuzM on GitHub (Sep 6, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4483

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

I have an url that either can be used with www. or without www. And noticed that when doing google social login I'm not getting token back, even tho data has been send to backend and its added to database, because I'm not getting token / cookie back i cant make request via Better Auth

For now i figured that this is something todo with urls www.example.com and example.com for some reason this does not work on them. I'm using railway to host my app and there it has option to generate random url i done that added that url to google and it works. Checking again www.example.com and example.com it does not work

Current vs. Expected behavior

Auth should work and send token from www.example.com and example.com urls

What version of Better Auth are you using?

1.3.8

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": 10,
    "cpuModel": "Apple M1 Max",
    "totalMemory": "64.00 GB",
    "freeMemory": "32.31 GB"
  },
  "node": {
    "version": "v24.7.0",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "11.5.1"
  },
  "frameworks": [
    {
      "name": "fastify",
      "version": "^5.6.0"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "postgres",
      "version": "^3.4.7"
    },
    {
      "name": "drizzle",
      "version": "^0.44.5"
    },
    {
      "name": "kysely",
      "version": "^0.28.5"
    }
  ],
  "betterAuth": {
    "version": "Unknown",
    "config": null
  }
}

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

Backend

Auth config (if applicable)

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

Additional context

No response

Originally created by @MariuzM on GitHub (Sep 6, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4483 ### Is this suited for github? - [ ] Yes, this is suited for github ### To Reproduce I have an url that either can be used with www. or without www. And noticed that when doing google social login I'm not getting token back, even tho data has been send to backend and its added to database, because I'm not getting token / cookie back i cant make request via Better Auth For now i figured that this is something todo with urls www.example.com and example.com for some reason this does not work on them. I'm using railway to host my app and there it has option to generate random url i done that added that url to google and it works. Checking again www.example.com and example.com it does not work ### Current vs. Expected behavior Auth should work and send token from www.example.com and example.com urls ### What version of Better Auth are you using? 1.3.8 ### 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": 10, "cpuModel": "Apple M1 Max", "totalMemory": "64.00 GB", "freeMemory": "32.31 GB" }, "node": { "version": "v24.7.0", "env": "development" }, "packageManager": { "name": "npm", "version": "11.5.1" }, "frameworks": [ { "name": "fastify", "version": "^5.6.0" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "postgres", "version": "^3.4.7" }, { "name": "drizzle", "version": "^0.44.5" }, { "name": "kysely", "version": "^0.28.5" } ], "betterAuth": { "version": "Unknown", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### 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-15 17:05:59 -05:00
GiteaMirror commented 2026-04-15 17:06:02 -05:00
Author
Owner
Copy Link

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

This is a common issue when handling authentication across www and non-www domains. The root cause is that cookies (including session tokens) are domain-specific: a cookie set for example.com is not sent to www.example.com and vice versa unless the cookie domain is explicitly set to the root domain (e.g., .example.com). If the cookie domain is set too narrowly, tokens won't be shared between both variants, which matches your symptoms source.

For Google social login, the redirect URI must match exactly (including www or non-www) with what you register in the Google Cloud Console and what Better Auth uses internally. If there's any mismatch, the OAuth flow may appear to succeed (user is created in the DB) but the token/cookie won't be returned to the client source.

To fix this:

  • Make sure both https://example.com and https://www.example.com are registered as redirect URIs in your Google Cloud Console.
  • In your Better Auth config, set the cookie domain to .example.com so cookies are valid for both www and non-www.
  • List both domains in trustedOrigins in your Better Auth config to allow authentication flows from both origins source.

This is a config/support issue, not a bug in Better Auth itself. If you need to support both www and non-www, you must handle cookie domain and trustedOrigins explicitly.

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:3261915632 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> This is a common issue when handling authentication across www and non-www domains. The root cause is that cookies (including session tokens) are domain-specific: a cookie set for example.com is not sent to www.example.com and vice versa unless the cookie domain is explicitly set to the root domain (e.g., .example.com). If the cookie domain is set too narrowly, tokens won't be shared between both variants, which matches your symptoms [source](https://github.com/better-auth/better-auth/pull/4325). For Google social login, the redirect URI must match exactly (including www or non-www) with what you register in the Google Cloud Console and what Better Auth uses internally. If there's any mismatch, the OAuth flow may appear to succeed (user is created in the DB) but the token/cookie won't be returned to the client [source](https://github.com/better-auth/better-auth/issues/3881). To fix this: - Make sure both https://example.com and https://www.example.com are registered as redirect URIs in your Google Cloud Console. - In your Better Auth config, set the cookie domain to .example.com so cookies are valid for both www and non-www. - List both domains in trustedOrigins in your Better Auth config to allow authentication flows from both origins [source](https://github.com/better-auth/better-auth/issues/4329). This is a config/support issue, not a bug in Better Auth itself. If you need to support both www and non-www, you must handle cookie domain and trustedOrigins explicitly. <!-- 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/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/0c788ba0-06d3-41a2-b111-9ab0a2573485?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/4483)
GiteaMirror commented 2026-04-15 17:06:03 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

For now lets make sure the url without www. does work, currently testing it does not.

  • I have checked trustedOrigins it has correctly set for the URL wich is example.com
  • Google console also is correct it has example.com URL in Authorised JavaScript origins

For the client side this is how my request looks

export const API_POST_SignInWithGoogle = async () => {
  const { data, error } = await authClient.signIn.social({
    provider: 'google',
    callbackURL: `${window.location.origin}/test`,
  })
  return { data, error: error?.message }
}

What else i missed?

<!-- gh-comment-id:3261935944 --> @MariuzM commented on GitHub (Sep 6, 2025): For now lets make sure the url without www. does work, currently testing it does not. - I have checked `trustedOrigins` it has correctly set for the URL wich is `example.com` - Google console also is correct it has example.com URL in `Authorised JavaScript origins` For the client side this is how my request looks ``` export const API_POST_SignInWithGoogle = async () => { const { data, error } = await authClient.signIn.social({ provider: 'google', callbackURL: `${window.location.origin}/test`, }) return { data, error: error?.message } } ``` What else i missed?
GiteaMirror commented 2026-04-15 17:06:04 -05:00
Author
Owner
Copy Link

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

A few things to check:

  1. Make sure your Better Auth config sets the cookie domain correctly. By default, cookies are only set for the exact host, so if you want them to work for example.com (without www), you should either leave out the crossSubDomainCookies option or set advanced.crossSubDomainCookies.enabled: false. If you want cookies to work for both www and non-www, set advanced.crossSubDomainCookies.enabled: true and domain: '.example.com' docs.

  2. Ensure HTTPS is used on example.com, since secure cookies require it docs.

  3. Double-check your baseURL in Better Auth config matches the exact domain (e.g. https://example.com) and that your Google OAuth redirect URI matches this domain docs.

  4. Inspect your browser's network tab after login to see if a Set-Cookie header is present and what its attributes are (domain, path, secure, sameSite). If the cookie isn't being set, it's likely a config or environment issue source.

  5. If you use a proxy, CDN, or custom CORS middleware, make sure credentials are allowed and headers are forwarded unmodified discussion.

If you share your full Better Auth config (especially the advanced/cookie settings), I can help spot any issues.

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:3261944535 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> A few things to check: 1. Make sure your Better Auth config sets the cookie domain correctly. By default, cookies are only set for the exact host, so if you want them to work for example.com (without www), you should either leave out the crossSubDomainCookies option or set `advanced.crossSubDomainCookies.enabled: false`. If you want cookies to work for both www and non-www, set `advanced.crossSubDomainCookies.enabled: true` and `domain: '.example.com'` [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/concepts/cookies.mdx). 2. Ensure HTTPS is used on example.com, since secure cookies require it [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/reference/security.mdx). 3. Double-check your baseURL in Better Auth config matches the exact domain (e.g. `https://example.com`) and that your Google OAuth redirect URI matches this domain [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/reference/options.mdx). 4. Inspect your browser's network tab after login to see if a Set-Cookie header is present and what its attributes are (domain, path, secure, sameSite). If the cookie isn't being set, it's likely a config or environment issue [source](https://github.com/better-auth/better-auth/pull/4325). 5. If you use a proxy, CDN, or custom CORS middleware, make sure credentials are allowed and headers are forwarded unmodified [discussion](https://github.com/better-auth/better-auth/discussions/3262#discussioncomment-13666476). If you share your full Better Auth config (especially the advanced/cookie settings), I can help spot any issues. <!-- 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/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3f9cff2d-ed8d-475f-8d10-f4433cf61f95?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/4483)
GiteaMirror commented 2026-04-15 17:06:05 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

This is my better auth config

import { betterAuth } from 'better-auth'
import { drizzleAdapter } from 'better-auth/adapters/drizzle'

import * as schema from '../d.tables'
import { genId } from '../utils/generate-ids'

import { db } from './drizzle.provider'

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: 'pg',
    schema,
  }),
  secret: process.env.BETTER_AUTH_SECRET,
  advanced: {
    database: {
      generateId() {
        return genId()
      },
    },
    crossSubDomainCookies: {
      enabled: true,
      domain: 'https://example.com',
    },
  },
  trustedOrigins: ['https://example.com', 'https://web-xxxx.up.railway.app'],
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    },
  },
})

My env server

BETTER_AUTH_URL="https://server-api.up.railway.app"
BETTER_AUTH_SECRET="xxxx"
GOOGLE_CLIENT_ID="xxxx"
GOOGLE_CLIENT_SECRET="xxxx"

Everything looks correct so I'm not sure where the problem is :( pls help

<!-- gh-comment-id:3261962112 --> @MariuzM commented on GitHub (Sep 6, 2025): This is my better auth config ```typescript import { betterAuth } from 'better-auth' import { drizzleAdapter } from 'better-auth/adapters/drizzle' import * as schema from '../d.tables' import { genId } from '../utils/generate-ids' import { db } from './drizzle.provider' export const auth = betterAuth({ database: drizzleAdapter(db, { provider: 'pg', schema, }), secret: process.env.BETTER_AUTH_SECRET, advanced: { database: { generateId() { return genId() }, }, crossSubDomainCookies: { enabled: true, domain: 'https://example.com', }, }, trustedOrigins: ['https://example.com', 'https://web-xxxx.up.railway.app'], emailAndPassword: { enabled: true, }, socialProviders: { google: { clientId: process.env.GOOGLE_CLIENT_ID, clientSecret: process.env.GOOGLE_CLIENT_SECRET, }, }, }) ``` My env server ```env BETTER_AUTH_URL="https://server-api.up.railway.app" BETTER_AUTH_SECRET="xxxx" GOOGLE_CLIENT_ID="xxxx" GOOGLE_CLIENT_SECRET="xxxx" ``` Everything looks correct so I'm not sure where the problem is :( pls help
GiteaMirror commented 2026-04-15 17:06:07 -05:00
Author
Owner
Copy Link

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

Your config is almost correct, but the issue is with the cookie domain: it must not include the protocol. Change

domain: 'https://example.com',

to

domain: 'example.com',

or

domain: '.example.com',

Browsers will reject cookies with an invalid domain (including protocols), which prevents authentication from working as expected docs.

After updating, redeploy/restart your backend and clear cookies for your domain in your browser. Then retry the login flow and check if the session cookie is set. If it still doesn't work, double-check that HTTPS is used everywhere and that your CORS/proxy settings allow credentials and forward headers unmodified docs.

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:3261970286 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> Your config is almost correct, but the issue is with the cookie domain: it must not include the protocol. Change ```ts domain: 'https://example.com', ``` to ```ts domain: 'example.com', ``` or ```ts domain: '.example.com', ``` Browsers will reject cookies with an invalid domain (including protocols), which prevents authentication from working as expected [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/concepts/cookies.mdx). After updating, redeploy/restart your backend and clear cookies for your domain in your browser. Then retry the login flow and check if the session cookie is set. If it still doesn't work, double-check that HTTPS is used everywhere and that your CORS/proxy settings allow credentials and forward headers unmodified [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/concepts/cookies.mdx). <!-- 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/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/15db924a-49ed-4ad9-b946-ec2be946581b?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/4483)
GiteaMirror commented 2026-04-15 17:06:08 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

Done all the steps but still having the issue :(

<!-- gh-comment-id:3262003752 --> @MariuzM commented on GitHub (Sep 6, 2025): Done all the steps but still having the issue :(
GiteaMirror commented 2026-04-15 17:06:09 -05:00
Author
Owner
Copy Link

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

Since you've already fixed the cookie domain and followed the recommended steps, let's dig deeper. There are a few common causes for cookies not being set after social login, even when config looks correct:

  • Make sure your Better Auth config sets sameSite: "none" and secure: true for cookies, especially if your frontend and backend are on different domains or subdomains. By default, Better Auth uses SameSite=Lax, which browsers block in cross-origin scenarios. You can set this globally with:

    advanced: {
  defaultCookieAttributes: {
    sameSite: "none",
    secure: true,
    httpOnly: true,
  },
}

    Or specifically for the session cookie:

    advanced: {
  cookies: {
    session_token: {
      attributes: {
        sameSite: "none",
        secure: true,
        httpOnly: true,
      },
    },
  },
}

    Reference

  • Double-check that both frontend and backend use HTTPS everywhere, with no http/https mismatch, and that your CORS config allows credentials and matches the frontend origin exactly. If you use a proxy/CDN (like Railway, Vercel, or Cloudflare), make sure it doesn't strip or rewrite cookie headers. Reference

  • Inspect the browser's network tab after login. Look for the Set-Cookie header in the response from your backend. If it's missing or has incorrect attributes (domain, path, secure, sameSite), the browser will reject it. Also check for any errors or warnings in the browser console.

  • Confirm that your callbackURL in the client matches the registered Google redirect URI exactly (including protocol and domain), and that the backend receives the OAuth callback. If the callback doesn't reach your backend, the user will be created but no session cookie will be set. Reference

If you can share the full response headers (especially Set-Cookie) from the network tab after login, and clarify your frontend/backend domain setup and any proxies/CDNs in use, I can help pinpoint the issue.

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:3262039108 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> Since you've already fixed the cookie domain and followed the recommended steps, let's dig deeper. There are a few common causes for cookies not being set after social login, even when config looks correct: - Make sure your Better Auth config sets `sameSite: "none"` and `secure: true` for cookies, especially if your frontend and backend are on different domains or subdomains. By default, Better Auth uses `SameSite=Lax`, which browsers block in cross-origin scenarios. You can set this globally with: ```ts advanced: { defaultCookieAttributes: { sameSite: "none", secure: true, httpOnly: true, }, } ``` Or specifically for the session cookie: ```ts advanced: { cookies: { session_token: { attributes: { sameSite: "none", secure: true, httpOnly: true, }, }, }, } ``` [Reference](https://github.com/better-auth/better-auth/issues/3470) - Double-check that both frontend and backend use HTTPS everywhere, with no http/https mismatch, and that your CORS config allows credentials and matches the frontend origin exactly. If you use a proxy/CDN (like Railway, Vercel, or Cloudflare), make sure it doesn't strip or rewrite cookie headers. [Reference](https://github.com/better-auth/better-auth/issues/3938) - Inspect the browser's network tab after login. Look for the `Set-Cookie` header in the response from your backend. If it's missing or has incorrect attributes (domain, path, secure, sameSite), the browser will reject it. Also check for any errors or warnings in the browser console. - Confirm that your callbackURL in the client matches the registered Google redirect URI exactly (including protocol and domain), and that the backend receives the OAuth callback. If the callback doesn't reach your backend, the user will be created but no session cookie will be set. [Reference](https://github.com/better-auth/better-auth/issues/3881) If you can share the full response headers (especially `Set-Cookie`) from the network tab after login, and clarify your frontend/backend domain setup and any proxies/CDNs in use, I can help pinpoint the issue. <!-- 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/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4876640a-e948-4c99-ade8-0642a85d6c65?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/4483)
GiteaMirror commented 2026-04-15 17:06:10 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

so i use hostinger via cloudflare how can i check on cloudflare this strip or rewrite cookie headers?

<!-- gh-comment-id:3262049197 --> @MariuzM commented on GitHub (Sep 6, 2025): so i use hostinger via cloudflare how can i check on cloudflare this strip or rewrite cookie headers?
GiteaMirror commented 2026-04-15 17:06:12 -05:00
Author
Owner
Copy Link

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

Cloudflare can silently strip or rewrite Set-Cookie headers, which breaks authentication flows that rely on cookies. To check if this is happening:

  1. Open your browser's network tab and inspect the response from your backend after login. Look for the Set-Cookie header—note its presence, attributes (domain, path, secure, sameSite), and if the cookie actually appears in the browser.
  2. Use curl to fetch the same endpoint directly from both your Cloudflare-proxied domain and (if possible) your origin server (Hostinger). Compare the Set-Cookie headers in both responses. If the header is present from Hostinger but missing or altered via Cloudflare, Cloudflare is interfering.
  3. In your Cloudflare dashboard, check for:
    • Proxy status (orange cloud = proxied, gray = DNS only). Try setting the DNS record to DNS only (gray cloud) to see if the issue goes away.
    • Page Rules, Transform Rules, or Workers that might modify headers.
    • Security features like "Scrape Shield" or "Cloudflare Access" that could block or rewrite cookies.

If you confirm Cloudflare is the cause, you may need to adjust or disable these features for your auth endpoints. If you can, share the Set-Cookie header from your network tab after login for more targeted help.
More troubleshooting steps here

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:3262059543 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> Cloudflare can silently strip or rewrite Set-Cookie headers, which breaks authentication flows that rely on cookies. To check if this is happening: 1. Open your browser's network tab and inspect the response from your backend after login. Look for the Set-Cookie header—note its presence, attributes (domain, path, secure, sameSite), and if the cookie actually appears in the browser. 2. Use curl to fetch the same endpoint directly from both your Cloudflare-proxied domain and (if possible) your origin server (Hostinger). Compare the Set-Cookie headers in both responses. If the header is present from Hostinger but missing or altered via Cloudflare, Cloudflare is interfering. 3. In your Cloudflare dashboard, check for: - Proxy status (orange cloud = proxied, gray = DNS only). Try setting the DNS record to DNS only (gray cloud) to see if the issue goes away. - Page Rules, Transform Rules, or Workers that might modify headers. - Security features like "Scrape Shield" or "Cloudflare Access" that could block or rewrite cookies. If you confirm Cloudflare is the cause, you may need to adjust or disable these features for your auth endpoints. If you can, share the Set-Cookie header from your network tab after login for more targeted help. [More troubleshooting steps here](https://github.com/better-auth/better-auth/issues/3938#issuecomment-3176753192) <!-- 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/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/73e1987c-c072-4367-a0f1-3b7dbf6d5155?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/4483)
GiteaMirror commented 2026-04-15 17:06:12 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

You say i need to get the header from backend but how? Once i click social login, the google form opens up and after everything happens so fast i don’t see any more request in the network

Also i tried
Proxy status (orange cloud = proxied, gray = DNS only). Try setting the DNS record to DNS only (gray cloud) to see if the issue goes away.
i set to gray and still same problem

<!-- gh-comment-id:3262069246 --> @MariuzM commented on GitHub (Sep 6, 2025): You say i need to get the header from backend but how? Once i click social login, the google form opens up and after everything happens so fast i don’t see any more request in the network Also i tried Proxy status (orange cloud = proxied, gray = DNS only). Try setting the DNS record to DNS only (gray cloud) to see if the issue goes away. i set to gray and still same problem
GiteaMirror commented 2026-04-15 17:06:13 -05:00
Author
Owner
Copy Link

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

This is a common challenge with OAuth flows—because the redirect happens so fast, the Set-Cookie header from the backend is easy to miss in the browser network tab. Here’s how you can reliably capture it:

  1. In Chrome/Edge, open DevTools, go to the Network tab, and enable “Preserve log.” Start the login flow, and after authenticating with Google, look for a request to /oauth2/callback/google (or similar). Click that request and check the “Response Headers” for Set-Cookie. You may need to filter by your backend domain or pause the redirect to catch it. HttpOnly cookies won’t show in the Cookies tab, only in the response headers. Details

  2. If the browser is too fast, use a tool like curl to manually hit the callback endpoint. For example:

curl -I "https://your-backend-domain.com/oauth2/callback/google?code=YOUR_CODE&state=YOUR_STATE"

Compare the Set-Cookie header from your origin server and your Cloudflare-proxied domain. If it’s present on origin but missing or altered via Cloudflare, Cloudflare is interfering. Details

  1. If browser/curl isn’t enough, try an HTTP proxy tool like Fiddler, mitmproxy, or Charles Proxy to capture all traffic and headers during the flow.

Since switching Cloudflare to DNS-only didn’t help, double-check for any Page Rules, Transform Rules, Workers, or security features in Cloudflare that could still modify headers. Also, confirm your cookie attributes (domain, path, secure, sameSite) and CORS settings are correct, and test in incognito or another browser to rule out extension issues. Checklist

Let me know if you’re able to capture the Set-Cookie header this way, or if you see any errors/warnings in the browser console—those can help pinpoint what’s blocking the cookie.

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:3262075972 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> This is a common challenge with OAuth flows—because the redirect happens so fast, the Set-Cookie header from the backend is easy to miss in the browser network tab. Here’s how you can reliably capture it: 1. In Chrome/Edge, open DevTools, go to the Network tab, and enable “Preserve log.” Start the login flow, and after authenticating with Google, look for a request to `/oauth2/callback/google` (or similar). Click that request and check the “Response Headers” for `Set-Cookie`. You may need to filter by your backend domain or pause the redirect to catch it. HttpOnly cookies won’t show in the Cookies tab, only in the response headers. [Details](https://github.com/better-auth/better-auth/issues/4038#issuecomment-3193374037) 2. If the browser is too fast, use a tool like curl to manually hit the callback endpoint. For example: ```bash curl -I "https://your-backend-domain.com/oauth2/callback/google?code=YOUR_CODE&state=YOUR_STATE" ``` Compare the `Set-Cookie` header from your origin server and your Cloudflare-proxied domain. If it’s present on origin but missing or altered via Cloudflare, Cloudflare is interfering. [Details](https://github.com/better-auth/better-auth/issues/4483#issuecomment-3262059543) 3. If browser/curl isn’t enough, try an HTTP proxy tool like Fiddler, mitmproxy, or Charles Proxy to capture all traffic and headers during the flow. Since switching Cloudflare to DNS-only didn’t help, double-check for any Page Rules, Transform Rules, Workers, or security features in Cloudflare that could still modify headers. Also, confirm your cookie attributes (domain, path, secure, sameSite) and CORS settings are correct, and test in incognito or another browser to rule out extension issues. [Checklist](https://github.com/better-auth/better-auth/discussions/3262#discussioncomment-13665380) Let me know if you’re able to capture the Set-Cookie header this way, or if you see any errors/warnings in the browser console—those can help pinpoint what’s blocking the cookie. <!-- 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/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2056a5a6-d0ce-4c5d-b438-968b2be8a100?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/4483)
GiteaMirror commented 2026-04-15 17:06:14 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

does better auth not have some sort of logging tool i can use to see what is being sent?

<!-- gh-comment-id:3262083658 --> @MariuzM commented on GitHub (Sep 6, 2025): does better auth not have some sort of logging tool i can use to see what is being sent?
GiteaMirror commented 2026-04-15 17:06:15 -05:00
Author
Owner
Copy Link

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

Better Auth does have a logger config option, but debug logging is not implemented for most endpoints—so even if you set up the logger, you won't see detailed logs for outgoing responses, cookies, or authentication flows right now (source).

You can enable debug logging for telemetry data by setting BETTER_AUTH_TELEMETRY_DEBUG=1 in your .env, but this only logs what telemetry is sent, not HTTP responses or cookies (source).

To see what is actually being sent (like Set-Cookie headers), you'll need to use your framework's middleware or hooks. With Fastify, you can add a hook to log response headers for debugging:

fastify.addHook('onSend', (request, reply, payload, done) => {
  console.log('Response headers:', reply.getHeaders());
  done();
});

This will print all outgoing headers—including Set-Cookie—so you can see exactly what Better Auth is sending during the auth flow.

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:3262085860 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> Better Auth does have a logger config option, but debug logging is not implemented for most endpoints—so even if you set up the logger, you won't see detailed logs for outgoing responses, cookies, or authentication flows right now ([source](https://github.com/better-auth/better-auth/issues/3169)). You can enable debug logging for telemetry data by setting BETTER_AUTH_TELEMETRY_DEBUG=1 in your .env, but this only logs what telemetry is sent, not HTTP responses or cookies ([source](https://github.com/better-auth/better-auth/issues/3935)). To see what is actually being sent (like Set-Cookie headers), you'll need to use your framework's middleware or hooks. With Fastify, you can add a hook to log response headers for debugging: ```js fastify.addHook('onSend', (request, reply, payload, done) => { console.log('Response headers:', reply.getHeaders()); done(); }); ``` This will print all outgoing headers—including Set-Cookie—so you can see exactly what Better Auth is sending during the auth flow. <!-- 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/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/825b2146-bd86-46d4-9296-a5e748c3659d?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/4483)
GiteaMirror commented 2026-04-15 17:06:15 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

This is what is being logged

Response headers: {
  vary: 'Origin',
  'access-control-allow-origin': 'https://example.com',
  'access-control-allow-credentials': 'true',
  'content-type': 'application/json; charset=utf-8'
}
Response headers: {
  vary: 'Origin',
  'access-control-allow-credentials': 'true',
  'content-type': 'application/json; charset=utf-8',
  location: 'https://example.com/test',
  'set-cookie': '__Secure-better-auth.session_token=z7uIZBgI4Cx72iiXlu6PXmJ8392VdL8gi.oPrXD3UCMu59FOQWES119JBofWszdrkTR1e7sSOL1Hm7%2Bw%3D; Max-Age=604800; Path=/; HttpOnly; Secure; SameSite=Lax'
}
Response headers: {
  vary: 'Origin',
  'access-control-allow-origin': 'https://example.com',
  'access-control-allow-credentials': 'true',
  'content-type': 'application/json; charset=utf-8'
}
<!-- gh-comment-id:3262093983 --> @MariuzM commented on GitHub (Sep 6, 2025): This is what is being logged ``` Response headers: { vary: 'Origin', 'access-control-allow-origin': 'https://example.com', 'access-control-allow-credentials': 'true', 'content-type': 'application/json; charset=utf-8' } Response headers: { vary: 'Origin', 'access-control-allow-credentials': 'true', 'content-type': 'application/json; charset=utf-8', location: 'https://example.com/test', 'set-cookie': '__Secure-better-auth.session_token=z7uIZBgI4Cx72iiXlu6PXmJ8392VdL8gi.oPrXD3UCMu59FOQWES119JBofWszdrkTR1e7sSOL1Hm7%2Bw%3D; Max-Age=604800; Path=/; HttpOnly; Secure; SameSite=Lax' } Response headers: { vary: 'Origin', 'access-control-allow-origin': 'https://example.com', 'access-control-allow-credentials': 'true', 'content-type': 'application/json; charset=utf-8' } ```
GiteaMirror commented 2026-04-15 17:06:16 -05:00
Author
Owner
Copy Link

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

The Set-Cookie header in your logs is missing the domain attribute, so the cookie will only be valid for the exact host that set it and won't be shared across www/non-www domains. Also, SameSite is set to Lax, which can cause issues with OAuth/social login flows that involve redirects or cross-origin requests—browsers may block the cookie in these cases docs.

To fix this, update your Better Auth config like this:

advanced: {
  crossSubDomainCookies: {
    enabled: true,
    domain: '.example.com', // no protocol, leading dot for all subdomains
  },
  defaultCookieAttributes: {
    sameSite: 'none', // required for OAuth/cross-origin
    secure: true,
    httpOnly: true,
  },
}

After making these changes, redeploy/restart your backend and clear cookies in your browser. Then, retry the login flow and check the Set-Cookie header again—it should now include both the domain and SameSite=None attributes. This should resolve the issue with cookies not being set or shared between www and non-www domains reference.

If you still have issues, check for browser warnings about cookies, test in a different browser, and make sure Cloudflare or any proxy/CDN isn't interfering with headers.

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:3262098591 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> The Set-Cookie header in your logs is missing the domain attribute, so the cookie will only be valid for the exact host that set it and won't be shared across www/non-www domains. Also, SameSite is set to Lax, which can cause issues with OAuth/social login flows that involve redirects or cross-origin requests—browsers may block the cookie in these cases [docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/concepts/cookies.mdx). To fix this, update your Better Auth config like this: ```ts advanced: { crossSubDomainCookies: { enabled: true, domain: '.example.com', // no protocol, leading dot for all subdomains }, defaultCookieAttributes: { sameSite: 'none', // required for OAuth/cross-origin secure: true, httpOnly: true, }, } ``` After making these changes, redeploy/restart your backend and clear cookies in your browser. Then, retry the login flow and check the Set-Cookie header again—it should now include both the domain and SameSite=None attributes. This should resolve the issue with cookies not being set or shared between www and non-www domains [reference](https://github.com/better-auth/better-auth/issues/3470). If you still have issues, check for browser warnings about cookies, test in a different browser, and make sure Cloudflare or any proxy/CDN isn't interfering with headers. <!-- 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/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4c28c2d6-a865-4fde-b3ac-c9bd8b6c6cf5?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/4483)
GiteaMirror commented 2026-04-15 17:06:17 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

Response headers: {
  vary: 'Origin',
  'access-control-allow-credentials': 'true',
  'content-type': 'application/json; charset=utf-8',
  location: 'https://example.com/test',
  'set-cookie': '__Secure-better-auth.session_token=Sju0Jyx4oDNajDv232Mq30AW13HiO2ZIFP3sx.ew2vo2m4yg1TfeIbT1h9Cy13aJhzmgHAi1R2RQw56YU6uGk%3D; Max-Age=604800; Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=None'
}
Response headers: {
  vary: 'Origin',
  'access-control-allow-origin': 'https://example.com',
  'access-control-allow-credentials': 'true',
  'content-type': 'application/json; charset=utf-8'
}

still not working

<!-- gh-comment-id:3262104920 --> @MariuzM commented on GitHub (Sep 6, 2025): ``` Response headers: { vary: 'Origin', 'access-control-allow-credentials': 'true', 'content-type': 'application/json; charset=utf-8', location: 'https://example.com/test', 'set-cookie': '__Secure-better-auth.session_token=Sju0Jyx4oDNajDv232Mq30AW13HiO2ZIFP3sx.ew2vo2m4yg1TfeIbT1h9Cy13aJhzmgHAi1R2RQw56YU6uGk%3D; Max-Age=604800; Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=None' } Response headers: { vary: 'Origin', 'access-control-allow-origin': 'https://example.com', 'access-control-allow-credentials': 'true', 'content-type': 'application/json; charset=utf-8' } ``` still not working
GiteaMirror commented 2026-04-15 17:06:18 -05:00
Author
Owner
Copy Link

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

Your Set-Cookie header looks correct, but if authentication still isn't working, the issue is likely environmental. Here are the most common causes and next steps:

  1. CORS and credentials: Make sure your frontend requests (especially after social login) use credentials: "include" (for fetch) or withCredentials: true (for axios). If credentials aren't included, browsers will ignore Set-Cookie on cross-origin responses reference.

  2. Browser policies: Some browsers (Safari, Brave, Firefox) block third-party cookies by default, especially with SameSite=None. Test in Chrome incognito with all extensions disabled to rule out browser-side interference reference.

  3. Cloudflare/proxy interference: Even with DNS-only mode, Cloudflare can still modify headers. Double-check for any Page Rules, Transform Rules, or Workers that might affect cookies. If possible, test bypassing Cloudflare entirely.

  4. Old cookies: Clear all cookies for your domain before testing. Old cookies can cause login/logout cycles to fail reference.

  5. Session validation: If the session is created without a valid user id (e.g., due to a misconfigured OAuth provider or custom user mapping), Better Auth will erase the cookie immediately after login. Check your database and logs for null user ids in session creation reference.

  6. Frontend redirect handling: If your frontend is a SPA, make sure it doesn't use XHR/fetch for the final OAuth redirect—let the browser handle the redirect so cookies are set properly.

Can you share your frontend auth client config and confirm if you see any CORS errors or cookie warnings in the browser console during login? This will help pinpoint the issue.

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:3262114482 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> Your Set-Cookie header looks correct, but if authentication still isn't working, the issue is likely environmental. Here are the most common causes and next steps: 1. **CORS and credentials:** Make sure your frontend requests (especially after social login) use `credentials: "include"` (for fetch) or `withCredentials: true` (for axios). If credentials aren't included, browsers will ignore Set-Cookie on cross-origin responses [reference](https://github.com/better-auth/better-auth/issues/2157#issuecomment-2782202751). 2. **Browser policies:** Some browsers (Safari, Brave, Firefox) block third-party cookies by default, especially with `SameSite=None`. Test in Chrome incognito with all extensions disabled to rule out browser-side interference [reference](https://github.com/better-auth/better-auth/issues/4038#issuecomment-3193423068). 3. **Cloudflare/proxy interference:** Even with DNS-only mode, Cloudflare can still modify headers. Double-check for any Page Rules, Transform Rules, or Workers that might affect cookies. If possible, test bypassing Cloudflare entirely. 4. **Old cookies:** Clear all cookies for your domain before testing. Old cookies can cause login/logout cycles to fail [reference](https://github.com/better-auth/better-auth/issues/2157#issuecomment-2782202751). 5. **Session validation:** If the session is created without a valid user id (e.g., due to a misconfigured OAuth provider or custom user mapping), Better Auth will erase the cookie immediately after login. Check your database and logs for null user ids in session creation [reference](https://github.com/better-auth/better-auth/issues/4172#issuecomment-3216623796). 6. **Frontend redirect handling:** If your frontend is a SPA, make sure it doesn't use XHR/fetch for the final OAuth redirect—let the browser handle the redirect so cookies are set properly. Can you share your frontend auth client config and confirm if you see any CORS errors or cookie warnings in the browser console during login? This will help pinpoint the issue. <!-- 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/536da403-f756-4938-af99-cdacf57e906f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/536da403-f756-4938-af99-cdacf57e906f?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/4483)
GiteaMirror commented 2026-04-15 17:06:18 -05:00
Author
Owner
Copy Link

@MariuzM commented on GitHub (Sep 6, 2025):

If i use a url that was randomly generated by railway it works, so i think browser, server and frontend all working correctly but somewhere else is the problem

<!-- gh-comment-id:3262121852 --> @MariuzM commented on GitHub (Sep 6, 2025): If i use a url that was randomly generated by railway it works, so i think browser, server and frontend all working correctly but somewhere else is the problem
GiteaMirror commented 2026-04-15 17:06:19 -05:00
Author
Owner
Copy Link

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

If authentication works on the Railway-generated URL but not on example.com or www.example.com, the issue is almost certainly environmental—something about your custom domain setup is blocking or dropping the cookie, even though your config and Set-Cookie header look correct.

Here’s what stands out:

  • Better Auth sets cookies strictly based on your config; there’s no special logic for custom domains or public suffixes, so if it works on Railway, it should work on your domain if everything else is equal (source).
  • Your Set-Cookie header for example.com includes Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=None, which is correct for sharing cookies across www and non-www (source).
  • Cloudflare and Hostinger can still interfere even in DNS-only mode, especially if SSL/TLS settings, Page Rules, or Workers are active. No documentation or known issues exist for Better Auth + Cloudflare, so you’ll need to check for any rules or settings that might block or rewrite cookies (source).
  • Recent Better Auth updates (PR #4330, #4123) added a bearer-token-confirmation flow for social logins. Make sure your frontend uses the latest Better Auth client with the bearer plugin, so it can retrieve the bearer token after OAuth redirects (source).

Checklist:

  • Double-check your DNS records and SSL certificates for example.com vs Railway URL.
  • Compare the full response headers (Set-Cookie, Location, etc.) for both domains.
  • Make sure your frontend is using the latest Better Auth client and bearer plugin.
  • Review Cloudflare for any Page Rules, Transform Rules, or Workers that could affect cookies.
  • Try bypassing Cloudflare/Hostinger by pointing example.com directly to Railway to isolate the issue.

If you can share the full response headers for both domains and confirm your frontend setup, I can help pinpoint what’s different.

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:3262132761 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> If authentication works on the Railway-generated URL but not on example.com or www.example.com, the issue is almost certainly environmental—something about your custom domain setup is blocking or dropping the cookie, even though your config and Set-Cookie header look correct. Here’s what stands out: - Better Auth sets cookies strictly based on your config; there’s no special logic for custom domains or public suffixes, so if it works on Railway, it should work on your domain if everything else is equal ([source](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/cookies/index.ts)). - Your Set-Cookie header for example.com includes `Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=None`, which is correct for sharing cookies across www and non-www ([source](https://github.com/better-auth/better-auth/issues/3470)). - Cloudflare and Hostinger can still interfere even in DNS-only mode, especially if SSL/TLS settings, Page Rules, or Workers are active. No documentation or known issues exist for Better Auth + Cloudflare, so you’ll need to check for any rules or settings that might block or rewrite cookies ([source](https://github.com/better-auth/better-auth/issues/3938)). - Recent Better Auth updates (PR #4330, #4123) added a bearer-token-confirmation flow for social logins. Make sure your frontend uses the latest Better Auth client with the bearer plugin, so it can retrieve the bearer token after OAuth redirects ([source](https://github.com/better-auth/better-auth/pull/4330)). Checklist: - Double-check your DNS records and SSL certificates for example.com vs Railway URL. - Compare the full response headers (Set-Cookie, Location, etc.) for both domains. - Make sure your frontend is using the latest Better Auth client and bearer plugin. - Review Cloudflare for any Page Rules, Transform Rules, or Workers that could affect cookies. - Try bypassing Cloudflare/Hostinger by pointing example.com directly to Railway to isolate the issue. If you can share the full response headers for both domains and confirm your frontend setup, I can help pinpoint what’s different. <!-- 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/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/489a7f50-05b1-4e36-8aa1-f24f7274bef0?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/4483)
GiteaMirror commented 2026-04-15 17:06:19 -05:00
Author
Owner
Copy Link

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

Marking as stale, non-reproducable

<!-- gh-comment-id:3330741072 --> @dvanmali commented on GitHub (Sep 24, 2025): Marking as stale, non-reproducable
GiteaMirror commented 2026-04-15 17:06:20 -05:00
Author
Owner
Copy Link

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

I did face a same problem, using cloudflare with subdomain
https://preview.mytreelings.com/ not work
https://mytreelings-preview.mytreelings.workers.dev/ works
Please help

<!-- gh-comment-id:3331401910 --> @summerisgood1 commented on GitHub (Sep 25, 2025): I did face a same problem, using cloudflare with subdomain https://preview.mytreelings.com/ not work https://mytreelings-preview.mytreelings.workers.dev/ works Please help
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#18582
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?