Skip to content

feat(dashboard): allow trusted reverse-proxy Host headers#27113

Open
jadametz wants to merge 1 commit into
NousResearch:mainfrom
jadametz:feat/dashboard-allowed-hosts
Open

feat(dashboard): allow trusted reverse-proxy Host headers#27113
jadametz wants to merge 1 commit into
NousResearch:mainfrom
jadametz:feat/dashboard-allowed-hosts

Conversation

@jadametz

Copy link
Copy Markdown

What does this PR do?

Adds an explicit trusted Host-header allowlist for the Hermes dashboard so operators can keep the dashboard bound to loopback while accessing it through a trusted local reverse proxy such as Tailscale Serve.

Today, that safer setup can fail with Invalid Host header because the browser reaches the dashboard using the reverse proxy's external hostname while Hermes is bound to 127.0.0.1. Binding the dashboard directly to 0.0.0.0 --insecure works around that, but it weakens the default safety model.

This PR keeps the existing DNS-rebinding protection by default and adds an opt-in HERMES_DASHBOARD_ALLOWED_HOSTS environment variable for trusted reverse-proxy hostnames. Host values are normalized before comparison, including host:port and bracketed IPv6 forms such as [::1]:9119.

It also documents the Tailscale Serve/reverse-proxy pattern and clarifies why these trusted proxy hosts are not added to CORS origins: navigating directly to the proxied dashboard hostname is not a cross-origin browser fetch.

Related Issue

Related to #10567 and #15731.

Also related to the currently open #20136, which takes a broader config-based approach for trusted reverse proxy hosts and WebSocket validation. This PR is the smaller environment-variable scoped approach for HTTP Host-header validation and documentation.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • hermes_cli/web_server.py
    • Add _host_header_name() to normalize Host headers consistently.
    • Add _configured_allowed_host_values() to parse HERMES_DASHBOARD_ALLOWED_HOSTS as comma- or semicolon-delimited hostnames.
    • Accept explicitly configured trusted hosts in _is_accepted_host() while preserving default localhost/DNS-rebinding protections.
    • Document that allowed hosts are matched literally and do not support wildcards/globs.
    • Clarify why reverse-proxy hostnames are intentionally not added to CORS origins.
  • tests/hermes_cli/test_web_server_host_header.py
    • Add coverage for trusted proxy host allowlisting.
    • Add regression coverage for bracketed IPv6 Host headers with and without ports.
    • Add coverage for comma/semicolon-delimited allowlist entries, case normalization, port stripping, and IPv6 allowlist entries.
  • website/docs/user-guide/features/web-dashboard.md
    • Add a short reverse-proxy/Tailscale Serve section showing loopback binding plus HERMES_DASHBOARD_ALLOWED_HOSTS.
    • Document delimiter behavior, port normalization, literal matching, and wildcard non-support.

How to Test

  1. Run the Host-header test suite:

    python -m pytest tests/hermes_cli/test_web_server_host_header.py -q -o 'addopts='

    Expected result:

    11 passed
    
  2. For a manual Tailscale Serve/local reverse-proxy setup, keep Hermes bound to loopback and set the trusted proxy hostname:

    HERMES_DASHBOARD_ALLOWED_HOSTS=dashboard.example.ts.net hermes dashboard --host 127.0.0.1 --no-open
  3. Verify accepted and rejected Host headers against the loopback-bound dashboard:

    curl -i -H 'Host: dashboard.example.ts.net' http://127.0.0.1:9119/api/status
    curl -i -H 'Host: evil.example' http://127.0.0.1:9119/api/status

    The configured trusted host should be accepted, while an unlisted external host should still be rejected.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: Linux 6.17.0

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — or N/A (HERMES_DASHBOARD_ALLOWED_HOSTS is an environment variable, not a config key)
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Targeted tests pass:

$ python -m pytest tests/hermes_cli/test_web_server_host_header.py -q -o 'addopts='
...........                                                              [100%]
11 passed in 0.73s

I also attempted the full suite with:

python -m pytest tests/ -q -o 'addopts='

The run does not complete cleanly on the current branch because of an existing baseline failure that is also present on origin/main:

FAILED tests/acp/test_registry_manifest.py::test_agent_json_version_matches_pyproject
FAILED tests/acp/test_registry_manifest.py::test_agent_json_pins_uvx_package_to_pyproject_version

Both origin/main and this branch currently have:

acp_registry/agent.json: 0.13.0
pyproject.toml: 0.14.0

So the full-suite checkbox is intentionally left unchecked; the targeted dashboard tests for this change pass.

Add HERMES_DASHBOARD_ALLOWED_HOSTS so localhost-bound dashboards can
accept explicit Host headers from trusted local reverse proxies such as
Tailscale Serve without falling back to all-interface insecure binds.

Keep the default DNS-rebinding protection intact and cover the opt-in
behavior with host-header tests.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/cli CLI entry point, hermes_cli/, setup wizard area/config Config system, migrations, profiles labels May 16, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Competing with #20136 (config-based dashboard.allowed_hosts) and #25173 (also dup of #20136). This PR uses an env-var approach (HERMES_DASHBOARD_ALLOWED_HOSTS) while #20136 uses config keys. See also closed #22437 (similar env-var approach) and #20884 (CLI flag approach, dup of #20136).

@StartupBros

Copy link
Copy Markdown

Hey @jadametz — there are a handful of competing dashboard-host-allowlist PRs open right now and the duplicate-detector bot linked them; sharing one observation that may be useful.

Same placement comment as I left on #25173: the _configured_allowed_host_values() check runs before the bind discrimination, so the env var widens 0.0.0.0 binds and explicit-non-loopback binds equally. An operator who deliberately bound to my-server.corp.net will now also accept anything in HERMES_DASHBOARD_ALLOWED_HOSTS.

Two small things in your PR that I really liked and would borrow:

  • The _host_header_name extraction is cleaner than my inline parsing — nice cleanup.
  • The CORS comment about why proxied origins aren't a cross-origin browser fetch is exactly right and worth keeping.

I opened #29195 with the same env-var name idea but gated inside the loopback-bind branch + a regression test for the non-loopback-bind case. Happy to fold your _host_header_name helper into it (or vice versa) if the maintainer prefers your factoring.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused patch and the useful tests around Host normalization.

Problems

  • The reported failure is real on current main: loopback binds only accept loopback Host values in hermes_cli/web_server.py:342-345, and the middleware returns 400 Invalid Host header via hermes_cli/web_server.py:365-377.
  • The implementation shape conflicts with the repo rubric: AGENTS.md:102-107 says new HERMES_* env vars for non-secret behavioral config should not be added; this PR introduces and documents HERMES_DASHBOARD_ALLOWED_HOSTS (5e354609:hermes_cli/web_server.py:179-194, 5e354609:website/docs/user-guide/features/web-dashboard.md:150-158).
  • The allowlist check runs before bind-mode discrimination (5e354609:hermes_cli/web_server.py:214-217 before 222-230), so it also widens explicit non-loopback binds. Current main intentionally requires exact Host matching for explicit non-loopback binds at hermes_cli/web_server.py:347-348.

Suggested changes

  • Prefer a dashboard.allowed_hosts config key and keep any env bridging consistent with existing config override conventions.
  • Apply extra allowed hosts only in the loopback-bind branch.
  • Add a regression test proving allowed hosts do not affect explicit non-loopback binds.

Automated hermes-sweeper review; maintainers make the final call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/cli CLI entry point, hermes_cli/, setup wizard P3 Low — cosmetic, nice to have type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants