UI appearance / settings changes made over a non-loopback (trusted remote) origin do not persist — persistence is hard-gated to loopback only

[panw2046]

Summary

When the DSH web UI is served over any non-loopback origin — a declared --trusted-host (e.g. a MagicDNS *.ts.net domain behind Tailscale Serve), a LAN hostname, or a reverse proxy — changes made in Settings → Appearance (theme light/dark/system, font size) are lost on page refresh. They do not persist to the Host settings document.

This is caused by a loopback-only hard gate in the client settings persistence path (ui-settings), which is inconsistent with the /api trust fence that already honors declared --trusted-host authorities.

Environment

• Version: dsh-v0.1.2-alpha.4
• Deployment: single container, dsh web --port 3081 --no-open --trusted-host <host>.taile<xxxx>.ts.net
• Access: browser via https://<host>.taile<xxxx>.ts.net (Tailscale Serve, tailnet-only, Let's Encrypt). /api requests work correctly (the --trusted-host fence lets them through).
• The same page opened as http://127.0.0.1:3081 does persist correctly.

Steps to reproduce

1. Open the web UI over a non-loopback origin (https://<host>.ts.net/ or any LAN hostname).
2. Go to Settings → Appearance and choose Dark (or change the font size).
3. The theme switches to Dark immediately.
4. Refresh the page → reverts to the default (light / system).

Expected behavior

A host the operator has explicitly trusted via --trusted-host (and that passes browser-session authentication) should be able to persist UI/appearance settings, consistent with the fact that the same authority is already trusted for /api access. At minimum this behavior should be clearly documented, because today it silently looks like a bug.

Root cause

Persistence mode is chosen per page origin and is 'host' only on loopback:

• packages/client/ui-settings/src/client/index.ts (~line 58):

  const persistence = ctx.remote.$host.isLoopback ? 'host' : 'memory'

• isLoopback is computed client-side purely from the page hostname:
  • packages/client/connection/src/client/index.ts (~line 228):

    isLoopback: transport?.ownsHost === true || pageLocation === undefined || isLoopbackHostname(pageLocation.hostname)

  • packages/client/connection/src/loopback-hostname.ts — matches only localhost / 127.* / [::1]. A .ts.net MagicDNS name is not loopback.
• The facts exposed to client plugins contain no notion of "trusted remote authority":
  • packages/api/gateway/src/client/index.ts — interface RemoteHostFacts { readonly home: string | undefined; readonly isLoopback: boolean }.
  • The --trusted-host list lives only server-side (packages/client/connection/src/api-request-trust.ts, rpc-host.ts) and is never shipped to the browser, so the client cannot tell whether its current origin is one of the trusted authorities.

Inconsistency worth highlighting

The /api request fence already accepts a declared trusted authority:

• packages/client/connection/src/api-request-trust.ts (~line 103):

  if (!isLoopbackHostname(hostUrl.hostname) && !isTrustedAuthority(hostUrl, trustedHosts)) return false

So the same remote origin that is trusted for /api is not trusted for settings persistence. This asymmetry is the core of the bug report.

Blast radius of isLoopback

ctx.remote.$host.isLoopback is currently reused as a coarse "privileged page" flag by at least three consumers:

Consumer	Purpose	Loopback-only justified?
packages/client/ui-settings/src/client/index.ts:58	Settings persistence (host vs memory)	No — a remote trusted user should be able to persist their UI preferences
packages/client/ui-settings-general/src/client/index.ts:76	Settings-document controller	Debatable — could be scoped per-user
packages/client/ui-deliverables/src/client/ProducedFiles.tsx	"Open file on host machine"	Yes — genuinely loopback/desktop-only

The security rationale for restricting durable writes to the Host settings document is clear. But gating UI appearance persistence (a per-user, low-risk preference) behind the exact same boolean as "open a file on the host OS" is too coarse.

Why this is not a one-line allowlist

--trusted-host is currently server-private. To let the client evaluate "is my origin trusted", the server would have to ship the trusted-host list to the browser, making it a publicly readable fact on any page that can reach the UI. That partially weakens the original "trust only loopback, never reveal the trust list" posture. Any proposal should therefore be designed as a narrow, session-scoped persistence grant, not a blanket relaxation of isLoopback.

Proposed directions for discussion

1. Decouple persistence from isLoopback. Introduce a narrower, server-issued capability (e.g. tied to the existing 30-day browser-session cookie / JWT grant rather than to the page hostname), so a browser that has already authenticated against a --trusted-host authority may persist its own UI preferences — while higher-risk surfaces ("open file on host") remain loopback-only.

2. Scoped settings document. Persist remote UI preferences into a per-session / per-cookie settings namespace instead of the shared Host settings document, so a remote trusted user personalizes their own view without mutating the operator's global configuration.

3. At minimum, document the limitation. If loopback-only persistence is intentional, surface it in the UI ("Changes won't persist on this host") and in dsh web --help, because today it behaves like a silent data-loss bug.

Expected follow-up

• Maintainer guidance on whether remote trusted-origin settings persistence is in-scope.
• If accepted, an agreed scoping model (per-cookie namespace vs. trusted-authority grant) so the fix can be designed safely and landed upstream.

[IkariKr]

I think this is the right place to separate three concepts that are currently close together but should stay distinct: request-authority trust, browser authentication, and client privileges.

I checked current master after the browser-token authentication work landed. trustedHosts in dsh-client-connection is now correctly a Host/Origin confused-deputy fence, while BrowserAuth uniformly authenticates Host API methods and WebSocket streams with the launch-token -> signed-cookie session. I would preserve both of those semantics.

The missing primitive seems narrower than "make trusted hosts privileged": a server-issued authenticated-client grant, with an optional authenticated reverse-proxy bootstrap path.

A possible direction:

1. Keep isTrustedApiRequest() mandatory. Host, Origin, Sec-Fetch-Site, and trustedHosts remain routing/request-trust evidence, never identity.
2. Keep the DSH browser session as the authority used by /api and Remote streams.
3. Allow an optional browser-auth bootstrap provider to establish that DSH session after an external gateway has authenticated the user. A generic authenticated-proxy provider could validate one gateway-held assertion/credential, then mint the same ordinary DSH signed browser cookie. After bootstrap, API dispatch should not have a second proxy-specific authorization path.
4. Project only coarse server-issued client grants/capabilities to the browser, for example a grant that permits durable UI preference persistence. Do not ship the trustedHosts allowlist to the browser and do not infer privilege from page hostname.
5. Keep genuinely local capabilities, such as opening a file on the host OS, separately loopback-only.

Security properties I would keep explicit:

• Host / --trusted-host never authenticates a caller.
• X-Forwarded-For, peer IP, or other routing metadata never authenticate a caller.
• The gateway must strip any client-supplied assertion and inject its own value only after gateway authentication.
• The DSH backend should remain on loopback/private transport for this mode.
• A proxy bootstrap should end in the existing DSH session credential rather than bypassing it on every request.
• No provider-specific Cloudflare/Tailscale/etc. logic is needed in core; the primitive should be generic.

This also gives #5430 a safer fix than broadening isLoopback: an authenticated remote browser could receive a narrow persistence grant while host-OS actions remain local-only.

We have downstream evidence for this deployment shape in DSH Orbit (v0.3.0-rc.1): an authenticated gateway in front of DSH, with exact public authority, HTTPS forwarding, same-origin/non-cross-site checks, and a gateway-held internal assertion. That downstream compatibility code is intentionally treated as temporary debt and is meant to disappear once DSH has a generic primitive. This is not a request to upstream Orbit-specific headers or its Hub/Node protocol.

Reference: https://github.com/IkariKr/dsh-orbit/tree/v0.3.0-rc.1

If maintainers agree with the direction, I would be happy to help reduce this to the smallest service/interface change once external PRs are accepted again.