fix(dashboard): read SPA gating from the mounted app, not the module global

[joelbrilliant]

The problem

Every route in mount_spa(application) registers on the application parameter, but _serve_index decided the auth scheme from the module-level app:

gated = bool(getattr(app.state, "auth_required", False))   # module global

Production calls mount_spa(app), so the two are the same object and today's behaviour is correct. But the SPA's auth scheme was being read from an object it was not mounted on.

Why it matters

That flag decides whether the long-lived _SESSION_TOKEN is injected into index.html. Gated mode withholds it and the browser authenticates with a cookie session instead; ungated mode injects it — which is exactly the property that makes it safe to put the dashboard behind a reverse proxy.

So a second mount (an embedded host, a test harness, any future sub-app) inherits the global's gating rather than its own. A gated app whose global is ungated would emit the very token gated mode exists to withhold.

Found while writing a test for that no-token invariant: setting auth_required on the app under test had no effect, because the code was reading a different app.

The fix

Read from application — the app the SPA was actually mounted on.

One line. Behaviour-identical in production (single caller, mount_spa(app)), correct for every other mount.

Tests

Two, with the app and the global deliberately disagreeing, which is the only way to tell the seams apart:

• gated app + ungated global → stays gated, no token in HTML (the security-relevant direction)
• ungated app + gated global → stays ungated, token present

Both fail before the change and pass after. tests/hermes_cli/test_web_server.py: 508 passed.

[teknium1]

Thanks for the focused fix. Current main confirms the premise: mount_spa(application) registers SPA handlers on application (hermes_cli/web_server.py:15868, hermes_cli/web_server.py:15886), while _serve_index currently reads the gate from module-global app (hermes_cli/web_server.py:15818). That gate controls the token-injecting branch at hermes_cli/web_server.py:15820-15835.

The proposed application.state.auth_required read in 7ee4818f scopes the decision to the mounted app and the two opposite-state cases cover the relevant seam.

Automated hermes-sweeper review.

[joelbrilliant]

Thanks for confirming the mounted-app seam. I’ve rebased the branch onto current main as 4e3a1d877 and retained the two opposite-state regressions. The focused web server suite passes 106/106 and Ruff is clean. The merge conflict is cleared and fresh CI is now running.