dragonflight/services/web-ui/nginx.conf

126 lines
4.6 KiB
Nginx Configuration File
Raw Normal View History

# 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".
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 _;
# 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;
# 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";
}
# 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)$ {
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";
}
# 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/ {
set $api_upstream http://mam-api:3000;
2026-04-07 22:05:41 -04:00
client_max_body_size 0;
proxy_pass $api_upstream;
2026-04-07 21:58:21 -04:00
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
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;
fix: close all 24 open issues (#40–#94) Bug fixes: - #91: dockerApi() 10s socket timeout (Docker daemon hang) - #77: await syncToAmpp() with .catch() — no longer fire-and-forget - #75: migration 016 — add 'proxy','import' to job_type enum; add 'completed' to job_status - #73: BullMQ orphan job cleanup on hard asset delete - #70: batch-trim jobs table gets expires_at; trim-status auto-expires stale rows - #66: scheduler tick marks stale live assets (>2h) as error - #63: migration 017 — partial unique index prevents concurrent live asset overwrite - #61: recorders.js uses getS3Bucket() not stale process.env.S3_BUCKET - #60: already fixed (copy nulls proxy/thumbnail keys, requeues proxy) - #40: already fixed (All projects clears openProject) - #64: already fixed (sourceType/needsProxy handled) - #90: GET /jobs now includes DB jobs table (trim jobs visible in UI) - #74: nginx Content-Type header preserved; multer 500MB file size limit - #68: GET /upload returns in-progress ingesting assets - #58: /stream and /video endpoints fall back to original file for all video types - #55: recorder poll .catch() logs auth errors cleanly; redirect stops interval - #52: thumb-status and thumb-duration moved inside position:relative wrapper - #50: ProjectCard gets onContextMenu handler with rename/delete menu - #49: project context menu dismisses on contextmenu + scroll events Features: - #93: POST /assets/:id/reprocess?type=proxy|thumbnail — force re-queue any asset Asset ⋯ menu now shows 'Re-generate proxy' and 'Re-generate thumbnail' buttons UI: - Logo: brightness(0) invert(1) filter applied consistently in sidebar, launcher, and login — white logo pops on dark UI; inline style removed from login.html
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/ {
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;
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;
}
# Premiere panel downloads — served as binary attachments
location /downloads/ {
add_header Cache-Control "public, max-age=86400";
add_header Content-Disposition 'attachment';
}
# SPA fallback - try to serve file, else route to the React shell.
2026-04-07 21:58:21 -04:00
location / {
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;
}
}