2026-05-27 21:48:49 -04:00
|
|
|
# Map for proper WebSocket upgrade handling on the proxied locations below.
|
fix(web-ui): forward X-Forwarded-Proto from outer proxy so mam-api emits Set-Cookie
This is the real cause of the login loop. mam-api sets its session cookie
with Secure=true (production config). express-session refuses to emit a
Secure Set-Cookie unless req.secure is true. With `app.set('trust proxy')`
on, req.secure derives from X-Forwarded-Proto.
web-ui's nginx was unconditionally sending `X-Forwarded-Proto: $scheme`.
Inside the web-ui container nginx listens on port 80, so $scheme is always
"http" — regardless of whether the outer NPM proxy terminated TLS. mam-api
saw http, decided the connection was insecure, and silently dropped the
Set-Cookie from the login response. Login succeeded server-side (session
row landed in PG, last_login_at updated) but the browser never received a
cookie, so the very next /auth/me check came back 401 and AuthGate bounced
to the login screen. Infinite loop.
The previous Connection: "upgrade" → $connection_upgrade fix wasn't wrong
(the hardcode is a real latent bug worth fixing) — it just wasn't the
proximate cause.
Fix: a second `map` directive forwards the outer X-Forwarded-Proto through
when present, falling back to $scheme only when no proxy header exists (so
direct localhost curls still work). Both /api/ and /capture/ now send the
correct value upstream, mam-api sees https, req.secure is true, Set-Cookie
flows through, login works.
Verified by curling the existing direct-to-mam-api path: with X-Forwarded-
Proto: https on the request, Set-Cookie comes back; without it, no
Set-Cookie. That's the exact difference between web-ui-proxied and
direct-to-mam-api in our previous diagnostic curls.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 22:11:27 -04:00
|
|
|
# Hardcoding `proxy_set_header Connection "upgrade"` puts nginx into tunnel-
|
|
|
|
|
# mode for every request, which has caused subtle bugs in the past. This
|
|
|
|
|
# variant only sets Connection: upgrade when the client actually requested
|
|
|
|
|
# an Upgrade (real WebSocket); otherwise it's "close".
|
2026-05-27 21:48:49 -04:00
|
|
|
map $http_upgrade $connection_upgrade {
|
|
|
|
|
default upgrade;
|
|
|
|
|
'' close;
|
|
|
|
|
}
|
|
|
|
|
|
fix(web-ui): forward X-Forwarded-Proto from outer proxy so mam-api emits Set-Cookie
This is the real cause of the login loop. mam-api sets its session cookie
with Secure=true (production config). express-session refuses to emit a
Secure Set-Cookie unless req.secure is true. With `app.set('trust proxy')`
on, req.secure derives from X-Forwarded-Proto.
web-ui's nginx was unconditionally sending `X-Forwarded-Proto: $scheme`.
Inside the web-ui container nginx listens on port 80, so $scheme is always
"http" — regardless of whether the outer NPM proxy terminated TLS. mam-api
saw http, decided the connection was insecure, and silently dropped the
Set-Cookie from the login response. Login succeeded server-side (session
row landed in PG, last_login_at updated) but the browser never received a
cookie, so the very next /auth/me check came back 401 and AuthGate bounced
to the login screen. Infinite loop.
The previous Connection: "upgrade" → $connection_upgrade fix wasn't wrong
(the hardcode is a real latent bug worth fixing) — it just wasn't the
proximate cause.
Fix: a second `map` directive forwards the outer X-Forwarded-Proto through
when present, falling back to $scheme only when no proxy header exists (so
direct localhost curls still work). Both /api/ and /capture/ now send the
correct value upstream, mam-api sees https, req.secure is true, Set-Cookie
flows through, login works.
Verified by curling the existing direct-to-mam-api path: with X-Forwarded-
Proto: https on the request, Set-Cookie comes back; without it, no
Set-Cookie. That's the exact difference between web-ui-proxied and
direct-to-mam-api in our previous diagnostic curls.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 22:11:27 -04:00
|
|
|
# Forward the outer X-Forwarded-Proto when present; fall back to $scheme.
|
|
|
|
|
# THIS IS WHY LOGIN WAS LOOPING: web-ui listens on port 80 inside the
|
|
|
|
|
# container, so $scheme is always "http". With `proxy_set_header
|
|
|
|
|
# X-Forwarded-Proto $scheme;`, mam-api saw http, decided req.secure=false,
|
|
|
|
|
# and (because cookie.secure=true in production) silently refused to emit
|
|
|
|
|
# the Set-Cookie at all. NPM correctly sends X-Forwarded-Proto: https on
|
|
|
|
|
# the outer request — we just have to pass it through to mam-api.
|
|
|
|
|
map $http_x_forwarded_proto $proxied_x_forwarded_proto {
|
|
|
|
|
default $http_x_forwarded_proto;
|
|
|
|
|
'' $scheme;
|
|
|
|
|
}
|
|
|
|
|
|
2026-04-07 21:58:21 -04:00
|
|
|
server {
|
|
|
|
|
listen 80;
|
|
|
|
|
server_name _;
|
|
|
|
|
|
2026-05-16 08:44:50 -04:00
|
|
|
# Docker embedded DNS — defers upstream resolution to request time
|
|
|
|
|
# This prevents nginx crashing at startup if sibling containers aren't
|
|
|
|
|
# ready yet (which happens on the first `docker compose up`).
|
|
|
|
|
resolver 127.0.0.11 valid=10s ipv6=off;
|
|
|
|
|
|
2026-04-07 22:05:41 -04:00
|
|
|
# Allow unlimited client upload size
|
|
|
|
|
client_max_body_size 0;
|
|
|
|
|
|
2026-04-07 21:58:21 -04:00
|
|
|
# Gzip compression
|
|
|
|
|
gzip on;
|
|
|
|
|
gzip_types text/plain text/css text/javascript application/javascript application/json;
|
|
|
|
|
gzip_min_length 1000;
|
|
|
|
|
|
|
|
|
|
# Root location - serve static files
|
|
|
|
|
root /usr/share/nginx/html;
|
|
|
|
|
|
2026-05-23 15:40:26 -04:00
|
|
|
# Fonts, icons, images: rarely change, safe to cache aggressively.
|
|
|
|
|
location ~* \.(png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
|
2026-04-07 21:58:21 -04:00
|
|
|
expires 1y;
|
|
|
|
|
add_header Cache-Control "public, immutable";
|
|
|
|
|
}
|
|
|
|
|
|
2026-05-23 15:40:26 -04:00
|
|
|
# CSS / JS — must revalidate so a redeploy is picked up immediately.
|
|
|
|
|
# The index.html links these without a version query string, so without
|
|
|
|
|
# this rule a stale stylesheet/script sits in the browser cache forever
|
|
|
|
|
# (which produced the unstyled calendar that triggered this fix).
|
|
|
|
|
location ~* \.(css|js)$ {
|
2026-05-17 08:30:49 -04:00
|
|
|
expires -1;
|
|
|
|
|
add_header Cache-Control "no-cache, must-revalidate";
|
|
|
|
|
}
|
|
|
|
|
|
2026-04-07 21:58:21 -04:00
|
|
|
# HTML files - no cache
|
|
|
|
|
location ~* \.html?$ {
|
|
|
|
|
expires -1;
|
|
|
|
|
add_header Cache-Control "no-cache, no-store, must-revalidate";
|
|
|
|
|
}
|
|
|
|
|
|
2026-05-18 07:29:50 -04:00
|
|
|
# Live HLS — served from /live (bind-mounted shared volume), low cache so playlist refreshes
|
|
|
|
|
location /live/ {
|
|
|
|
|
alias /live/;
|
|
|
|
|
types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; }
|
|
|
|
|
add_header Cache-Control "no-cache";
|
|
|
|
|
add_header Access-Control-Allow-Origin *;
|
|
|
|
|
}
|
|
|
|
|
|
2026-04-07 21:58:21 -04:00
|
|
|
# API proxy - forward to mam-api service
|
|
|
|
|
location /api/ {
|
2026-05-16 08:44:50 -04:00
|
|
|
set $api_upstream http://mam-api:3000;
|
2026-04-07 22:05:41 -04:00
|
|
|
client_max_body_size 0;
|
2026-05-16 08:44:50 -04:00
|
|
|
proxy_pass $api_upstream;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_http_version 1.1;
|
|
|
|
|
proxy_set_header Upgrade $http_upgrade;
|
2026-05-27 21:48:49 -04:00
|
|
|
proxy_set_header Connection $connection_upgrade;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_set_header Host $host;
|
|
|
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
|
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
fix(web-ui): forward X-Forwarded-Proto from outer proxy so mam-api emits Set-Cookie
This is the real cause of the login loop. mam-api sets its session cookie
with Secure=true (production config). express-session refuses to emit a
Secure Set-Cookie unless req.secure is true. With `app.set('trust proxy')`
on, req.secure derives from X-Forwarded-Proto.
web-ui's nginx was unconditionally sending `X-Forwarded-Proto: $scheme`.
Inside the web-ui container nginx listens on port 80, so $scheme is always
"http" — regardless of whether the outer NPM proxy terminated TLS. mam-api
saw http, decided the connection was insecure, and silently dropped the
Set-Cookie from the login response. Login succeeded server-side (session
row landed in PG, last_login_at updated) but the browser never received a
cookie, so the very next /auth/me check came back 401 and AuthGate bounced
to the login screen. Infinite loop.
The previous Connection: "upgrade" → $connection_upgrade fix wasn't wrong
(the hardcode is a real latent bug worth fixing) — it just wasn't the
proximate cause.
Fix: a second `map` directive forwards the outer X-Forwarded-Proto through
when present, falling back to $scheme only when no proxy header exists (so
direct localhost curls still work). Both /api/ and /capture/ now send the
correct value upstream, mam-api sees https, req.secure is true, Set-Cookie
flows through, login works.
Verified by curling the existing direct-to-mam-api path: with X-Forwarded-
Proto: https on the request, Set-Cookie comes back; without it, no
Set-Cookie. That's the exact difference between web-ui-proxied and
direct-to-mam-api in our previous diagnostic curls.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 22:11:27 -04:00
|
|
|
proxy_set_header X-Forwarded-Proto $proxied_x_forwarded_proto;
|
2026-05-26 10:10:44 -04:00
|
|
|
# Preserve Content-Type so multer receives the full multipart boundary (#74)
|
|
|
|
|
proxy_set_header Content-Type $content_type;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_buffering off;
|
|
|
|
|
proxy_request_buffering off;
|
2026-04-07 22:05:41 -04:00
|
|
|
proxy_connect_timeout 300;
|
|
|
|
|
proxy_send_timeout 300;
|
|
|
|
|
proxy_read_timeout 300;
|
2026-04-07 21:58:21 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Capture proxy - forward to capture service
|
|
|
|
|
location /capture/ {
|
2026-05-16 08:44:50 -04:00
|
|
|
set $capture_upstream http://capture:3001;
|
|
|
|
|
proxy_pass $capture_upstream;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_http_version 1.1;
|
|
|
|
|
proxy_set_header Upgrade $http_upgrade;
|
2026-05-27 21:48:49 -04:00
|
|
|
proxy_set_header Connection $connection_upgrade;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_set_header Host $host;
|
|
|
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
|
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
fix(web-ui): forward X-Forwarded-Proto from outer proxy so mam-api emits Set-Cookie
This is the real cause of the login loop. mam-api sets its session cookie
with Secure=true (production config). express-session refuses to emit a
Secure Set-Cookie unless req.secure is true. With `app.set('trust proxy')`
on, req.secure derives from X-Forwarded-Proto.
web-ui's nginx was unconditionally sending `X-Forwarded-Proto: $scheme`.
Inside the web-ui container nginx listens on port 80, so $scheme is always
"http" — regardless of whether the outer NPM proxy terminated TLS. mam-api
saw http, decided the connection was insecure, and silently dropped the
Set-Cookie from the login response. Login succeeded server-side (session
row landed in PG, last_login_at updated) but the browser never received a
cookie, so the very next /auth/me check came back 401 and AuthGate bounced
to the login screen. Infinite loop.
The previous Connection: "upgrade" → $connection_upgrade fix wasn't wrong
(the hardcode is a real latent bug worth fixing) — it just wasn't the
proximate cause.
Fix: a second `map` directive forwards the outer X-Forwarded-Proto through
when present, falling back to $scheme only when no proxy header exists (so
direct localhost curls still work). Both /api/ and /capture/ now send the
correct value upstream, mam-api sees https, req.secure is true, Set-Cookie
flows through, login works.
Verified by curling the existing direct-to-mam-api path: with X-Forwarded-
Proto: https on the request, Set-Cookie comes back; without it, no
Set-Cookie. That's the exact difference between web-ui-proxied and
direct-to-mam-api in our previous diagnostic curls.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 22:11:27 -04:00
|
|
|
proxy_set_header X-Forwarded-Proto $proxied_x_forwarded_proto;
|
2026-04-07 21:58:21 -04:00
|
|
|
proxy_buffering off;
|
|
|
|
|
proxy_request_buffering off;
|
|
|
|
|
}
|
|
|
|
|
|
2026-05-26 10:34:28 -04:00
|
|
|
# Premiere panel downloads — served as binary attachments
|
|
|
|
|
location /downloads/ {
|
|
|
|
|
add_header Cache-Control "public, max-age=86400";
|
|
|
|
|
add_header Content-Disposition 'attachment';
|
|
|
|
|
}
|
|
|
|
|
|
2026-05-23 16:48:38 -04:00
|
|
|
# SPA fallback - try to serve file, else route to the React shell.
|
2026-04-07 21:58:21 -04:00
|
|
|
location / {
|
2026-05-23 16:48:38 -04:00
|
|
|
try_files $uri $uri/ /index.html;
|
2026-04-07 21:58:21 -04:00
|
|
|
expires -1;
|
|
|
|
|
add_header Cache-Control "no-cache, no-store, must-revalidate";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Deny access to dotfiles
|
|
|
|
|
location ~ /\. {
|
|
|
|
|
deny all;
|
|
|
|
|
}
|
|
|
|
|
}
|