Cross-subdomain session spike
One question: does the platform_session cookie survive a fetch from this
origin to the API on another subdomain, and can this page read the response?
Throwaway diagnostic — delete it once the real frontend exists.
Environment
| This page's origin | |
| API base URL | |
| Registrable domain | |
| Transport | |
document.cookie |
1 · Log in
POST /v1/auth/login with credentials: 'include'. This request
carries Content-Type: application/json, so the browser sends a CORS
preflight first — a misconfigured origin fails here before any cookie is issued.
2 · Check the session
GET /v1/auth/me with credentials: 'include'. Runs automatically
after a successful login. This is the request that proves — or disproves — that the
browser stored the cookie and attached it to a cross-subdomain call.
3 · Re-check after a hard reload
The interesting failure is a cookie that is set but not sent back on a
later request. Log in above, then hard-reload
(Ctrl/Cmd + Shift + R) and press this button. It repeats the
/v1/auth/me call using nothing but what the browser persisted across the reload.
4 · Log out
POST /v1/auth/logout, sent with no body and no custom headers so it stays a
simple request and skips the preflight. Revokes the session and clears the cookie;
204, no body. A later /v1/auth/me should then say
invalid or expired session, not
missing credentials — that difference is what tells cookie
transport apart from a dead session.
Request log
Nothing sent yet.
Response headers are not shown: auth sets no
Access-Control-Expose-Headers, so a cross-origin page cannot read
X-Request-Id. Find it in the gateway log instead. Where a request produced no
HTTP response at all, the browser's real reason is only in DevTools → Console.