web: does browser-session auth intend to cover routes registered via webServer.register()? (plugin dashboard routes reachable without the ?token= session)

[Kaiji-Z]

Question

Since the browser-session auth landed (per-boot ?token= URL + HMAC dsh-auth- cookie, enforced in packages/client/connection/src/browser-auth.ts), all Host Connection requests are gated by isAuthenticated() — 401 otherwise. Routes that plugins register through the webserver entry (webServer.register(), @deepseek-ai/dsh-host-webserver → packages/api/gateway) appear to sit on a separate handler chain that never passes this gate, so they answer unauthenticated on the same port.

Is this intended (i.e. plugin routes are the plugin own auth responsibility), or should the session gate cover them? If it is intended, would you consider exposing an opt-in so plugins can require the same browser session — right now the token is process-private (printed to console only), so a plugin cannot validate anything by itself.

Reproduction (dsh-v0.1.3-alpha.1, source checkout, web profile, Windows)

With a fresh boot printing dsh web: http://127.0.0.1:3080/?token=...:

curl -s -o /dev/null -w %{http_code} http://127.0.0.1:3080/            # -> 401 (host UI, gated)
curl -s -o /dev/null -w %{http_code} http://127.0.0.1:3080/<plugin-route>   # -> 200 (plugin-registered, ungated)
curl -s -o /dev/null -w %{http_code} -X POST http://127.0.0.1:3080/<plugin-route> -H "content-type: application/json" -d {}   # -> 400 (our own body validation — the request reached plugin business logic unauthenticated)

Our plugin (dsh-plugin-lookatstudy) registers /lookatstudy/api/* via webServer.register(); without any cookie or token, GET returns the full learning state and the POST routes (activate / mode / focus / delete) process writes.

Scope / risk assessment

Low, we believe: the web server binds 127.0.0.1 (LAN unreachable), and the data behind our routes is low-sensitivity learning progress. The residual exposure is local processes and cross-site CSRF-style blind writes from webpages (reads are CORS-blocked; writes are not). The same reasoning presumably applies to any plugin exposing state or write routes this way.

Minimal fix options (in the order we would prefer)

1. Apply the same isAuthenticated() session check to webserver-registered routes before dispatch (plugins keep zero auth code).
2. Or expose an opt-in on webServer.register() (e.g. requireSession: true or an auth-wrapping helper) so existing unauthenticated registrations keep working while new ones can require the browser session.
3. Or, if unauthenticated-by-design: document it loudly at the webServer.register() extension point so plugin authors know the token gate does not protect them.

Happy to send a PR for any of these directions if you point us at the intended one.

[rootkiller6788]

Confirmed on 0.1.3-alpha.1 — your three curls reflect exactly what the code does, and it's layering, not an oversight. ctx.webServer is a bare carrier: named routes, no middleware, and deliberately no auth or Origin policy of its own. The browser-session gate lives entirely in client-connection, which owns a single /api prefix route whose handler runs the Host/Origin fence (403) then isAuthenticated() (401) before dispatch, plus the SPA index at serve time. Routes a plugin registers on any other path never pass through that handler, so they answer unauthenticated.

That means option 1 (gate every plugin route) would be the wrong default, and not one you'd actually want either — the in-repo counter-example is webhook-github, whose route has to stay reachable without a browser session because GitHub posts inbound, and the plugin verifies the webhook signature itself. Per-registrant auth is the intended model.

Your sharpest point is the real gap though: a plugin that wants the session gate has no supported way to get it, since the browser-session credential and token are process-private and Connection exposes no way to opt a handler in. "Document it loudly" is cold comfort for write-route authors who have no tool to be safe with.

So I'd push option 2, hung on Connection rather than the carrier: a wrapper that hands a plugin handler the same requestRejection an /api route gets. The Host fence matters as much as the cookie here — on loopback it's the DNS-rebinding defense, and today's plugin routes don't even get that. A withBrowserSession(handler)-style export (or accepting gated registrations under the /api prefix) keeps current unauthenticated routes working and gives protected ones a real seam. It's a small surface — worth opening as an issue so maintainers can weigh in on the shape.