Yuuz12/dsh-webui-auth

Name: Yuuz12/dsh-webui-auth
Author: Yuuz12

Bundle捆绑包 Native原生 ⭐ 8 MIT Approval & Security审批与安全 Clients & Launchers客户端与启动器 Sessions & Context会话与上下文

WebUI authentication: HTTP/transport layer enforced login (four layers of protection: resources, plugin bundles, /api, WebSocket), server-side sessions + HttpOnly cookies.

Project Overview项目介绍

Edited by Zhiwei Agent (zhiwei)由知微Agent(zhiwei)编辑

This is a native DSH bundle plugin that adds persistent authentication to the DSH WebUI. It can be installed via the official DSH plugin command from npm or GitHub, and manual installation is also supported for advanced users. It requires an installed Node.js environment and pnpm package manager. If you don’t already have pnpm enabled, you can set it up easily by running corepack enable pnpm, which is included with modern Node.js installations. The plugin enforces authentication at the HTTP transport layer, so unauthenticated browsers cannot access any WebUI resources, APIs, or real-time connections, and it cannot be bypassed via browser developer tools.

This plugin is intended for users who expose their DSH WebUI to a local area network or public network, and need to control who can access the instance. After installation, users create an account and password either in the DSH settings “Authentication” panel or on the first-access login page. It protects four layers of entry points: WebUI static resources, plugin bundles, API endpoints, and WebSocket connections. It follows a fail-closed principle, meaning that if route wrapping is incomplete for any reason, it will disable authentication entirely instead of leaving an unprotected opening for attackers. It also does not modify any DSH core source code, so DSH upgrades will not break the plugin.

This plugin is released under the open source MIT license. Credentials are persisted to disk as scrypt hashes, and plaintext passwords are never stored anywhere. Sessions are also persisted to disk, so restarting DSH does not drop active sessions, and modifying your password automatically revokes all other existing sessions. For reverse proxy or non-loopback LAN deployments, you must add your external domain to DSH’s trustedHosts configuration to allow WebSocket connections after authentication. All authentication events are audit logged in a local JSONL file, and client IP addresses are pseudonymized via HMAC before storage.

这是专为 DeepSeek Harness (DSH) 开发的原生身份认证持久化插件，用于给 DSH WebUI 添加访问控制门禁。未认证的浏览器无法加载任何 WebUI 资源、调用接口或建立实时连接，认证在 HTTP 传输层强制执行，无法通过浏览器开发者工具绕过。插件不修改 DSH 核心源码，仅在运行时包装路由，因此 DSH 核心升级不会影响插件功能，也不会留下安全漏洞。

本插件适合将 DSH WebUI 暴露到局域网或公网的用户使用，用于管控访问权限。安装完成后，用户可在 DSH 设置的「身份认证」面板或首次访问的登录页创建账号密码。它覆盖四层访问入口：WebUI 静态资源、插件包、API 接口与 WebSocket 连接，遵循故障关闭原则，若路由包装不完整则直接禁用认证，避免出现安全漏洞。

本插件采用 MIT 许可证开源，可通过 DSH 官方 plugin 命令从 npm 或 GitHub 安装，手动安装也支持。依赖 Node.js 环境与 pnpm 包管理器，pnpm 可通过 Node 自带的 corepack enable pnpm 启用。会话和凭据持久化存储在磁盘，密码以 scrypt 哈希保存，明文不落地，反代部署下需额外将对外域名加入 DSH 配置的 trustedHosts 列表。

View on GitHub在 GitHub 查看

Send to your DSH发给你的 DSH 安装

请帮我安装这个 DSH 插件。安装前先完成【兼容性检查 + 安全性检查】，检查通过再动手。

插件：dsh-webui-auth（Yuuz12/dsh-webui-auth）
仓库：https://github.com/Yuuz12/dsh-webui-auth
本站详情页：https://www.yhbd.top/plugins/yuuz12-dsh-webui-auth/
本站登记：类型 bundle · 归类 原生 DSH 插件 · 许可证 MIT · ⭐ 8 · 最近提交 2026-09-16 · 主语言 JavaScript

按下面顺序执行，每步先把结论告诉我，再进入下一步：

【1 兼容性检查】
① 我这边：DSH 版本、Node 版本、操作系统、当前 profile（web / desktop）。
② 读它的 README、package.json、插件 manifest，列出它要求的 DSH 版本 / Node 版本 / 操作系统 / 外部依赖 / 需要另外先装的运行时。
③ 逐条比对，结论只写「满足 / 不满足 / 未知」三种；不满足的给出可行替代方案。
④ 检查是否和我已装的插件冲突：命令名重复、skill / tool 重名、端口占用、重复注册的 MCP server。

