feat(dashboard): HERMES_DASHBOARD_ALLOWED_HOSTS env for reverse-proxy / tunnel deployments#32362
Closed
olavon wants to merge 1 commit into
Closed
feat(dashboard): HERMES_DASHBOARD_ALLOWED_HOSTS env for reverse-proxy / tunnel deployments#32362olavon wants to merge 1 commit into
olavon wants to merge 1 commit into
Conversation
…/tunnel deployments Adds an opt-in allowlist for the dashboard's host-header check so it can sit behind a reverse proxy or tunnel (Cloudflare Tunnel, nginx, Traefik, ...) without disabling the DNS-rebinding defence (GHSA-ppp5-vxwm-4cf7) or exposing the bind to a non-loopback interface. HERMES_DASHBOARD_ALLOWED_HOSTS=hermes.example.com,dashboard.internal Comma-separated, case-insensitive, port-stripped. Loopback names remain accepted unconditionally; any host not on the allowlist (and not matching the bound host / a loopback alias) is still rejected with HTTP 400. Tests: covers allowlisted accept, case-insensitivity, and non-allowlisted reject on a loopback bind.
Collaborator
Author
|
Closing in favor of #27113 — same env-var approach, and per @alt-glitch's note above let's consolidate rather than pile on a 6th PR for this feature. Happy to review/test #27113 if helpful. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
When running the Hermes dashboard behind a reverse proxy or tunnel (Cloudflare Tunnel, nginx, Traefik, Tailscale Funnel, etc.), the host-header DNS-rebinding defence (GHSA-ppp5-vxwm-4cf7) rejects requests because the public Host header (e.g. `hermes.example.com`) doesn't match the loopback bind.
Currently the only escape hatches are:
This is a fairly normal deployment pattern — bind to loopback, expose via an authenticated proxy/tunnel — and the defence shouldn't force users into less-safe alternatives.
What
New opt-in env var:
Pairs naturally with the existing `HERMES_DASHBOARD_HOST` (bind addr) env var.
How
`hermes_cli/web_server.py`:
`tests/hermes_cli/test_web_server_host_header.py`:
Tested
```
$ ./venv/bin/python -m pytest tests/hermes_cli/test_web_server_host_header.py -q
......... [100%]
9 passed, 1 warning in 1.15s
```
Also verified end-to-end on my own deployment (Cloudflare Tunnel → `127.0.0.1:9119` with Cloudflare Access OTP gating the hostname):
Docs
Happy to add a note to `website/docs/user-guide/docker.md` (where `HERMES_DASHBOARD_HOST` is documented) and/or a reverse-proxy section if you'd like — let me know your preference and I'll push it onto this branch.