c24c6156dc
Login was infinite-looping in production. Server side was healthy (sessions landing in PG, /me returning 200 to a manually-signed cookie) but the browser never received `Set-Cookie`. Bisected the proxy chain layer by layer with direct curls on the box: - mam-api direct (port 47432) → Set-Cookie present - web-ui nginx (port 47434) → Set-Cookie STRIPPED - NPM (https://dragonflight.live) → Set-Cookie stripped (because web-ui ate it) Root cause was this in /api/ and /capture/: proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; The literal "upgrade" was being sent on every request, not just real WebSocket negotiations. Nginx then routes the upstream response through its tunnel/upgrade code path, which doesn't preserve all response headers the same way — Set-Cookie got silently dropped. mam-api doesn't speak WebSockets today so it never sent a 101, and the bad pattern went unnoticed until session-cookie auth shipped. Fix is the standard conditional pattern: a `map` directive at the top of default.conf computes $connection_upgrade as "upgrade" only when the client actually requested Upgrade, otherwise "close". Both location blocks now send `Connection $connection_upgrade` instead of the hardcoded literal. WebSocket support on either location continues to work unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| capture | ||
| mam-api | ||
| node-agent | ||
| premiere-plugin | ||
| web-ui | ||
| worker | ||