fix: allow dashboard host headers for trusted proxies

[eco-botfleet-audit]

Summary

• add explicit --allowed-host / dashboard.allowed_hosts support for Hermes Dashboard Host-header validation
• keep the origin bound to loopback while accepting a known reverse-proxy / Cloudflare Access hostname
• add regression coverage for allowed proxy hostnames and wildcard rejection

Why

Cloudflare Access / Tunnel deployments commonly terminate the public hostname at the edge while forwarding to a loopback dashboard origin. The dashboard's DNS-rebinding Host-header guard should keep rejecting arbitrary hostnames, but operators need a narrow, explicit allowlist for the public proxy hostname instead of using --host 0.0.0.0 --insecure as a workaround.

Operational driver: Oss Gruppen audit dashboard issue https://github.com/Oss-Gruppen-AS/enterprise-continuum/issues/450

Test plan

• python -m pytest tests/hermes_cli/test_web_server_host_header.py tests/hermes_cli/test_dashboard_lifecycle_flags.py -q
• live smoke on audit-kanban.scheel.no origin:
  • Host: audit-kanban.scheel.no to 127.0.0.1:9119/api/status returns 200
  • Host: evil.example returns 400
  • process listens on 127.0.0.1:9119, not 0.0.0.0:9119
  • unauthenticated public URL returns Cloudflare Access 302 before Hermes HTML

[alt-glitch]

Competing implementation: multiple open PRs address the same reverse-proxy Host-header allowlist — #20136 (config-based, oldest), #27113 (env-var), #25173 (dup of #20136), #28578 (bundled with i18n fix). This PR adds CLI --allowed-host flag + config support.

[StartupBros]

Hey @eco-botfleet-audit — there are several competing dashboard-host-allowlist PRs and I left similar notes on #25173, #27113, #28578. One observation specific to yours:

The allowed_hosts check is placed after the 0.0.0.0 short-circuit but before the loopback-bind branch:

if bound_host in {"0.0.0.0", "::"}:
    return True

if host_only in _normalize_allowed_hosts(allowed_hosts):
    return True

# Loopback bind: ...
bound_lc = bound_host.lower()
if bound_lc in _LOOPBACK_HOST_VALUES:
    ...

So when the operator binds to a specific non-loopback hostname like my-server.corp.net, configured allowed_hosts will still be accepted — widening the explicit-non-loopback bind. Moving the check inside the bound_lc in _LOOPBACK_HOST_VALUES branch keeps that case strict.

Things in this PR I think are stronger than mine:

• Three-way config surface (config file + CLI flag + plumbed via app.state) is more flexible than my env-only.
• _normalize_allowed_hosts (scheme stripping, wildcard rejection, dedup) is more robust than my comma-split.

I opened #29195 with a narrower env-var-only surface but with the loopback-only placement. If the maintainer prefers your richer config surface, the placement tweak alone would lock down the non-loopback-bind case.

[teknium1]

Thanks for tackling the reverse-proxy dashboard Host allowlist. The premise still holds on current main: a loopback-bound dashboard only accepts loopback Host values in hermes_cli/web_server.py:342-345.

Problems

• In the PR diff, hermes_cli/web_server.py:231 checks allowed_hosts before the loopback-bind branch. That widens explicit non-loopback binds, which current main keeps strict via exact match at hermes_cli/web_server.py:347-348.
• The sibling WebSocket Host/Origin guard is not plumbed. Current main enforces that path at hermes_cli/web_server.py:10032 and :10049, outside HTTP middleware, so proxied dashboard chat traffic would still fail.
• hermes_cli/main.py:10186 adds HERMES_DASHBOARD_ALLOWED_HOSTS for a behavioral setting. AGENTS.md:102-107 says non-secret config should live in config.yaml rather than new user-facing HERMES_* env vars.

Suggested changes

• Move allowed_hosts acceptance inside the loopback branch only.
• Pass the normalized allowlist into WebSocket Host/Origin validation and add a regression test for proxied Host + Origin.
• Keep the public surface to dashboard.allowed_hosts and --allowed-host.

Automated hermes-sweeper review.

[teknium1]

This allowlist check needs to live inside the loopback-bind branch. As written, a server explicitly bound to a non-loopback hostname will also accept any configured proxy hostname, weakening the exact-match rule for that mode.

[teknium1]

Please avoid adding a public HERMES_* env var for this non-secret behavior; AGENTS.md says behavioral settings should go through config.yaml rather than new user-facing environment variables.