dsh-loopback-bridge

DSH's settings page includes a hard-coded client-side gate: if the hostname is not 127.0.0.1 or localhost, the entire page locks into read-only mode and all writes to model config and API keys are blocked. Meanwhile the server-side RPC channel has been open since 0.1.2 via the --trusted-host flag, so the bottleneck is purely in the browser. Users running DSH on a home NAS or Raspberry Pi who want to tweak settings over a LAN IP or a domain have been forced into ugly workarounds, like rewriting the nginx reverse-proxy Host (which trips 0.1.2's Host-bound cookies into a 401) or simply giving up on remote management.

dsh-loopback-bridge takes a deliberately minimal approach: it is purely client-side and simply marks the current connection as local at page load, so the settings page availability check passes naturally. It does not modify the official DSH package, does not require any reverse-proxy changes, and takes effect immediately after a web process restart. If a future DSH release natively supports trusted-host in the browser, you uninstall the plugin and are done, with zero migration cost.

This plugin is well suited for anyone running DSH on a home NAS, Raspberry Pi, or VPS and wanting to manage its settings over a LAN IP or a public domain. One important caveat: the plugin equates the ability to change settings with the ability to open the DSH page. Inside a trusted LAN this is perfectly fine, but on the public internet you must place an authentication layer such as authentik or oauth2-proxy in front, otherwise anyone who can reach the page has full credential write access. The plugin performs no server-side authentication by design; that gatekeeping responsibility sits squarely with the operator.