Browser session cookie: SameSite=Strict causes a redirect loop on iOS when the page is opened from another app

[Amro-Afifi]

Version: @deepseek-ai/dsh 0.1.5-rc.1

What happens

dsh-client-connection issues the browser session cookie with SameSite=Strict (sessionCookie() in packages/client/connection/src/browser-auth.ts). On iPhone (iOS 26, Edge for iOS / WebKit), when the Web UI is opened from outside the browser (a link in another app, a home-screen shortcut, or a tab resumed after a while), WebKit treats the first navigation as cross-site (Sec-Fetch-Site: cross-site). It then withholds Strict cookies for the whole redirect chain that follows:

GET /?token=…  -> 303 /   Set-Cookie: dsh-auth-…; HttpOnly; SameSite=Strict
GET /          -> no dsh-auth cookie sent -> 401 (or, behind a front door, back to /?token=…)

Under a front door that sends cookie-less visitors back through the token exchange, this becomes an endless loop. The browser stops after many hops with ERR_FAILED. Opening the same URL by typing it (Sec-Fetch-Site: none) works. Desktop browsers are not affected.

We know the design note (2026-08-24 browser-token-authentication) scopes support to loopback HTTP and says proxy deployment is not a supported contract. The cookie behaviour itself does not depend on the proxy, though: any cross-site top-level arrival at /?token=… gets a cookie that the immediate 303 / does not carry.

Suggestion

Either of these would fix it:

1. Default to SameSite=Lax. Top-level GET navigations still carry the cookie, and cross-site subresource requests and POSTs still do not. CSRF and DNS-rebinding protection already come from the Host/Origin checks that run before authentication (403), so Strict adds little on top of them.
2. Keep Strict as the default, but add a setting next to cookieMaxAgeDays (for example cookieSameSite: "strict" | "lax").

Current workaround

We rewrite the attribute at the reverse proxy (Caddy):

reverse_proxy 127.0.0.1:<port> {
    header_down Set-Cookie "SameSite=Strict" "SameSite=Lax"
}

This fixed it for us. We would rather not depend on a string rewrite of a header the package owns.

[PerryLink]

SameSite=Strict 我核到了——在当前最新代码上仍是硬编码

1. 你引的位置仍然成立

在 origin/master（= d743267388 = dsh-v0.2.1-alpha.2，2026-10-09）上：

// packages/client/connection/src/browser-auth.ts:129
const attributes = `${name}=${value}; Max-Age=…; Path=/; Expires=…; HttpOnly; SameSite=Strict`

⇒ SameSite=Strict 是写死在会话 cookie 属性串里的，与你的描述一致。

2. 机制（这解释了"为什么只有从别的 App 打开时才成环"）

SameSite=Strict 的含义是：跨站发起的导航不会带上该 cookie。而"从另一个 App 里的链接打开 Web UI"正是一次跨站顶层导航 ⇒ 第一次请求不带会话 cookie ⇒ 服务端把你送去认证/引导 ⇒ 该跳转在 WebKit 眼里依然是跨站 ⇒ 一次又一次 —— 表现就是你看到的重定向环。

对照：在浏览器里直接输入地址或在同站内导航时，导航是 same-site，cookie 照常带上，所以不复现。这条对照建议写进正文，它是"机制确凿"的最短论证。

3. 修法建议（含取舍，便于评审）

1. SameSite=Lax（推荐）：顶层 GET 导航会带上 cookie ⇒ 解决成环；而跨站 POST/子资源仍不带 ⇒ CSRF 的主要面仍被挡住；
2. SameSite=None; Secure：只有在嵌入式/跨站上下文必须带 cookie 时才需要，防护最弱，需配合其它 CSRF 措施；
3. 若坚持 Strict，则必须改流程（例如首次进入走一个不带凭据的"握手页"再同站跳转）——成本明显更高。

建议把诉求写成可验收的一条：

在 iOS 上从外部 App 打开 Web UI 时，应在不出现重定向环的前提下进入界面（或明确给出"请在本浏览器中打开"的提示），并说明该 cookie 的 SameSite 取值与理由。

4. ⚠️ 版本：请在当前发布线上复核

你写的是 0.1.5-rc.1——那是旧的线。当前是：

npm: latest = 0.2.0-rc.2    next = 0.2.0-rc.2    alpha = 0.2.1-alpha.2
最新 tag: dsh-v0.2.1-alpha.2 (2026-10-09)

（注意：latest 早就不再是 0.1.5-rc.3 了——那是几周前的情况。）

我在最新代码上核到 :129 仍是 SameSite=Strict ⇒ 问题很可能仍在，但请你在 0.2.x 上重跑一次并把 dsh --version 写上：

npm i -g @deepseek-ai/dsh@latest    # 0.2.0-rc.2；或 @next 同版本

一条边界

我确认的是该属性在当前最新代码里仍为硬编码 Strict（这足以支撑你的因果链第一环）。iOS 26 上 WebKit 的具体跳转行为以你的实测为准——我没有 iOS 设备。

[alexadamus77-ui]

"Spot on analysis. Hardcoding SameSite=Strict definitely causes top-level navigation issues when opening links from external apps on iOS. Moving to Lax or making it configurable makes complete sense for a smoother auth flow- especially when handling redirects or testing through tools like CroxyProxy."