BA
Better Auth•2mo ago
astro

session data is null despite session cookie

so i have a hono api and i've writtten a custom middlware to check for authentication which works fine locally however, in prod (deployed on cf workers) despite the headers containing the session cookie the session is null, here's my middleware: https://github.com/777advait/better-auth-monorepo/blob/main/apps/api/src/middlewares/authenticated.ts server logs: 
GET https://better-api.astro-dev.tech/api/auth/me - Ok @ 7/27/2025, 11:07:06 PM
  (log) <-- GET /api/auth/me
  (log) Incoming headers: {
  accept: '*/*',
  'accept-encoding': 'gzip, br',
  'accept-language': 'en-GB,en;q=0.8',
  'cache-control': 'no-cache',
  'cf-connecting-ip': '2401:4900:1722:b4e0:7928:b11e:b988:501f',
  'cf-ipcountry': 'IN',
  'cf-ray': '965de7209a041a5e',
  'cf-visitor': '{"scheme":"https"}',
  connection: 'Keep-Alive',
  cookie: '__Secure-better-auth.session_token=yqyUt5unqZDvw13peHrjo4QApuoUD29P.BvB1NAdq0PffeW6xi%2B8igN8XbhsUl3sMGJeLVUp%2F5eI%3D',
  host: 'better-api.astro-dev.tech',
  origin: 'https://better-web.astro-dev.tech',
  pragma: 'no-cache',
  priority: 'u=1, i',
  referer: 'https://better-web.astro-dev.tech/',
  'sec-ch-ua': '"Not)A;Brand";v="8", "Chromium";v="138", "Brave";v="138"',
  'sec-ch-ua-mobile': '?1',
  'sec-ch-ua-platform': '"Android"',
  'sec-fetch-dest': 'empty',
  'sec-fetch-mode': 'cors',
  'sec-fetch-site': 'same-site',
  'sec-gpc': '1',
  'user-agent': 'Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Mobile Safari/537.36',
  'x-forwarded-proto': 'https',
  'x-real-ip': '2401:4900:1722:b4e0:7928:b11e:b988:501f'
}
  (log) Cookie header: __Secure-better-auth.session_token=yqyUt5unqZDvw13peHrjo4QApuoUD29P.BvB1NAdq0PffeW6xi%2B8igN8XbhsUl3sMGJeLVUp%2F5eI%3D
  (log) Session Data: null
  (log) --> GET /api/auth/me 401 0ms
GET https://better-api.astro-dev.tech/api/auth/me - Ok @ 7/27/2025, 11:07:06 PM
  (log) <-- GET /api/auth/me
  (log) Incoming headers: {
  accept: '*/*',
  'accept-encoding': 'gzip, br',
  'accept-language': 'en-GB,en;q=0.8',
  'cache-control': 'no-cache',
  'cf-connecting-ip': '2401:4900:1722:b4e0:7928:b11e:b988:501f',
  'cf-ipcountry': 'IN',
  'cf-ray': '965de7209a041a5e',
  'cf-visitor': '{"scheme":"https"}',
  connection: 'Keep-Alive',
  cookie: '__Secure-better-auth.session_token=yqyUt5unqZDvw13peHrjo4QApuoUD29P.BvB1NAdq0PffeW6xi%2B8igN8XbhsUl3sMGJeLVUp%2F5eI%3D',
  host: 'better-api.astro-dev.tech',
  origin: 'https://better-web.astro-dev.tech',
  pragma: 'no-cache',
  priority: 'u=1, i',
  referer: 'https://better-web.astro-dev.tech/',
  'sec-ch-ua': '"Not)A;Brand";v="8", "Chromium";v="138", "Brave";v="138"',
  'sec-ch-ua-mobile': '?1',
  'sec-ch-ua-platform': '"Android"',
  'sec-fetch-dest': 'empty',
  'sec-fetch-mode': 'cors',
  'sec-fetch-site': 'same-site',
  'sec-gpc': '1',
  'user-agent': 'Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Mobile Safari/537.36',
  'x-forwarded-proto': 'https',
  'x-real-ip': '2401:4900:1722:b4e0:7928:b11e:b988:501f'
}
  (log) Cookie header: __Secure-better-auth.session_token=yqyUt5unqZDvw13peHrjo4QApuoUD29P.BvB1NAdq0PffeW6xi%2B8igN8XbhsUl3sMGJeLVUp%2F5eI%3D
  (log) Session Data: null
  (log) --> GET /api/auth/me 401 0ms
this works perfectly fine locally (both in bun and wrangler runtime) so is it an issue with cf workers?
GitHub
better-auth-monorepo/apps/api/src/middlewares/authenticated.ts at m...
Contribute to 777advait/better-auth-monorepo development by creating an account on GitHub.
Solution:
i fixed it! it was a cloudflare issue, i was instantiating an auth instance in my api app, and the base URL of that was a worker, workers dont allow communication among each other over public network, the requests fail silently (no messages no warnings), it can only be permitted via service bindings https://developers.cloudflare.com/workers/configuration/routing/custom-domains/#worker-to-worker-communication https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/ i just moved my auth stuff into the api app so there's no worker-worker communication, everything sits in one place, it'd be good to be able to define custom fetch functions when instantiating auth instances in future...
Cloudflare Docs
Service bindings
Facilitate Worker-to-Worker communication.
Cloudflare Docs
Custom Domains
Custom Domains allow you to connect your Worker to a domain or subdomain, without having to make changes to your DNS settings or perform any certificate management. After you set up a Custom Domain for your Worker, Cloudflare will create DNS records and issue necessary certificates on your behalf. The created DNS records will point directly to y...
Jump to solution
1 Reply
Solution
astro
astro•2mo ago
i fixed it! it was a cloudflare issue, i was instantiating an auth instance in my api app, and the base URL of that was a worker, workers dont allow communication among each other over public network, the requests fail silently (no messages no warnings), it can only be permitted via service bindings https://developers.cloudflare.com/workers/configuration/routing/custom-domains/#worker-to-worker-communication https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/ i just moved my auth stuff into the api app so there's no worker-worker communication, everything sits in one place, it'd be good to be able to define custom fetch functions when instantiating auth instances in future
Cloudflare Docs
Service bindings
Facilitate Worker-to-Worker communication.
Cloudflare Docs
Custom Domains
Custom Domains allow you to connect your Worker to a domain or subdomain, without having to make changes to your DNS settings or perform any certificate management. After you set up a Custom Domain for your Worker, Cloudflare will create DNS records and issue necessary certificates on your behalf. The created DNS records will point directly to y...

Did you find this page helpful?