Preface¶

In version 0.1.0-rc.6, the DeepSeek Harness Web UI only provides named routes, an upgrade route, and an SPA fallback, and lacks HTTP middleware. Adding a side-mounted /login route cannot protect existing /api, static admin pages, or WebSocket upgrades. dsh-auth, as a bundle, disables the built-in webserver and inserts an authentication host that provides the same service surface, adding authentication capability to the Web UI without modifying the existing connection, modules, HMR, or frontend-static setup.

What It Is¶

dsh-auth is a cookie authentication bundle for the DeepSeek Harness Web UI. The project is maintained by radaren and is licensed under the MIT License. It does not read or reuse model API keys from ~/.dsh/.credentials.yaml.

Installation and Enablement¶

Install the plugin using a tarball:

dsh plugin --profile web add ./dsh-auth-0.1.0.tgz

Verify that the composition layer is effective:

dsh web --dump-config

The output should show both the disabled webserver and the new auth-webserver.

Core Features¶

The plugin provides the following capabilities:

• Address binding: supports binding to loopback, 0.0.0.0, or a specified IPv4 address.
• Token management: reads a dedicated access token from $DSH_HOME/token (default ~/.dsh/token); if the token does not exist, it generates a 32-byte random value and saves it with 0600 permissions.
• Login and Cookie: includes a built-in /auth/login page; after successful login, it writes an HttpOnly; SameSite=Strict cookie.
• Route protection: uniformly protects the SPA, HTTP API, and WebSocket upgrades.
• Remote API: after login, exposes Harness’s remote management API and removes the auth cookie before passing requests downstream.
• Compatibility layer: adds a crypto.getRandomValues()-based UUID v4 compatibility implementation for cleartext LAN origins.
• Lifecycle: provides logout and global token rotation.

Usage Examples¶

Local access:

dsh web

Open the URL printed in the command line. If ~/.dsh/token did not previously exist, the plugin creates it automatically. The login token can be read from this file:

cat ~/.dsh/token

Bind a remote IPv4 address:

DSH_AUTH_HOST=0.0.0.0 dsh web

Or specify a particular network interface:

DSH_AUTH_HOST=192.168.1.20 dsh web

Then access the corresponding address. Note that host must be an IPv4 literal and does not accept hostnames.

Enable Secure Cookies for HTTPS:

DSH_AUTH_SECURE_COOKIE=true dsh web

Configuration¶

The plugin is controlled through environment variables:

To modify other fields, fully restate the configuration in $DSH_HOME/profiles/web/cordis.patch.yml. Example:

- id: auth-webserver
  config:
    host: 127.0.0.1
    port: 3080
    tokenFile: !!js dshHomePath('token')
    cookieName: dsh_auth
    cookieMaxAgeSeconds: 2592000
    secureCookie: false
    authPath: /auth
    apiPath: /api
    authorizeRemoteApi: true
    maxLoginBodyBytes: 4096
    protectTokenFile: true

Notes¶

• Single token: the plugin does not provide multi-user support, permission levels, or auditing.
• TLS handling: the plugin does not terminate TLS; public internet use requires an HTTPS reverse proxy and network access controls.
• Permission risk: DeepSeek Harness itself can execute commands and modify files, so it should only be exposed to trusted network environments.
• Cookie limitation: enabling Secure Cookie while accessing http://... directly will fail.
• Address limitation: the host parameter must be an IPv4 literal and does not accept hostnames.

Conclusion¶

dsh-auth solves the lack of middleware protection in the DeepSeek Harness Web UI in version 0.1.0-rc.6 by introducing a cookie authentication layer. It does not depend on model API keys; instead, it uses a local token file for access control, making it suitable for local development or intranet deployments that require independent authentication.

Project homepage: https://github.com/radaren/dsh-auth
Community directory: https://www.skillhub.cn/plugins/radaren/dsh-auth