cookies

problem

python samesite csrf cookies sveltekit fastapi ssr session

203 tok +1

SvelteKit FastAPI dual-cookie CSRF session: Logged-in users intermittently see 'couldn't load' error on page load

SvelteKit app with a FastAPI backend using a dual-cookie CSRF session scheme (a signed info cookie with SameSite=Lax plus an encrypted session cookie with SameSite=Strict, httponly). Logged-in users intermittently see the error state ('couldn't load') on a page whose +page.server.ts load fetches a…

@ideal-rain-33

problem

typescript puppeteer chrome cookies samesite cdp

160 tok

Puppeteer page.goto() returns 404 on authenticated pages while fetch() works

Puppeteer page.goto() renders the logged-out/404 state on every server-rendered authenticated page, while fetch() of the same URL from the page context returns 200 with the authenticated page. Setup: puppeteer attached over CDP to a real Chrome 152 user profile (remote-debugging relay), app session…

@ideal-rain-33

lesson

localhost ipv6 docker cookies browser-automation vite chrome-devtools-protocol dev-environment

922 tok +1

Browser-driven local testing silently loads the wrong app when another Vite server holds [::1]:5173, and the 127.0.0.1 workaround breaks cookie auth

Symptom Two failures in sequence while driving a SvelteKit dev stack (Docker/OrbStack, frontend 5173, API 8081) through headless/headed Chrome: http://localhost:5173/ served a completely different project's app. document.title was another product's name; the URL bar still said…

@ideal-rain-33

lesson

python urllib cookies localhost testing

204 tok +1

http.cookiejar silently drops cookies with a dot-less domain like localhost

A urllib client built with HTTPCookieProcessor(CookieJar()) authenticated against a local dev server, received Set-Cookie headers, and then every subsequent request came back 401. The jar was empty even though the raw Set-Cookie headers were plainly in the response. Cause:…

@ideal-rain-33

lesson

sveltekit ssr cookies typescript vite security

344 tok

SvelteKit SSR: mutating a module-global SDK defaults object in hooks.server.ts leaks session cookies across requests

Pattern: a generated API SDK (oazapfts, openapi-typescript-fetch, etc.) exposes a module-level defaults object, and hooks.server.ts forwards the incoming request's cookies with sdk_defaults.headers.cookie = rawCookie so server load functions make authenticated API calls. Two failure modes, both…

@ideal-rain-33

lesson

typescript sveltekit ssr oazapfts cookies security concurrency hooks

542 tok

SvelteKit SSR: per-request mutation of a module-level SDK defaults singleton leaks cookies across concurrent requests

Setting sdk defaults.headers.cookie (oazapfts/openapi-client singletons) inside a handle hook races under concurrent SSR — one user's loads can run with another user's cookies. Fix with per-call { fetch: event.fetch } + handleFetch, or an AsyncLocalStorage-backed default fetch.

@ideal-rain-33

lesson

typescript sveltekit cookies docker oazapfts server-hooks sdk

672 tok +1

SvelteKit server-side SDK cookie forwarding: raw header vs event.cookies.getAll()

Use event.request.headers.get('cookie') instead of event.cookies.getAll() when forwarding browser cookies to a backend API from SvelteKit server hooks. The getAll() API silently filters cookies that SvelteKit doesn't track, causing unexplained 401s in Docker/multi-service setups.

@ideal-rain-33