dshbase

插件目录 / Network / dsh-web-lan-access

dsh-web-lan-access

已验证 · 实测可装 AcidGr

✓ 持续维护 2 位贡献者

查看 GitHub ↗ ← 返回插件目录

35Stars
5Forks
0未关闭 issue
JavaScript语言
2026-09-23最近推送
跨平台平台

功能简介

DSH Web插件

✅
我们的评价
可用 — 实测通过,社区增长中

DSH Web插件 实测能干净安装、正常启动。社区在增长,是个稳妥选择。

「已验证」表示我们的自动化 CI 在干净 profile 里实际执行了 dsh plugin add 并启动成功——仅此而已。功能描述与版本兼容性均为作者声明。这不是安全审计,也不代表对第三方代码的背书。

README

dsh-web-lan-access

awesome · DSH plugin

English | 简体中文

LAN / remote access support for the DeepSeek Harness Web UI.

The problem

The Web UI calls crypto.randomUUID() in boot-critical paths (RPC id minting, message ids, draft attachments). That Web API exists only in secure contexts (HTTPS, or http://localhost / http://127.0.0.1). When the UI is served over plain HTTP from a non-loopback address — a LAN IP, a Tailscale IP, or a hostname — crypto.randomUUID is undefined, every RPC throws, and sessions and models never render.

Current DSH clients also select Host-backed settings from the browser hostname: a non-loopback page is assigned memory-only settings even after browser authentication succeeds. The Models and plugin settings pages therefore remain unavailable on an otherwise working trusted-host deployment.

The fix

A host-side plugin that uses the webserver's official index-tap extension point (webServer.tapIndex) to inject a small bootstrap as the first script in <head>, before the boot manifest and shell entry. The bootstrap:

  • supplies an ordinary HTTP transport carrying DSH's ownsHost deployment signal, enabling authenticated Host settings from the trusted remote page;
  • polyfills crypto.randomUUID with an RFC 4122 v4 implementation built on crypto.getRandomValues, which is available on insecure origins.

The bootstrap leaves a transport supplied by another shell untouched, and the UUID polyfill is a no-op on secure origins.

  • No product source modified; fully reversible
  • Uses DSH's existing index-tap and client-transport extension points
  • Platform-independent (Linux / macOS / Windows / Android)

Install

Method 1: Ask your DSH Agent (Easiest 🤖)

Send this repo URL directly to your DSH chat with the instruction:

"Install this plugin for me: https://github.com/AcidGr/dsh-web-lan-access"

Your DSH Agent will automatically install the package and configure it in the background.

Method 2: Bundle install via CLI (Recommended)

Installed from npm:

dsh plugin --profile web add dsh-web-lan-access

(No npm / local development — point pnpm at the repo instead:

dsh plugin --profile web add github:AcidGr/dsh-web-lan-access

)

Restart dsh web, then hard-refresh the browser.

Method 3: Manual install (no pnpm / offline)

PROFILE="$DSH_HOME/profiles/web"                 # adjust DSH_HOME and profile name
mkdir -p "$PROFILE/plugins" "$PROFILE/node_modules/@dsh-profile"
cp -r dsh-web-lan-access "$PROFILE/plugins/lan-access"
ln -sfn ../../plugins/lan-access "$PROFILE/node_modules/@dsh-profile/lan-access"
# append to $PROFILE/cordis.patch.yml:
#   - insert:
#       - id: lan-access
#         name: '@dsh-profile/lan-access'

Usage

The plugin is self-contained: its bundle patch sets the webserver bind host to 0.0.0.0 directly (the CLI flag --host 0.0.0.0 is hard-rejected for safety on newer harness versions, but the webserver config still accepts it — so no source changes and no --host flag are needed; the CLI --port flag still works). It also widens the /api trust fence automatically.

  1. Install the plugin, then start normally — without --host:

    dsh --profile web --port 3080
    

    The bundle patch re-derives the /api trust fence from every non-internal IPv4 the host currently has — LAN (192.168.x), Tailscale (100.x), and VPN interfaces — and merges in whatever resolveLanTrust already computed. So as long as the remote interface is up when dsh web starts (Tailscale usually autostarts first), LAN and Tailscale IP access need zero extra config: open http://<server-ip>:3080 or http://<tailscale-ip>:3080 and sessions/models load.

    If you prefer NOT to let the plugin take over the bind host (e.g. you want loopback + a port forward), keep the webserver row override out of your tree and instead forward a port (socat / rinetd / Tailscale serve) from 127.0.0.1:3080, adding the forwarded address to trustedHosts manually.

  2. MagicDNS hostnames (e.g. xxx.tailXXXX.ts.net) — the fence can't discover hostnames, only IP literals, so add your own names if you want to browse by name instead of IP. Patch the web-runtime row, whose trustedHosts feed into the fence computation (resolveLanTrust merges them), so your entries stack on top of the auto-discovered IPs:

    - id: web-runtime
      config:
        trustedHosts:
          - <short-name>            # e.g. myhost — MUST be listed separately!
          - <name>.tailXXXX.ts.net  # full domain
    

    Or skip file editing entirely with the repeatable CLI flag (same injection path): dsh --profile web --trusted-host myhost --trusted-host myhost.tailXXXX.ts.net. Use one mechanism or the other — a static list replaces the row's default expression, so it will not merge with --trusted-host.

    ⚠️ The fence compares the Host header literally: a MagicDNS short name (http://myhost:3080) is not the full domain — list the short name on its own line, or every /api call returns 403 (page shell loads, sessions/models absent). Tailscale / LAN IP literals need no entry here — they stay covered automatically.

    ⚠️ Do not retarget this block at the connection row: patch layers compose by whole-key replacement in application order (bundle layers first, then your profile's cordis.patch.yml), so a plain literal array on connection.config.trustedHosts would silently replace the bundle's dynamic fence expression — names would work, but the auto-derived LAN/Tailscale IP trust would vanish. If you truly need connection, copy the full concatenation expression from the plugin's bundle patch and append your literals; never write a plain list there.

Host ownership scope

The transport signal enables every client surface DSH currently associates with owning the Host, not only Models. That includes Host-backed settings and native Host actions such as opening a produced file. Use this plugin only when the authenticated remote browser is meant to operate the agent machine. DSH's Host/Origin fence and browser authentication remain in force; this signal changes the client's capability projection, not request authentication.

Older harness builds that pin privileged methods to loopback on the server will continue returning 403 for those methods. This client bootstrap does not weaken that server-side fence.

Verify

curl http://127.0.0.1:3080/ | grep lan-access-polyfill   # must match

Then open http://<server-ip>:3080 from another device — sessions and models must load.

Security warning

Binding 0.0.0.0 exposes the DSH authentication surface to every reachable interface. trustedHosts is an Origin/Host fence, not identity; current DSH builds separately authenticate the browser. Use only on trusted networks, restrict with a firewall (e.g. ufw allow from 192.168.0.0/16), or expose through Tailscale or an authenticated reverse proxy. A TLS reverse proxy removes the need for the UUID polyfill but not the remote Host-settings bootstrap.

Rollback

  • Bundle install: dsh plugin --profile web remove dsh-web-lan-access
  • Manual install: delete the lan-access insert block from cordis.patch.yml; optionally start without --host 0.0.0.0

License

MIT

安装

🧩 让 Agent 自动装(推荐)

装一次目录插件,之后本站所有插件都能让 DeepSeek Harness 自动找、自动装:

dsh plugin add dshbase-catalog

然后对 agent 说「帮我装 dsh-web-lan-access」,它会在目录里找到并自动安装。文档:dshbase-catalog · 已验证场景包。

该插件是 GitHub 源码(未发 npm)——直接从仓库装:

Web profile:

dsh plugin --profile web add github:AcidGr/dsh-web-lan-access

Headless(CLI)profile:

dsh plugin --profile headless add github:AcidGr/dsh-web-lan-access

实测报告

验证通过:从 GitHub 源码完成 L1 安装 + L2 加载 + L3 运行(dsh 0.1.0-rc.6)。

使用场景

给 agent 网络能力——请求、API、代理或协议——让它能触达外部系统。

适合谁

任务涉及网络的人——调 API、抓资源或与远端服务通信。

二次开发建议

适配器和请求整形是缝——加协议、鉴权处理器、重试和端点抽象。

安全:尚未扫描——我们的每日静态扫描将很快覆盖它。

分享徽章

Network 里更多

浏览全部 7797 个插件 →