【2 安全性检查】
① 仓库可信度：和上面「本站登记」是否一致；star / fork 数、创建时间、最近提交，是否归档或长期停更。
② 安装脚本：逐行看 package.json 的 preinstall / install / postinstall，以及 install.sh、setup.ps1 之类脚本。出现 curl|bash、下载后直接执行、混淆代码、访问与插件功能无关的域名，立刻停下来告诉我，不要继续装。
③ 依赖：列出新增依赖，标出无人维护、或与知名包拼写近似的可疑包（typosquatting）。
④ 权限与副作用：它会读写哪些目录、访问哪些域名、需要哪些 DSH 权限（filesystem / network / shell / clipboard 等），以及怎么卸载和回滚。
⑤ 如果它要求 sudo / 管理员权限，或权限明显超出功能所需，先停下来问我。

【3 安装】
上面两步没有「不满足」和「高危项」时才执行；用官方推荐方式安装，不要自行提权。

【4 汇报】
用表格输出：检查项 / 结论 / 依据 / 是否需要我决策。拿不准的一律写「未知」并说明要我怎么确认——不要猜，也不要替我决定。

Send this message to DSH in your current session: it verifies compatibility and security first (answering met / not met / unknown item by item) and only installs once everything checks out — it will stop and ask you if it finds a high-risk item. The box scrolls; the copy is the full prompt. CLI install commands may not be accurate across systems, so DSH is the safer route.把上面这条消息直接发给当前会话里的 DSH：它会先核对兼容性与安全性（逐条给「满足 / 不满足 / 未知」），确认没问题再安装，有高危项会停下来问你。框内可滚动，复制到的是完整提示词；安装命令不一定准确，发给 DSH 更稳。

Pre-install check安装前体检Compatibility · Security兼容性 · 安全性 1 warning1 项注意

Only 8 stars - very few users, little community feedback星标只有 8，几乎没人在用，遇到问题缺少社区反馈

DSH walks through these 9 checksDSH 会逐条核对这 9 项

Compatibility兼容性

DSH, Node, OS and profile requirementsDSH 版本 / Node 版本 / 操作系统 / profile 是否满足要求
External dependencies and runtimes (Electron / Python / Docker, ...)外部依赖与运行时（Electron / Python / Docker 等）是否齐备
Conflicts with installed plugins: command names, skill / tool names, ports, duplicate MCP registration与已装插件是否冲突：命令名、skill / tool 重名、端口占用、重复 MCP 注册

Security安全性

Repo matches the facts registered here; archived or abandoned?仓库是否与页面登记一致，是否归档或长期停更
Safety of preinstall / install / postinstall and install.sh / setup.ps1preinstall / install / postinstall 与 install.sh、setup.ps1 是否安全
curl|bash, download-then-execute, obfuscation, unrelated domains → stop immediatelycurl|bash、下载即执行、混淆代码、无关域名 → 立刻停止
Typosquatting or unmaintained packages among the new dependencies新增依赖里有没有 typosquatting 或无人维护的包
Requested permissions vs. what the feature actually needs申请了哪些权限、是否超出功能所需（filesystem / network / shell / clipboard）
Any sudo / admin requirement, plus uninstall and rollback是否要求 sudo / 管理员权限，以及卸载与回滚方式

Anything uncertain must be marked unknown with a note on how to confirm it. This site's signal screen is a static snapshot, not a security audit.拿不准的必须标「未知」并说明要我怎么确认。本站的信号筛查是静态快照，不能替代安全审计。

Or use CLI install (for developers)或使用命令行安装（适合开发者）

CLI Install命令行安装

npx @deepseek-ai/dsh plugin --profile web add dsh-webui-auth

把 Yuuz12/dsh-webui-auth 加入你的 DSH 配置（web profile）即可启用。

READMEREADME

17.7 KB · 缓存于 2026-09-16 19:40:02 · 17.7 KB

dsh-webui-auth

English | 中文

DSH WebUI 身份认证插件（持久化插件）。在「设置 → 身份认证」或首次访问登录页创建账号密码后，未认证的浏览器无法加载 WebUI 的任何资源、调用任何接口或建立任何实时连接——认证在 HTTP/传输层强制执行，不可通过浏览器开发者工具绕过。

架构

认证由四层组成，全部通过运行时包装 webServer 路由实现，不改动任何 DSH 核心包源码：

