[Feature] Allow privileged settings/credentials APIs on trusted-host LAN deployments

[nevergow]

Problem

settings.describe / settings.update / credentials.* / agentPreset.* / llm.discoverModels are pinned to loopback-only via PRIVILEGED_METHODS (checked with an empty trust list), even when --trusted-host is configured. On a LAN deployment (dsh bound to 127.0.0.1 behind a reverse proxy with HTTPS), the Settings / Models / Credentials / Agent-preset / Plugin pages all fail with transport failure for /api/settings.describe: HTTP 403 from any non-loopback client.

Verified in source: packages/client/connection/src/index.ts PRIVILEGED_METHODS + createSharedFetchHandler/register use isTrustedApiRequest(request, []) for these methods, so --trusted-host never applies to them. The comment says the configuration plane stays loopback-same-origin until a real authentication layer.

Ask

Would be great to have an explicit opt-in (env/config flag) that lets a trusted-host deployment also allow these privileged methods, e.g. --allow-remote-settings or a config key, so LAN users can manage settings without SSH-ing into the host. An explicit opt-in keeps the default safe.

[roojay]

遇到了同样问题，想把这个部署到公网环境下使用，外层已经有安全身份处理的情况下，内部这一堆写死的东西没法处理很难受。

[nevergow]

Same pain here on a LAN deployment (dsh behind nginx with HTTPS, --trusted-host set). All the settings / models / credentials / plugin management pages fail with 403 on settings.describe from any non-loopback client, so remote management requires SSH-ing into the host every time.

Current workaround: manage configuration from the host itself via http://127.0.0.1:3080 (loopback passes the privileged-methods fence). Works, but it is painful for LAN users and basically unusable for public deployments like @roojay described.

What would help most:

1. An explicit opt-in flag (e.g. --allow-remote-settings or a config key) that lets a trusted-host deployment pass the privileged methods through the same trustedHosts fence — default stays loopback-only, so nothing weakens for existing deployments.
2. Or a proper auth layer (token/basic auth) that replaces the loopback pin for remote management.

Thanks for looking into this!

[JUANWANG-BUAA]

我做了个远程控制的方案https://github.com/JUANWANG-BUAA/dsh-full-remote ，实测是可以解决局域网与内网穿透的控制问题，并且目前没发现大的问题

[0gl20shk0sbt36]

@nevergow @roojay — I hit the exact same wall (LAN deployment, privileged methods 403 from any non-loopback client) and ended up building a generic solution that does not touch dsh source at all.

Approach: an mTLS gateway instead of an allow-flag

Instead of asking for --allow-remote-settings (which would weaken the loopback pin), I put a small standalone gateway in front of dsh that provides the real authentication layer the code comment asks for:

• Client certs (mTLS) issued from my own CA — every device gets its own cert
• The gateway terminates TLS, verifies the client cert (CA + serial + expiry + optional IP binding), then reverse-proxies to dsh on 127.0.0.1
• It rewrites Host/Origin headers to the loopback target, so the dsh trust fence sees loopback and privileged methods (settings.describe / credentials.* / agentPreset.* / llm.discoverModels) pass naturally — no source patch, no --trusted-host needed
• Cert identity maps to a permission list in SQLite (serial → purposes[]), so admin certs only reach the management plane and device certs only reach their allowed backends (one port per purpose)

Default stays safe: no registered cert = no access. The auth layer is stronger than a token — private key, per-device revocation, expiry built into the cert.

Repo: https://github.com/0gl20shk0sbt36/mtls-gateway

It is generic: fronts dsh today, any other self-hosted app tomorrow (vaultwarden, etc.). Works for LAN and for public deployments behind a tunnel, since the outer security is the cert itself.