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.

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.