Supported authentication contract for embedding dsh web in a Tauri/WebView shell

[Jstn-1g]

Summary

dsh-v0.1.2-alpha.1 correctly adds browser-session authentication around the Web control surface. The launch token is exchanged for an authority-bound, signed HttpOnly; SameSite=Strict cookie, and unauthenticated API and upgrade requests receive 401.

That contract works for an ordinary top-level or same-origin browser. It does not currently provide a supported path for a native shell whose application UI embeds the official DSH Web UI in a cross-site iframe/WebView. Browsers withhold the Strict cookie in that embedded context, so the iframe cannot authenticate its HTTP or WebSocket traffic.

I am asking for a documented, fail-closed embedded-authentication contract. I am explicitly not requesting removal or weakening of browser authentication.

Versions and integration

• DSH: dsh-v0.1.2-alpha.1
• Exact DSH commit: cd5ef8148158c3a752a658978873241fdf8e2bbc
• Relevant implementation: packages/client/connection/src/browser-auth.ts
• Desktop release reference: v0.9.5-beta.1 at f443ea977d919b65003ebf2e43fd95a64df87b81
• Current Desktop main: 2e378226bb267c5b5fb5ae16ce153b93ccba55c6
• Current Desktop compatibility bypass: c8077b09a78a91ea56a300808290c7577b738d0e
• Unpublished native token/cookie prototype: branch fix/dsh-browser-auth, base 2aec8bc544c56eab1a262946ffa2af94bb36a844

The Desktop shell origin and the loopback DSH origin are different sites. The official UI is currently hosted in an iframe pointing at http://127.0.0.1:<port>.

Minimal browser reproduction

This two-origin test isolates browser cookie behavior without depending on Tauri code:

1. Serve a top-level page from origin A, such as http://127.0.0.2:<port-a>.
2. Have that page embed origin B, http://127.0.0.1:<port-b>, in an iframe.
3. On B, exchange a one-time query token by returning:
   • 303 Location: /
   • Set-Cookie: dsh-auth-test=value; Path=/; HttpOnly; SameSite=Strict
4. From the redirected B iframe, request /api/probe with credentials enabled.
5. Compare that request with a top-level navigation to B.

Observed in headless Microsoft Edge:

{
  "crossSiteIframeApiCookie": "NONE",
  "topLevelApiCookie": "dsh-auth-test=value",
  "observedApiCookies": [null, "dsh-auth-test=value"]
}

No real launch token, DSH cookie, credential, Workspace data, or Session data was logged.

Expected behavior

A documented native-shell flow should allow the official Web UI to authenticate both HTTP and WebSocket/upgrade routes while preserving:

• launch-secret confidentiality;
• authority and process-instance binding;
• Host, Origin, and Sec-Fetch-Site checks;
• one-time or otherwise bounded bootstrap credentials;
• expiry, rotation, and fail-closed behavior;
• no credential access from plugin JavaScript;
• no token persistence in logs, frontend state, URLs after exchange, or profile files.

Actual behavior

The alpha token exchange succeeds for top-level navigation and for a native HTTP cookie jar. The resulting Strict cookie is absent from requests made by the cross-site iframe. Consequently, the official API and upgrade paths reject the embedded UI with 401.

A native-side exchange alone does not solve this: the native HTTP cookie jar and WebView cookie store are separate, and browser SameSite policy still governs embedded requests.

Current workaround and why it is not a contract

Desktop commit c8077b0 patches the compiled alpha connection package so requestRejection() keeps the Host/Origin trust fence but skips browserAuth.isAuthenticated().

This restores the iframe functionally, but it deliberately removes the new browser-session boundary. It is also tied to private compiled-code anchors. We consider it a temporary compatibility bypass, not a suitable upstream contract.

We do not propose:

• treating Host/Origin checks as authentication;
• removing isAuthenticated();
• globally changing the cookie to SameSite=None;
• exposing the launch token to iframe or plugin JavaScript;
• persisting or repeatedly reusing the launch token;
• silently falling back to unauthenticated operation.

Requested guidance

Which embedding model does DSH intend native shells to support?

Possible contract shapes could include:

1. documented top-level WebView navigation and a supported native-shell handoff, avoiding cross-site framing;
2. a narrowly scoped native bootstrap/capability exchange covering HTTP and upgrade routes without exposing the secret to Web code; or
3. a documented same-origin carrier intended specifically for trusted packaged shells.

The precise mechanism should remain an upstream security decision. The essential requirement is that the shell can prove ownership of the launched DSH instance without weakening authentication for ordinary loopback callers.

A related security discussion proposes denying framing for clickjacking protection: #4514. If frame denial is adopted, a documented native-shell/top-level contract becomes necessary independently of the cookie issue.

Can maintainers confirm the intended supported path, or whether packaged shells should stop embedding the official UI in an iframe?

[liyangbing]

The security boundary in this report is worth keeping explicit: a native shell, the embedded Web UI, the loopback Host, and the provider are separate identities. Host/Origin checks can establish request routing or browser context, but they are not a substitute for an authenticated principal.

For a reproducible integration review, record the exact alpha.1 source commit, shell origin, loopback origin, iframe/top-level navigation mode, cookie attributes, HTTP result, and WebSocket/upgrade result separately. A compatibility bypass that skips browserAuth may restore rendering while removing the very boundary being tested; it should not be presented as a supported authentication contract.

The handbook identity guide uses the same fail-closed checklist: verify the embedded binary and exact @deepseek-ai/dsh revision, identify who owns credentials, keep file:// or WebView IPC separate from the official Web surface, and do not put launch secrets in URLs, frontend state, logs, or plugin JavaScript: https://sandbaseai.github.io/deepseek-harness-handbook/official-deepseek-harness.html

That page is an independent community guide, not an official Desktop/WebView compatibility claim. The maintainer decision should define one supported shell topology and its HTTP plus upgrade authentication behavior; until then, top-level same-origin behavior and native cookie-jar behavior should not be generalized to cross-site iframe support.