dsh web: provide an opt-out for the mandatory browser token auth (reverse-proxy / trusted-LAN deployments)

[erkkimon]

Since 0.1.2 (tested 0.1.2-rc.1), dsh web requires every browser to
open a per-boot ?token=… URL before serving the UI; the token is
printed only on stdout, and a successful visit sets a 30-day cookie
bound to the exact request authority. As far as I can tell from
@deepseek-ai/dsh-client-connection (authorizeIndex /
isAuthenticated) there is no opt-out: no CLI flag, no config field on
the connection plugin, no loopback exemption, and no way to pin the
token via environment.

For a single developer on localhost this is a sensible default. For a
managed deployment it is effectively a hard lock-out:

• I run 16 dsh web instances (4 users × 4 hosts) behind a
  TLS-terminating reverse proxy on a private LAN, addressed by DNS
  names that are already declared via --trusted-host.
• The token lives in each instance's journal and rotates on every
  service restart, so every browser × every instance × every ~30 days
  needs a manual token fetch by an operator.
• The cookie is per-authority, so one instance reached via two names
  needs the dance twice.
• An embedding page (a dashboard that iframes instances) can never
  authenticate at all in Firefox, which partitions third-party
  cookies.

Would you accept one of the following? Happy to send a PR for
whichever shape you prefer:

1. a --no-browser-auth flag on dsh web (or a
   client-connection config field, e.g. browserAuth: false), or
2. treating requests that already pass the --trusted-host fence as
   authenticated, or
3. an environment variable to pin the launch token (so a fleet can
   distribute a stable secret out of band).

We currently maintain a one-line source patch that makes
isAuthenticated() return true, reapplied on every upgrade — workable
but obviously not where this should live.

[argszero]

Source-verified against current master (d347e70390) — your read of the code is exact, with one nuance that changes the recommended shape:

What the code does today. The trust fence and the browser token are two separate gates:

• packages/client/connection/src/api-request-trust.ts — isTrustedApiRequest (:91) accepts a request whose Host is loopback or matches a trustedHosts entry (isTrustedAuthority :75). trustedHosts is a real config field (z.array(String).default([]), index.ts:88). This gate guards API requests.
• packages/client/connection/src/browser-auth.ts — authorizeIndex (:240) guards serving index.html. Its only admission paths are (a) a valid ?token= query minting the authority-bound cookie (:250-263), or (b) a valid unexpired authority-bound cookie via isAuthenticated (:289). Every other request — loopback or trusted-host, API-fence-passing or not — receives the same minimal 401 (:310-316). There is no trustedHosts read anywhere in browser-auth.ts.

So your statement "no opt-out: no flag, no config field, no loopback exemption, no env pin" is exactly right for the index path; the fence you declared via --trusted-host only protects the APIs underneath.

Why I'd be cautious about your option 2 (treating requests that pass the --trusted-host fence as authenticated). The browser token is not arbitrary friction — it is the anti-drive-by-session defense that this codebase's trust-fence lineage (#3210 and the reverse-proxy work) deliberately built: without it, any other LAN user (or a malicious webpage running in any browser that can reach the host) can boot an authenticated UI session against an instance they were never meant to open. On your 4-user × 4-host deployment behind a TLS proxy that is precisely the multi-tenant boundary: if the proxy does not itself authenticate, "trusted host" means "trusted by the operator", not "authenticated as user X". A blanket fence⇒auth rule would hand every user every instance.

The shapes that preserve the defense: your option 1 with the responsibility made explicit — an opt-in (--no-browser-auth flag or a browserAuth: false config field on client-connection) that the operator sets only when the reverse proxy in front performs its own authentication/network isolation. That keeps the secure default and gives managed deployments the escape hatch, with the tradeoff documented next to the flag.

Two smaller fixes that would already remove most of your operational pain without dropping the gate:

1. Token pinning via env — today launchToken is generated per activation, which is why it rotates on every restart and lives in the journal. If the launch token were overridable by an env var (or a fixed browserAuthToken config), your operators would fetch it once per deployment instead of per boot, and the 30-day cookie renewal stays the only periodic dance.
2. Per-authority cookie UX — the cookie name is derived from the authority (cookieName(authority), isAuthenticated), which is why one instance behind two DNS names needs the dance twice. If the authority binding were normalized (e.g. to the trustedHosts entry the request matched), one token visit could cover all declared names for that instance.

The third-party-cookie/iframe case (Firefox partitioning) is genuinely unsolvable at this layer — an iframed instance cannot carry a third-party cookie, so if dashboards are a requirement, that specific embedding path does argue for the explicit opt-in flag scoped to that deployment.