kiwi_guest_id cookie set with Secure flag on HTTP direct access — session lost on every request #105

New issue

Closed

opened 2026-04-18 09:12:43 -07:00 by pyr0ball · 0 comments

pyr0ball commented

2026-04-18 09:12:43 -07:00

Owner

Summary

The kiwi_guest_id session cookie is always set with Secure=True in CLOUD_MODE. When accessing the stack directly on HTTP (e.g. http://localhost:8515 for developer testing), browsers refuse to send the cookie back, so every request creates a new anonymous session. Any item added in one request is invisible in the next.

Steps to reproduce

Open http://localhost:8515 in a browser (direct port, no Caddy/HTTPS)
Add a pantry item
Refresh or navigate — the item is gone (new session created)

Expected

Direct HTTP access maintains session continuity for developer testing.

Actual

Set-Cookie: kiwi_guest_id=...; Secure — browser will not send this cookie on HTTP, breaking all session state.

Root cause

cloud_session.py _resolve_guest_session() passes secure=CLOUD_MODE to response.set_cookie(). When CLOUD_MODE=true, Secure=True regardless of the transport protocol. For production via Caddy (HTTPS) this is correct. For direct HTTP dev access it breaks sessions.

Note

This does not affect production traffic via menagerie.circuitforge.tech (served over HTTPS). It only affects developer testing via direct port. Still worth fixing to avoid confusing test results.

Fix

Only set secure=True when the request itself is over HTTPS, or document that direct-port testing requires a browser with --unsafely-treat-insecure-origin-as-secure flag. Alternatively add CLOUD_AUTH_BYPASS_IPS to the dev .env so the bypass session (no cookie needed) is used for LAN testing.

## Summary The `kiwi_guest_id` session cookie is always set with `Secure=True` in CLOUD_MODE. When accessing the stack directly on HTTP (e.g. `http://localhost:8515` for developer testing), browsers refuse to send the cookie back, so every request creates a new anonymous session. Any item added in one request is invisible in the next. ## Steps to reproduce 1. Open `http://localhost:8515` in a browser (direct port, no Caddy/HTTPS) 2. Add a pantry item 3. Refresh or navigate — the item is gone (new session created) ## Expected Direct HTTP access maintains session continuity for developer testing. ## Actual `Set-Cookie: kiwi_guest_id=...; Secure` — browser will not send this cookie on HTTP, breaking all session state. ## Root cause `cloud_session.py` `_resolve_guest_session()` passes `secure=CLOUD_MODE` to `response.set_cookie()`. When `CLOUD_MODE=true`, `Secure=True` regardless of the transport protocol. For production via Caddy (HTTPS) this is correct. For direct HTTP dev access it breaks sessions. ## Note This does not affect production traffic via `menagerie.circuitforge.tech` (served over HTTPS). It only affects developer testing via direct port. Still worth fixing to avoid confusing test results. ## Fix Only set `secure=True` when the request itself is over HTTPS, or document that direct-port testing requires a browser with `--unsafely-treat-insecure-origin-as-secure` flag. Alternatively add `CLOUD_AUTH_BYPASS_IPS` to the dev `.env` so the bypass session (no cookie needed) is used for LAN testing.