behind reverse proxy #67

New issue

Closed

opened 2026-08-12 19:09:21 +02:00 by zaph0d · 0 comments

zaph0d commented

2026-08-12 19:09:21 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/niels-emmer/myace/pull/67
Author: @niels-emmer
Created: 8/12/2026
Status: ✅ Merged
Merged: 8/12/2026
Merged by: @niels-emmer

Base: main ← Head: fix/oauth-redirect-uri-scheme

📝 Commits (1)

48d1130 fix: forward real X-Forwarded-Proto through frontend nginx instead of overwriting it

📊 Changes

3 files changed (+59 additions, -1 deletions)

View changed files

📝 AGENTS.md (+9 -0)
📝 docs/debugging.md (+38 -0)
📝 frontend/nginx.conf (+12 -1)

📄 Description

Summary

Fixes a production bug where every GitHub/Google/OIDC login attempt behind docker-compose.prod.yml's reverse-proxy setup was rejected by the provider with a redirect-URI-mismatch error, even though the registered callback URL was exactly correct.
Root cause: frontend/nginx.conf's /api/ location unconditionally set X-Forwarded-Proto: $scheme, overwriting the correct https value the external reverse proxy (nginx-proxy-manager) had already set, with its own $scheme — always http, since that container never terminates TLS. The backend trusts X-Forwarded-Proto to build redirect_uri via request.url_for(), so it always generated http://... regardless of the real scheme.
Fix: forward the already-set upstream header, falling back to $scheme only when nothing set it (the no-reverse-proxy, base docker-compose.yml case).
Documented as a new docs/debugging.md entry and extended AGENTS.md rule 27 (production hardening/proxy-header trust chain) — this is exactly the kind of two-hop proxy gotcha that rule already existed to describe, it was just missing this half of the chain.

Test plan

Confirmed the live production bug directly: curl https://myace.macjuu.com/api/v1/auth/login/github showed redirect_uri=http%3A%2F%2Fmyace.macjuu.com%2F... in the Location header before this fix.
Rebuilt the frontend image locally and verified via a temporary debug nginx location that the container now reports computed=https when sent X-Forwarded-Proto: https, and computed=http (unchanged, correct fallback) when not — proving the map forwards the real value instead of always overwriting it.
Confirmed nginx config is syntactically valid (nginx -t, clean startup logs).
Not independently re-verifiable end-to-end against docker-compose.dev.yml — dev's uvicorn command intentionally omits --proxy-headers (dev doesn't need scheme-awareness), so this needed the nginx-layer test above instead.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/niels-emmer/myace/pull/67 **Author:** [@niels-emmer](https://github.com/niels-emmer) **Created:** 8/12/2026 **Status:** ✅ Merged **Merged:** 8/12/2026 **Merged by:** [@niels-emmer](https://github.com/niels-emmer) **Base:** `main` ← **Head:** `fix/oauth-redirect-uri-scheme` --- ### 📝 Commits (1) - [`48d1130`](https://github.com/niels-emmer/myace/commit/48d1130b2fdb0365179737fc4080ed542add8332) fix: forward real X-Forwarded-Proto through frontend nginx instead of overwriting it ### 📊 Changes **3 files changed** (+59 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `AGENTS.md` (+9 -0) 📝 `docs/debugging.md` (+38 -0) 📝 `frontend/nginx.conf` (+12 -1) </details> ### 📄 Description ## Summary - Fixes a production bug where every GitHub/Google/OIDC login attempt behind `docker-compose.prod.yml`'s reverse-proxy setup was rejected by the provider with a redirect-URI-mismatch error, even though the registered callback URL was exactly correct. - Root cause: `frontend/nginx.conf`'s `/api/` location unconditionally set `X-Forwarded-Proto: $scheme`, overwriting the correct `https` value the external reverse proxy (nginx-proxy-manager) had already set, with its own `$scheme` — always `http`, since that container never terminates TLS. The backend trusts `X-Forwarded-Proto` to build `redirect_uri` via `request.url_for()`, so it always generated `http://...` regardless of the real scheme. - Fix: forward the already-set upstream header, falling back to `$scheme` only when nothing set it (the no-reverse-proxy, base `docker-compose.yml` case). - Documented as a new `docs/debugging.md` entry and extended `AGENTS.md` rule 27 (production hardening/proxy-header trust chain) — this is exactly the kind of two-hop proxy gotcha that rule already existed to describe, it was just missing this half of the chain. ## Test plan - [x] Confirmed the live production bug directly: `curl https://myace.macjuu.com/api/v1/auth/login/github` showed `redirect_uri=http%3A%2F%2Fmyace.macjuu.com%2F...` in the `Location` header before this fix. - [x] Rebuilt the frontend image locally and verified via a temporary debug nginx location that the container now reports `computed=https` when sent `X-Forwarded-Proto: https`, and `computed=http` (unchanged, correct fallback) when not — proving the `map` forwards the real value instead of always overwriting it. - [x] Confirmed nginx config is syntactically valid (`nginx -t`, clean startup logs). - Not independently re-verifiable end-to-end against `docker-compose.dev.yml` — dev's uvicorn command intentionally omits `--proxy-headers` (dev doesn't need scheme-awareness), so this needed the nginx-layer test above instead. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

zaph0d

2026-08-12 19:09:21 +02:00