dsh-settings-remote

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-01），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

# dsh-settings-remote

> 随 [dsh-weixin-gateway](https://github.com/shaodushu/dsh-weixin-gateway) 仓库 `plugins/` 维护的独立 npm 包。

dsh web 客户端插件：让 **settings.\* 配置平面**（`settings.describe` / `settings.update` / `settings.replace` / `settings.mutate` / `settings.openDocument`）在**非 loopback 页面也可读可写**。

修复经域名反向代理访问 dsh web 时，模型/提供方目录页的两个报错：

- `settings are unavailable in this browser`（客户端镜像门控）
- `transport failure for /api/settings.mutate: HTTP 403`（服务端特权方法硬钉 loopback）

## 背景

dsh 的 `dsh-client-connection` 把 `settings.*` 等配置平面方法硬编码在 `PRIVILEGED_METHODS` 中，对它们用**空信任列表**做 `isTrustedApiRequest` 判定——即使通过 `--trusted-host` 配置了域名也强制 loopback（DNS-rebinding 防御设计）。因此经域名访问时：

- `settings.describe` 被客户端镜像门控（`connection.isLoopback` 判定）挡在页面外
- `settings.mutate` 等写操作被服务端 trust fence 直接 403

本插件从两侧绕过（保持信任边界）：

**服务端半边**（`lib/index.js`）：利用 webServer **exact 路由匹配优先于 /api 前缀路由**的特性，为五个 `settings.*` 方法注册 exact 路由，用**与 /api 前缀路由相同的 trustedHosts 信任墙**（Host ∈ loopback ∪ trustedHosts，Origin 同源，sec-fetch-site ≠ cross-site）放行请求，再原样委托 `apiProxy` 分派。`credentials.*` / `host.*` / `agentPreset.*` 等其他特权方法的 loopback 保护不变。

**客户端半边**（`lib/client.js`）：把设置镜像的持久化强制切到 `"host"` 并主动加载一次，使非 loopback 页面真正发起 `settings.describe`。

## 安装

```bash
dsh plugin --profile web add dsh-settings-remote
```

需要服务端以 `--trusted-host <域名>` 启动 dsh web（IP 与域名都加），并在反向代理处透传 `Host` 头。

## 安全边界

- 仅放行 `settings.*` 配置平面五个方法；`credentials.*`、`host.openPath`、`agentPreset.*` 等仍保持 loopback 硬钉
- 放行依赖 trustedHosts 信任墙：管理员显式配置的域名 + 浏览器同源检查（Origin / sec-fetch-site）

## License

MIT