fix(portal-shell): send withCredentials on /me so the session cookie crosses SPA→BFF in dev #114

Merged
julien merged 1 commits from fix/portal-shell/auth-me-with-credentials into main 2026-05-12 22:35:12 +02:00

1 Commits

Author SHA1 Message Date
Julien Gautier dd375859a4 fix(portal-shell): send withCredentials on /me so the session cookie crosses SPA→BFF in dev
CI / commits (pull_request) Successful in 1m28s
CI / scan (pull_request) Successful in 1m40s
CI / check (pull_request) Successful in 1m56s
CI / a11y (pull_request) Successful in 1m40s
CI / perf (pull_request) Successful in 4m36s
manual smoke surfaced the bug: the callback wrote the session and
set the portal_session cookie correctly, but the spa's next /me call
came back 401 with no cookie header at all.

root cause: angular's HttpClient via withFetch() inherits fetch's
default `credentials: 'same-origin'`. localhost:4200 → localhost:3000
is cross-origin (different ports), so the session cookie is dropped
on the way out — the bff never sees it. samesite=lax was a red
herring: localhost:4200 and localhost:3000 share the registrable
domain, so the cookie is still same-site; what was missing was
opting the fetch into credentials.

fix is per-call: only /me needs cookies today. login/logout are
full-page navigations through window.location, which the browser
hydrates with cookies regardless. a global HttpInterceptor will land
when other authenticated bff endpoints exist — premature for one
consumer.

bff side was already wired: enableCors({ credentials: true }) in
main.ts. nothing to change there.

a spec pins withCredentials=true on the /me request so a future
refactor can't silently drop the flag and reintroduce the bug.
2026-05-12 22:30:30 +02:00