Introduction

The Web GUI of DeepSeek Harness (hereinafter referred to as DSH) does not include a login by default; it assumes a single user on localhost. Once the service is bound to 0.0.0.0—whether accessed via mobile, shared within a local area network (LAN), or handed over to a small team—anyone on the same network can open this page: read all sessions, consume the model API key configured by you, or even modify host settings.

The philosophy of DSH is “everything is a plugin,” meaning such capabilities do not require modifying the core itself. The islibaodong/dsh-login introduced below is exactly such a plugin: it adds a login wall, a multi-account system, and session boundaries isolated by user to the Web GUI, transforming a single-user deployment into a controllable multi-user deployment.

What is this

islibaodong/dsh-login is a multi-user login gateway plugin for the DSH Web GUI. It is maintained by islibaodong, licensed under MIT, and categorized under admin-security. It consists of three main capabilities: a login wall, user management within the GUI, and session/workspace isolation per user. Adding and managing users does not require CLI; everything is completed within the Web GUI.

Core Features

Login Wall

Pages, static resources, SPA routes, APIs, and WebSockets all require a valid session; unauthenticated access is uniformly redirected to /login. This means that not only are pages inaccessible, but direct API requests and WebSocket connections are also blocked.

Multi-account and User Management

The first visit displays a one-time “Create Administrator Account” page. Subsequent new users are added by the administrator: after logging in, go to Settings → User Management → New User.

The user management panel provides the last login time, the number of online sessions, and three operations: reset password, disable, and remove. Disabling, removing, or changing the password immediately revokes the user’s online sessions.

The settings for dsh-login itself are separated by user: Administrators see Settings → User Management, while regular users see Account (Identity + Logout). Regular users do not call the administrator API, and every user can find a logout entry in the settings panel.

Isolation of Sessions and Workspaces per User

Regular users can only see and operate on their own sessions (including those they created subagents/forks); sessions, messages, and workspaces belonging to others are completely invisible. Management domains like credentials and host settings are generally prohibited for regular users.

Administrators are an exception: they are not isolated, can see all sessions, and have full configuration permissions.

The plugin also provides defaultWorkspace: automatically configuring a default workspace for the user upon their first access to /api.

Remote Access: Automatic Learning of Host Whitelist

The host trust validation for /api uses a dynamic set: LAN literal + trustedHosts + automatically learned hosts. The Host of any successful login is written to the persistent whitelist. Therefore, when accessing the GUI via frp, tunnel, or LAN IP, there is no need to manually edit trustedHosts; the whitelist itself can be managed in Settings → User Management.

Capability Discovery and Silent Read Rejection

Two accompanying mechanisms reduce meaningless errors in the browser of regular users:

  • Capability Discovery: GET /api/auth/capabilities, requires session authentication. The client uses this to understand which capabilities the current session possesses.
  • Silent Read Rejection: Read probes for unauthorized resources return 204 instead of an error; write operations still return 403. This behavior can be toggled via the quietDenials switch.

Session Persistence

Login sessions are persisted to <dataDir>/sessions.json (file permissions 0o600). Existing cookies remain valid after the process restarts. The default TTL is 7 days; they only become invalid upon a real logout, password change, user removal, or TTL expiration.

Installation and Activation

Installation is a single command:

dsh plugin --profile web add github:islibaodong/dsh-login

The reason for --profile web is that DSH installs plugins based on profile directories ($DSH_HOME/profiles/<name>), and web is the profile that launches the Web GUI. If you are using a custom profile, simply replace web in the command with the corresponding name.

During installation, dsh plugin add reads the cordis.patch.yml declared inside the package, automatically completing three things:

  1. Mounting the dsh-login plugin line;
  2. Disabling the web-runtime line (dsh-login takes over the fallback position of frontend-static and re-provides the webRuntime service);
  3. Disabling the built-in connection line (dsh-login mounts its own identity-aware takeover and provides dist/client.js).

After the above steps, restart dsh web and open the GUI. The first visit will display a one-time “Create Administrator Account” page; set your username and password. Then, log in as the administrator and add other users in Settings → User Management → New User.

