dsh-auth

The built-in webServer in DeepSeek Harness 0.1.0-rc.6 exposes named routes, an upgrade route, and a SPA fallback, but offers no HTTP middleware layer. Adding a /login route alone cannot protect the existing /api endpoints, static admin pages, and WebSocket connections simultaneously. dsh-auth replaces the built-in webServer with an auth-host bundle that provides the same service surface, placing SPA, HTTP API, and WebSocket upgrade behind a single shared-token login gate.

The login flow is deliberately minimal: the plugin reads or auto-generates a 32-byte random token (file permission 0600), serves a built-in /auth/login page, and writes an HttpOnly, SameSite=Strict cookie on success. Logout clears only the current browser session; replacing the token file and restarting dsh web revokes all sessions. For plain-LAN deployments it injects a crypto.getRandomValues()-based UUID v4 shim so the client bundle does not break when crypto.randomUUID() is unavailable. It fixes API compatibility only and does not upgrade HTTP to a secure context, so public-facing use requires an HTTPS reverse proxy and the Secure cookie flag.

dsh-auth is aimed at operators who manage a Harness web instance on a LAN or behind a proxy and need a credential gate without standing up full OIDC or OAuth2 infrastructure. It does not read model API keys from .credentials.yaml, does not modify existing HMR, connection, or modules plugins, and is ready to use after installation. It is a single shared-token boundary, not a multi-user RBAC or audit system, and it does not terminate TLS. It answers exactly one question: who is allowed to open this Harness instance.