dsh-remote-gateway

DSH keeps its privileged browser APIs on loopback by design, which means a stock reverse proxy can serve the page to a remote browser but leaves settings, plugin bundles, WebSockets, and host-directory selection all broken. dsh-remote-gateway inserts itself between your authenticated reverse proxy and the internal DSH server as a narrow compatibility gateway: it forwards HTTP, SSE, and WebSocket traffic, rewrites Host and Origin to the loopback authority, and strips every edge-authentication and forwarded-client-identity header before the request touches DSH. Unrelated plugin assets pass through byte-for-byte; only the exact dsh-client-connection probe is patched, and the native OS file dialog is swapped for DSH's in-app filesystem browser so remote users can still pick a workspace.

Because the gateway rides the DSH plugin lifecycle, your existing systemd, launchd, or other supervisor already starts, stops, and watches it alongside DSH. Configuration is deliberately small: a listen address, a listen port (default 3080), and an exact-IP allowlist. A /_dsh-remote-gateway/health endpoint lets monitoring check the gateway process and source policy without touching the DSH upstream, and the connection-patch is fail-closed—if a DSH update changes the expected probe, the module returns 502 with an explicit log line rather than quietly loading a half-broken remote UI.

This plugin is aimed at operators who already run DSH behind a process supervisor and need a small, trusted team to reach it over a TLS-terminating, authenticated reverse proxy. The source-IP allowlist is defence-in-depth on top of the proxy's own ACL, not a replacement for it. Review every third-party DSH plugin before installation, since plugins execute with the DSH process permissions and the gateway does not sandbox them.