If not needed, uninstalling is also a single command:

dsh plugin --profile web remove @islibaodong/dsh-login

Manual Installation (Alternative Method)

If you prefer to manage patch files yourself, you can add insert lines to the profile’s cordis.patch.yml:

- insert:
    - id: dsh-login
      name: '@islibaodong/dsh-login'
      config:
        password: DSH_LOGIN_PASSWORD   # Credentials reference name; user storage is named <name>_USERS
        distIndex: ''                  # Leave empty to auto-parse frontend dist
        dataDir: ''                    # Leave empty to resolve to <DSH_HOME>/.dsh-login
        sessionTtl: 604800             # Session TTL, default 7 days
        autoTrustHosts: true           # Successful login Host writes to /api whitelist
        enabled: true                  # Set to false to disable without uninstalling
        defaultWorkspace: true         # Automatically configure default workspace on first /api access
        workspaceRoot: ''              # Root directory for default workspace, empty is <DSH_HOME>/workspaces

Note: Since dsh-login takes over the fallback position and re-provides the webRuntime service, when installing manually, in addition to inserting the lines above, you also need to disable the web-runtime line and the built-in connection line as described in the repository README; other combinations are not affected.

Upgrading from the Old Single-Password Version

Previously, dsh-login was a single-password version. After upgrading from the old version, the old single password can no longer log in anyone. The first visit after the upgrade will guide you to create a new administrator account.

Current Status: Development Paused

The repository README explicitly states: development on this repository is paused. The delivered features—login wall, multi-account management, user isolation, remote web-ui compatibility, capability discovery, and silent read rejection—are fully functional. What is unfinished is the role-based control of third-party UI plugin functions (hiding from unauthorized users, not rendering, and not sending requests), which is blocked by upstream DSH capabilities and cannot be solved by this plugin alone.

Specifically, it is stuck on three upstream limitations:

  1. DSH’s settings panel renders a single global list of sections; plugins cannot show or hide settings sections within dsh-login per user.
  2. DSH WebServer’s route priority is exact-beats-prefix, and there is no pre-routing hook. Third-party plugins registering exact routes by themselves (e.g., /api/pet/pets and /api/pet/state registered by @linxin666/dsh-pet) cannot be intercepted or silenced by dsh-login based on the user.
  3. DSH’s client runtime activates all bundled plugins; there is no activation threshold per user. Unmodified third-party plugins will still trigger mount-period probes for every user.

The author is waiting for upstream DSH to provide per-identity slot/section filtering or conditional plugin activation; at that time, role-based functional control can be implemented on top of the already delivered capabilities.

Applicable Scenarios and Precautions

Suitable scenarios:

  • Exposing the DSH Web GUI to a LAN for multi-user use;
  • Accessing your own GUI from outside via frp or tunnels;
  • Small teams sharing a set of services, each maintaining their own sessions and workspaces.

Precautions before use:

  1. The plugin runs with the permissions of the current dsh process. You should check the source code and license of any third-party plugin before installing it. dsh-login’s license is MIT, and the source code is public on GitHub.
  2. The boundaries of regular users’ capabilities are clear: they can chat normally—create, open, and continue their own sessions, run subagents, and manage the content of their workspace; other operations (reading other users’ sessions, credentials, plugins/presets/host settings, model key management) will be rejected.
  3. Development is paused, and role-based control of third-party plugin functions depends on upstream progress. Please consider these two points when selecting this plugin.

Summary

With a single installation command, dsh-login fills the missing login and multi-user capabilities of the DSH Web GUI: the login wall blocks unauthenticated access, the administrator completes account management within the GUI, sessions between regular users are invisible to each other, and the login state persists after restarts. For users who need to open the GUI to the LAN or remote access, this is the direct way to address this shortcoming.

  • Directory Page: https://www.skillhub.cn/plugins/islibaodong/dsh-login
  • GitHub Repository: https://github.com/islibaodong/dsh-login

skillhub.cn is a community-maintained plugin directory and has no official affiliation with DeepSeek or HF.