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

[GH-ISSUE #8737] getCookieCache / createCookieGetter prefix mismatch? #11174

New Issue
Open
opened 2026-04-13 07:32:01 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-13 07:32:01 -05:00
Owner
Copy Link
Copy Source

Originally created by @NickWoodward on GitHub (Mar 23, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/8737

Is this suited for github?

  • No

To Reproduce

  1. Configure better-auth with cookie cache enabled and an HTTP baseURL:
export const auth = betterAuth({
  baseURL: "http://localhost:8787",
  session: {
    cookieCache: {
      enabled: true,
      maxAge: 5 * 60,
    },
  },
  // ...
});
  1. Use getCookieCache in middleware:
export async function middleware(request: NextRequest) {
  const session = await getCookieCache(request);
  if (!session) {
    return NextResponse.redirect(new URL("/sign-in", request.url));
  }
  return NextResponse.next();
}
  1. Run npx opennextjs-cloudflare build && opennextjs-cloudflare preview (the build sets NODE_ENV=production)
  2. Signing in to set the cookie (it will be better-auth.session_data)

Current vs. Expected behavior

So I'm pretty new to this better-auth/open-next/cloudflare combo, so apologies if I've made a basic error here. I'm guessing this is less of a bug, and more friction between wrangler's local preview environment and what better-auth expects, but I'm still a little unclear on the best fix.

Current behaviour:
Mismatch between how the SECURE_COOKIE_PREFIX is set and read in wrangler preview environments?

  • Deploying a preview using wrangler sets NODE_ENV to "production"

  • secureCookiePrefix in createCookieGetter sees that useSecureCookies is undefined, that baseURL is not an object so dynamicProtocol is undefined, so it sets a non-prefixed cookie based on baseURLString existing but baseURLString.startsWith("https://") being false:

const secureCookiePrefix = (
  options.advanced?.useSecureCookies !== void 0
    ? options.advanced?.useSecureCookies
    : dynamicProtocol === "https"
      ? true
      : dynamicProtocol === "http"
        ? false
        : baseURLString
          ? baseURLString.startsWith("https://")
          : isProduction
) ? SECURE_COOKIE_PREFIX : "";
  • but in contrast getCookieCache checks isSecure (undefined), then isProduction (true), meaning that it looks for the Prefixed cookie:
const name = config?.isSecure !== void 0 ? 
  config.isSecure ? 
    `${SECURE_COOKIE_PREFIX}${cookiePrefix}.${cookieName}` : 
    `${cookiePrefix}.${cookieName}` 
  : 
  isProduction ? 
    `${SECURE_COOKIE_PREFIX}${cookiePrefix}.${cookieName}` : 
    `${cookiePrefix}.${cookieName}`;

Basically getCookieCache seems to look for __Secure-better-auth.session_data, doesn't find it and so returns null - rather than looking for better-auth.session_data.

Expected behaviour: getCookieCache and createCookieGetter should use the same logic so that the correct secure variant is set and checked? I'm obviously not an expert so not really sure.

Again, sorry if there's an easy fix for this and this is just ignorance on my part!

Thanks,

Nick

What version of Better Auth are you using?

1.5.4

System info

{
  "system": {
    "platform": "win32",
    "arch": "x64",
    "version": "Windows 11 Pro",
    "release": "10.0.26200",
    "cpuCount": 12,
    "cpuModel": "12th Gen Intel(R) Core(TM) i7-1255U",
    "totalMemory": "15.72 GB",
    "freeMemory": "1.64 GB"
  },
  "node": {
    "version": "v22.17.1",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.9.2"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "^15.5.9"
    },
    {
      "name": "react",
      "version": "^19.2.3"
    }
  ],
  "databases": [
    {
      "name": "drizzle",
      "version": "^0.45.1"
    }
  ],
  "betterAuth": {
    "version": "Unknown",
    "config": null,
    "error": "Couldn't read your auth config. Make sure to default export your auth instance or to export as a variable named auth."
  }
}

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

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
    session: {
      cookieCache: {
        enabled: true,
        maxAge: 5 * 60, 
      },
    },
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response

Originally created by @NickWoodward on GitHub (Mar 23, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/8737 ### Is this suited for github? - No ### To Reproduce 1. Configure better-auth with cookie cache enabled and an HTTP baseURL: ``` export const auth = betterAuth({ baseURL: "http://localhost:8787", session: { cookieCache: { enabled: true, maxAge: 5 * 60, }, }, // ... }); ``` 2. Use getCookieCache in middleware: ``` export async function middleware(request: NextRequest) { const session = await getCookieCache(request); if (!session) { return NextResponse.redirect(new URL("/sign-in", request.url)); } return NextResponse.next(); } ``` 3. Run npx opennextjs-cloudflare build && opennextjs-cloudflare preview (the build sets NODE_ENV=production) 4. Signing in to set the cookie (it will be better-auth.session_data) ### Current vs. Expected behavior So I'm pretty new to this better-auth/open-next/cloudflare combo, so apologies if I've made a basic error here. I'm guessing this is less of a bug, and more friction between wrangler's local preview environment and what better-auth expects, but I'm still a little unclear on the best fix. **Current behaviour:** Mismatch between how the SECURE_COOKIE_PREFIX is set and read in wrangler preview environments? - Deploying a preview using wrangler sets `NODE_ENV` to "production" - `secureCookiePrefix` in `createCookieGetter` sees that `useSecureCookies` is undefined, that baseURL is not an object so `dynamicProtocol` is undefined, **_so it sets a non-prefixed cookie_** based on `baseURLString` existing but `baseURLString.startsWith("https://")` being false: ``` const secureCookiePrefix = ( options.advanced?.useSecureCookies !== void 0 ? options.advanced?.useSecureCookies : dynamicProtocol === "https" ? true : dynamicProtocol === "http" ? false : baseURLString ? baseURLString.startsWith("https://") : isProduction ) ? SECURE_COOKIE_PREFIX : ""; ``` - but in contrast `getCookieCache` checks `isSecure` (undefined), then `isProduction` (true), **_meaning that it looks for the Prefixed cookie_**: ``` const name = config?.isSecure !== void 0 ? config.isSecure ? `${SECURE_COOKIE_PREFIX}${cookiePrefix}.${cookieName}` : `${cookiePrefix}.${cookieName}` : isProduction ? `${SECURE_COOKIE_PREFIX}${cookiePrefix}.${cookieName}` : `${cookiePrefix}.${cookieName}`; ``` Basically `getCookieCache` seems to look for `__Secure-better-auth.session_data`, doesn't find it and so returns null - rather than looking for `better-auth.session_data`. **Expected behaviour:** getCookieCache and createCookieGetter should use the same logic so that the correct secure variant is set and checked? I'm obviously not an expert so not really sure. Again, sorry if there's an easy fix for this and this is just ignorance on my part! Thanks, Nick ### What version of Better Auth are you using? 1.5.4 ### System info ```bash { "system": { "platform": "win32", "arch": "x64", "version": "Windows 11 Pro", "release": "10.0.26200", "cpuCount": 12, "cpuModel": "12th Gen Intel(R) Core(TM) i7-1255U", "totalMemory": "15.72 GB", "freeMemory": "1.64 GB" }, "node": { "version": "v22.17.1", "env": "development" }, "packageManager": { "name": "npm", "version": "10.9.2" }, "frameworks": [ { "name": "next", "version": "^15.5.9" }, { "name": "react", "version": "^19.2.3" } ], "databases": [ { "name": "drizzle", "version": "^0.45.1" } ], "betterAuth": { "version": "Unknown", "config": null, "error": "Couldn't read your auth config. Make sure to default export your auth instance or to export as a variable named auth." } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ session: { cookieCache: { enabled: true, maxAge: 5 * 60, }, }, emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the corebug labels 2026-04-13 07:32:01 -05:00
GiteaMirror commented 2026-04-13 07:32:03 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Mar 23, 2026):

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

You've identified a confirmed bug in Better Auth's cookie handling. The issue is that getCookieCache and createCookieGetter use different logic for determining the secure cookie prefix:

  • createCookieGetter checks: useSecureCookies → dynamicProtocol → baseURL.startsWith("https://") → isProduction
  • getCookieCache only checks: config?.isSecure → isProduction

This is a known issue - when baseURL is HTTP but NODE_ENV=production, createCookieGetter correctly skips the __Secure- prefix, but getCookieCache still looks for the prefixed cookie.

Workarounds:

  1. Explicitly set useSecureCookies in your auth config:
export const auth = betterAuth({
  baseURL: "http://localhost:8787",
  advanced: {
    useSecureCookies: false, // Force no prefix for HTTP
  },
  session: {
    cookieCache: { enabled: true, maxAge: 5 * 60 },
  },
});
  1. Pass isSecure to getCookieCache in your middleware:
const session = await getCookieCache(request, {
  isSecure: false, // Match your HTTP setup
  // ... other config
});
  1. Check both cookie variants in middleware as a fallback:
const sessionCookie =
  request.cookies.get("__Secure-better-auth.session_data") ??
  request.cookies.get("better-auth.session_data");

The root cause is architectural - getCookieCache is a public utility without access to baseURL, so it can't replicate createCookieGetter's logic. Explicitly setting useSecureCookies: false is the cleanest fix for your HTTP localhost scenario.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:4107773883 --> @dosubot[bot] commented on GitHub (Mar 23, 2026): <!-- Greeting --> Hi @NickWoodward! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> You've identified a **confirmed bug** in Better Auth's cookie handling. The issue is that `getCookieCache` and `createCookieGetter` use different logic for determining the secure cookie prefix: - `createCookieGetter` checks: `useSecureCookies` → `dynamicProtocol` → `baseURL.startsWith("https://")` → `isProduction` - `getCookieCache` only checks: `config?.isSecure` → `isProduction` This is [a known issue](https://github.com/better-auth/better-auth/issues/1487#issuecomment-2705381199) - when `baseURL` is HTTP but `NODE_ENV=production`, `createCookieGetter` correctly skips the `__Secure-` prefix, but `getCookieCache` still looks for the prefixed cookie. **Workarounds:** 1. **Explicitly set `useSecureCookies`** in your auth config: ```typescript export const auth = betterAuth({ baseURL: "http://localhost:8787", advanced: { useSecureCookies: false, // Force no prefix for HTTP }, session: { cookieCache: { enabled: true, maxAge: 5 * 60 }, }, }); ``` 2. **Pass `isSecure` to `getCookieCache`** in your middleware: ```typescript const session = await getCookieCache(request, { isSecure: false, // Match your HTTP setup // ... other config }); ``` 3. **Check both cookie variants** in middleware as a fallback: ```typescript const sessionCookie = request.cookies.get("__Secure-better-auth.session_data") ?? request.cookies.get("better-auth.session_data"); ``` The root cause is architectural - `getCookieCache` is a public utility without access to `baseURL`, so it can't replicate `createCookieGetter`'s logic. Explicitly setting `useSecureCookies: false` is the cleanest fix for your HTTP localhost scenario. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=great_response&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=irrelevant_answer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=incorrect_sources&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=too_verbose&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=hallucination&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=bug_report&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report) | [Other](https://app.dosu.dev/response-feedback/259d96ed-cdd3-4bc6-8352-ad8c48cf69d4?feedback_type=other&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%27ve%20identified%20a%20%2A%2Aconfirmed%20bug%2A%2A%20in%20Better%20Auth%27s%20cookie%20handling.%20The%20issue%20is%20that%20%60getCookieCache%60%20and%20%60createCookieGetter%60%20use%20different%20logic%20for%20determining%20the%20secure%20cookie%20prefix%3A%0A%0A-%20%60createCookieGetter%60%20checks%3A%20%60useSecureCookies%60%20%E2%86%92%20%60dynamicProtocol%60%20%E2%86%92%20%60baseURL.startsWith%28%22https%3A//%22%29%60%20%E2%86%92%20%60isProduction%60%0A-%20%60getCookieCache%60%20only%20checks%3A%20%60config%3F.isSecure%60%20%E2%86%92%20%60isProduction%60%0A%0AThis%20is%20%5Ba%20known%20issue%5D%28https%3A//github.com/better-auth/better-auth/issues/1487%23issuecomment-2705381199%29%20-%20when%20%60baseURL%60%20is%20HTTP%20but%20%60NODE_ENV%3Dproduction%60%2C%20%60createCookieGetter%60%20correctly%20skips%20the%20%60__Secure-%60%20prefix%2C%20but%20%60getCookieCache%60%20still%20looks%20for%20the%20prefixed%20cookie.%0A%0A%2A%2AWorkarounds%3A%2A%2A%0A%0A1.%20%2A%2AExplicitly%20set%20%60useSecureCookies%60%2A%2A%20in%20your%20auth%20config%3A%0A%60%60%60typescript%0Aexport%20const%20auth%20%3D%20betterAuth%28%7B%0A%20%20baseURL%3A%20%22http%3A//localhost%3A8787%22%2C%0A%20%20advanced%3A%20%7B%0A%20%20%20%20useSecureCookies%3A%20false%2C%20//%20Force%20no%20prefix%20for%20HTTP%0A%20%20%7D%2C%0A%20%20session%3A%20%7B%0A%20%20%20%20cookieCache%3A%20%7B%20enabled%3A%20true%2C%20maxAge%3A%205%20%2A%2060%20%7D%2C%0A%20%20%7D%2C%0A%7D%29%3B%0A%60%60%60%0A%0A2.%20%2A%2APass%20%60isSecure%60%20to%20%60getCookieCache%60%2A%2A%20in%20your%20middleware%3A%0A%60%60%60typescript%0Aconst%20session%20%3D%20await%20getCookieCache%28request%2C%20%7B%0A%20%20isSecure%3A%20false%2C%20//%20Match%20your%20HTTP%20setup%0A%20%20//%20...%20other%20config%0A%7D%29%3B%0A%60%60%60%0A%0A3.%20%2A%2ACheck%20both%20cookie%20variants%2A%2A%20in%20middleware%20as%20a%20fallback%3A%0A%60%60%60typescript%0Aconst%20sessionCookie%20%3D%0A%20%20request.cookies.get%28%22__Secure-better-auth.session_data%22%29%20%3F%3F%0A%20%20request.cookies.get%28%22better-auth.session_data%22%29%3B%0A%60%60%60%0A%0AThe%20root%20cause%20is%20architectural%20-%20%60getCookieCache%60%20is%20a%20public%20utility%20without%20access%20to%20%60baseURL%60%2C%20so%20it%20can%27t%20replicate%20%60createCookieGetter%60%27s%20logic.%20Explicitly%20setting%20%60useSecureCookies%3A%20false%60%20is%20the%20cleanest%20fix%20for%20your%20HTTP%20localhost%20scenario.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord)&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/8737)
GiteaMirror commented 2026-04-13 07:32:04 -05:00
Author
Owner
Copy Link
Copy Source

@NickWoodward commented on GitHub (Mar 23, 2026):

@dosu - 1 & 2 are just restating the problem though - which is that I have to hardcode isSecure or useSecureCookies. and 3 sidesteps the benefit of getCookieCache for me (checking the cookie role)

would this work as intended in my middleware?

const isSecure = request.url.startsWith("https://");
const cachedSession = await getCookieCache(request, { isSecure });
<!-- gh-comment-id:4107872405 --> @NickWoodward commented on GitHub (Mar 23, 2026): @dosu - 1 & 2 are just restating the problem though - which is that I have to hardcode isSecure or useSecureCookies. and 3 sidesteps the benefit of getCookieCache for me (checking the cookie role) would this work as intended in my middleware? ``` const isSecure = request.url.startsWith("https://"); const cachedSession = await getCookieCache(request, { isSecure }); ```
GiteaMirror commented 2026-04-13 07:32:05 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Mar 23, 2026):

You're right that my first suggestions don't fully solve the underlying inconsistency.

Your approach would work:

const isSecure = request.url.startsWith("https://");
const cachedSession = await getCookieCache(request, { isSecure });

This dynamically determines isSecure based on the request protocol, which should match how createCookieGetter evaluates the baseURL. Since your requests to http://localhost:8787 will have isSecure: false, and your cookies are being set without the __Secure- prefix (because baseURL starts with http://), this should align the get/set behavior.

Just make sure BETTER_AUTH_SECRET is available in your middleware environment, as getCookieCache needs it to decrypt the cookie data.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:4107877133 --> @dosubot[bot] commented on GitHub (Mar 23, 2026): <!-- Answer --> You're right that my first suggestions don't fully solve the underlying inconsistency. Your approach would work: ```typescript const isSecure = request.url.startsWith("https://"); const cachedSession = await getCookieCache(request, { isSecure }); ``` This dynamically determines `isSecure` based on the request protocol, which should match how [`createCookieGetter` evaluates the baseURL](https://github.com/better-auth/better-auth/blob/03278b5ad62c4cea61a8373bb7fe522519b31a42/packages/better-auth/src/cookies/index.ts#L447-L453). Since your requests to `http://localhost:8787` will have `isSecure: false`, and your cookies are being set without the `__Secure-` prefix (because baseURL starts with `http://`), this should align the get/set behavior. Just make sure `BETTER_AUTH_SECRET` is available in your middleware environment, as `getCookieCache` needs it to decrypt the cookie data. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=great_response&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=irrelevant_answer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=incorrect_sources&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=too_verbose&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=hallucination&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=bug_report&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report) | [Other](https://app.dosu.dev/response-feedback/dd2f45cd-34b9-4fc4-b27c-4428611c2ede?feedback_type=other&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%27re%20right%20that%20my%20first%20suggestions%20don%27t%20fully%20solve%20the%20underlying%20inconsistency.%20%0A%0AYour%20approach%20would%20work%3A%0A%0A%60%60%60typescript%0Aconst%20isSecure%20%3D%20request.url.startsWith%28%22https%3A//%22%29%3B%0Aconst%20cachedSession%20%3D%20await%20getCookieCache%28request%2C%20%7B%20isSecure%20%7D%29%3B%0A%60%60%60%0A%0AThis%20dynamically%20determines%20%60isSecure%60%20based%20on%20the%20request%20protocol%2C%20which%20should%20match%20how%20%5B%60createCookieGetter%60%20evaluates%20the%20baseURL%5D%28https%3A//github.com/better-auth/better-auth/blob/03278b5ad62c4cea61a8373bb7fe522519b31a42/packages/better-auth/src/cookies/index.ts%23L447-L453%29.%20Since%20your%20requests%20to%20%60http%3A//localhost%3A8787%60%20will%20have%20%60isSecure%3A%20false%60%2C%20and%20your%20cookies%20are%20being%20set%20without%20the%20%60__Secure-%60%20prefix%20%28because%20baseURL%20starts%20with%20%60http%3A//%60%29%2C%20this%20should%20align%20the%20get/set%20behavior.%0A%0AJust%20make%20sure%20%60BETTER_AUTH_SECRET%60%20is%20available%20in%20your%20middleware%20environment%2C%20as%20%60getCookieCache%60%20needs%20it%20to%20decrypt%20the%20cookie%20data.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord)&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/8737)
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 labels bug core
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#11174