mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
Sean Oliver
075c2f4528
## Problem While working on the phased PostHog Attribution rollout (GROWTH-625 / GROWTH-668) — specifically the initial referrer handoff across the app boundary — we discovered that `parseFirstReferrerCookie` was returning `null` even when the cookie was visibly present in the browser. The root cause: `serializeFirstReferrerCookie` calls `encodeURIComponent(JSON.stringify(data))`, but Next.js `cookies.set()` encodes the value again, producing a double-encoded cookie. On the read side, `parseFirstReferrerCookie` only decodes once, so `JSON.parse` receives a still-encoded string and fails. The `try/catch` swallows the error and returns `null`. Confirmed in production: the raw cookie value starts with `%257B%2522` (double-encoded `%` characters). A single `decodeURIComponent` produces `%7B%22referrer%22...` — still URL-encoded, not valid JSON. This was blocking the cross-app attribution handoff that GROWTH-625 depends on. ## Changes - **Serializer**: Removed `encodeURIComponent` from `serializeFirstReferrerCookie` — Next.js `cookies.set()` already handles encoding - **Parser**: Made `parseFirstReferrerCookie` resilient to both encodings — tries single decode first, falls back to double decode for existing cookies in the wild (365-day TTL means legacy cookies persist up to a year) - **Test**: Added unit test for the double-encoded legacy cookie format ## Testing - 35/35 common unit tests pass, 12/12 www middleware tests pass - Verified locally: Google → www (localhost:3000) → Studio (localhost:8082). Console logs confirmed `parseFirstReferrerCookie` returned the full data object instead of null - Confirmed in production that existing cookies are double-encoded and the fix correctly handles them Ref: GROWTH-625 / GROWTH-668