层	机制	未认证行为
WebUI 资源（index.html、/assets/*、SPA 路由）	插件注册 `prefix ''` 兜底路由，校验会话后转交 frontend-static	302 → 登录页
插件 bundle（/plugins/*）	运行时包装 `/plugins` 前缀路由 handler	401
/api RPC 接口	运行时包装 `/api` 前缀路由 handler	401
WebSocket（`/api/remote.mux`；旧核心 `/api/events.mux`、`/api/events.host`）	运行时包装 upgrade 路由 handler	401 拒绝升级

不修改核心包：dsh 升级不会覆盖补丁、不会产生「升级后 /api 裸奔」的窗口。插件每次启动对路由表重做包装，并用 2s→10s 重扫捕获晚注册路由。v0.1.2-alpha.2 及更新核心的事件流 WebSocket 位于 /api/remote.mux（由 dsh-api-gateway 注册），候选列表自动适配，不再误报「upgrade 路由缺失」。
fail-closed：若预期路由缺失（dsh 内部结构变化导致包装不上），setup/configure 会拒绝启用认证，并在宿主日志与设置页同时报错——宁可不可用，不可「开了登录却裸奔 /api」。
与核心自带浏览器认证（v0.1.2-alpha.2+）协作：该版本核心自带 launch-token 交换的签名 Cookie（dsh-auth-*）认证 / 与 /api。插件登录成功后自动把浏览器引导到核心的带 token 根 URL 完成核心 Cookie 交换；/api 请求在插件会话校验后原样转交给核心（不再改写 Host/Origin，避免破坏核心 Cookie 与 Host 绑定）。两者叠加：浏览器须同时持有插件会话 Cookie 与核心 Cookie。
反代/局域网旧核心下的特权方法（≤alpha.1）：已认证请求由插件在会话校验后以「回环形状」转交核心，使核心中回环钉死的特权方法（settings/credentials/agentPreset/llm.discoverModels）在反代部署下可用——会话 Cookie 闸门是比 Host 启发式更强的身份证明。
WebSocket 与 trustedHosts：WS 升级握手仍受核心自身 requestRejection / isTrustedApiRequest 限制，因此反代/局域网（非回环 Host）部署下，WS 下行需要同时在 dsh 配置中把对外域名加入 client-connection.trustedHosts，否则即使已登录也会被拒绝升级。
登录后跳转的协议自适应（0.3.3，修 #6 / #7）：插件登录成功后要把浏览器引导到核心的带 token 根地址，其 authority 取自本次请求的 Host（不再写死 127.0.0.1），scheme 按请求实际协议解析，优先级：① 操作者显式声明 remote-web-ui.publicBaseUrl（仅当其 host/port 与本次请求 Host 一致时采信——否则局域网直连会被重定向到公网地址、跨源丢掉刚下发的会话 Cookie）；② 标准代理头 X-Forwarded-Proto（取最左值）或 RFC 7239 Forwarded: proto=；③ socket 自身是 TLS（插件直接终结 TLS）；④ 兜底 http。刻意不做「非 IP 域名即 https」的猜测——那会把纯 http 的内网域名访问（http://nas.local:3080）打成 https 死链。前端登录页另有一层单向兜底：页面在 https 下收到同源 http:// 跳转时自动升级为 https://（反向不降级、异源不改写）。
桌面端标记透传（0.3.5，修 #8）：DSH Desktop 的 advanced / extended 模式会在组合层禁用核心 ui-layout 行，此时客户端 layout 服务的唯一提供者是桌面端自己的客户端插件，而它只在 URL 带 dsh-desktop-* 标记时才生效（标记缺失时 parseDesktopClientEnvironment() 返回 undefined，apply() 直接 return）。任何一次落到干净 / 的跳转都会丢掉这些标记 → 12 个依赖 layout 的客户端插件永远停在 pending → 渲染器 30s 不上报健康 → 宿主弹出「部分插件加载失败」恢复模式对话框。已确认两条丢标记的路径：① 首次登录——核心 token→cookie 交换把浏览器 303 到干净的 /；② 退出后重登——退出登录是客户端自行 location.href = '/'，服务端从头到尾没看到那个带标记的 URL 被放弃。对策是主动记忆：渲染器正常加载（URL 带标记）时就把标记写进 Cookie（dsh_wua_desktop，HttpOnly / SameSite=Lax / 12h），此后任何一步丢标记，只要文档请求落到干净的 /，就 302 回带标记的 URL。补投发生在文档加载之前，与客户端插件之间不存在竞态。暂存刻意不清除——清除会引入「记住 → 立刻清掉 → 退出后无处可补」的时序陷阱，过期交给 Max-Age。标记按 dsh-desktop- 前缀整体透传（刻意不做硬编码白名单——DSH Desktop 将来新增一个标记时会再次静默弄坏桌面端启动，正是本 issue 的同类耦合），其中 mode 必须是 compatibility/extended/advanced 之一、值长度上限 64；跳转目标恒为同源相对路径 /，无开放重定向面；网页版（无 dsh-desktop-* 标记）零影响。这套适配全部隔离在 lib/desktop-adapter.js，index.js 只保留网关里的两处调用点（标着「宿主适配层」）。该模块不 import 主模块任何东西，可整体摘除；文件头写明了设计取舍、移除步骤，以及新增其它宿主适配的接口约定（{ remember(req,res), restore(req,res) }）。

Showing the opening section of the README — the full document lives in the repository以上为 README 开头摘要，完整文档在仓库内 · View the full README on GitHub →在 GitHub 查看完整 README →

渲染基于仓库 Yuuz12/dsh-webui-auth 的 README.md。在 GitHub 查看原文 →