dsh-web-access

The DeepSeek Harness Web profile ships with no authentication at all: any local process can call /api, RPC channels, or both WebSocket downlinks without restriction. dsh-web-access adds a minimal, local-only auth layer. At startup the server generates a one-time token; on first browser visit it is exchanged for a host-only, HttpOnly, SameSite=Strict session cookie. From that point on, anonymous /api calls, custom RPC channels, and both WebSocket downlink streams return 401, while mismatched Host or Origin headers receive 403. Static HTML, the plugin Client bundle, and HMR metadata stay public so browser bootstrap runs in parallel with auth and first paint is not delayed.

The security boundary is deliberately narrow. The WebServer must bind to 127.0.0.1—passing 0.0.0.0 causes a hard startup refusal. Query tokens, WebSocket subprotocol tokens, duplicate target cookies, and duplicate Authorization headers are all rejected. Every process restart rotates the token, cookie name, and session secret, instantly invalidating prior credentials. The token is never written to cookies, web storage, history state, the DSH_WEB_URL variable, or model context. This plugin protects a local Web profile only; it is not a remote identity system and does not support LAN or public deployments.

It is aimed at developers who run the DSH Web profile locally and want a minimal browser-side auth shield. Desktop runtime developers may also note the ctx.webAccess service interface, which lets a native WebView complete cookie bootstrap outside the sandbox; when the plugin is absent the service does not exist and the runtime decides how to degrade. Uninstalling and restarting cleanly restores the stock 0.1.1-rc.2 unauthenticated behaviour with no residue.