[Web] Stale dsh-auth-* cookies: server-side self-healing (retire other authorities cookies at mint time)

[isheng-eqi]

TL;DR

Every report I can find about this (#9924, #10716, #11391, #11410, #12166, #12360, #12400, #11220) describes the desktop host, and master already fixed it there in 93bef27 — fix(desktop): remove legacy Host auth cookies from the default session. That commit touches only apps/desktop/*: it clears the Electron cookie jar.

The web build (dsh web) has no equivalent, and packages/client/connection still never retires a cookie minted for a different authority. So the web side still accumulates whenever the authority changes (different port, --port 0, several profiles).

This post proposes the missing half: let the server retire stale cookies itself, at mint time. The server is the only party that can name them, because the request's Cookie: header lists every one.

Why server-side retirement rather than the existing suggestions

Existing suggestion	Why it is not a root fix
Stop hashing the port into the cookie name (#10716)	authenticate() compares payload.authority !== authority and rejects on mismatch, so the name is not the only port binding — relaxing it changes the security boundary
Pin the loopback port (#11410)	Requires control over launch args; apps/desktop-host hardcodes --port 0
Raise maxHeaderSize (#12166)	Moves the threshold; the garbage keeps growing
Session cookie instead of 30 days (#11391)	Helps, but does not remove rows already persisted
Clear the cookie DB (#12400 and others)	Needs the browser/app fully closed (SQLite holds an exclusive lock) and recurs

Server-side retirement needs no configuration, no naming change, no user action, and no new security assumption. It works for the web build and for any host that talks HTTP to connection.

The change (two files, both required)

1. packages/client/connection/src/browser-auth.ts — emit expiry instructions for every dsh-auth-* cookie that is not the current authority's:

function staleSessionCookies(headers: ConnectionTrustRequest['headers'], current: string): string[] {
  const raw = header(headers, 'cookie')
  if (raw === undefined) return []
  const expiries: string[] = []
  const seen = new Set<string>()
  for (const segment of raw.split(';')) {
    const at = segment.indexOf('=')
    if (at === -1) continue
    const name = segment.slice(0, at).trim()
    if (name === current || !name.startsWith(COOKIE_PREFIX) || seen.has(name)) continue
    seen.add(name)
    expiries.push(`${name}=; Max-Age=0; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; SameSite=Strict`)
  }
  return expiries
}

and append them to set-cookie in the mint branch of authorizeIndex(), plus the already-authenticated 303 and the /connect 302.

2. packages/host/frontend-static/src/index.ts — the writeHead adapter must not stringify the array:

-      writeHead(nextStatus, nextHeaders) {
-        status = nextStatus
-        headers = new Headers(nextHeaders)
-      },
+      writeHead(nextStatus, nextHeaders) {
+        status = nextStatus
+        for (const [name, raw] of Object.entries(nextHeaders ?? {})) {
+          const values: readonly unknown[] = Array.isArray(raw) ? raw : [raw]
+          for (const item of values) headers.append(name, String(item))
+        }
+      },

The trap worth flagging

With only change 1 the response looks correct but does nothing: the Cookie header is ~531 B in a single Set-Cookie line carrying every attribute of all four cookies. Cause: new Headers(nextHeaders) runs String() over the array value, and Set-Cookie cannot be comma-joined (its own Expires value contains a comma). packages/host/webserver's nodeHeaders() already does the right thing — it uses headers.getSetCookie() — so once the adapter appends per value, the multi-value header survives to the wire.

Diagnostic that separates the two states: read the response with a real HTTP client, not curl piped through a shell. resp.headers.get_all('Set-Cookie') returns 1 entry (broken adapter, ~531 B, contains Max-Age=2592000 and Max-Age=0) versus 4 entries (correct).

Measured on 0.2.2-alpha.2 (commit ce7073d)

Header ceiling, constructed with real-shaped cookies (~228 B each), Node default maxHeaderSize 16384:

Cookies	Cookie header	Response
68	15,696 B	401
71	16,389 B	431
74	17,082 B	431

End-to-end on dsh web:

step1  GET /?token=<t>   Cookie: dsh-auth-OLD1=a; dsh-auth-OLD2=b; dsh-auth-OLD3=c
       → 303, Set-Cookie × 4  (1 fresh + 3 with Max-Age=0)
step2  GET /             Cookie: <fresh cookie from step1>
       → 200, 517,008 B index
control GET /?token=<t>  Cookie: unrelated=1
       → 303, Set-Cookie × 1  (no expiry instructions)

Browser-level (Playwright + Chromium, the affected profile): seed 72 dsh-auth-LEGACY* cookies for 127.0.0.1:3080, then open the printed token URL → after load only 1 dsh-auth- remains, the UI renders normally, console shows 0 errors.

Bootstrap caveat: once the browser already carries more than 16 KB, even the cleaning response cannot be delivered — the request is rejected before the application. Start once with node --max-http-header-size=65536 apps/cli/lib/bin.js web; the first token exchange then cleans the store, and default arguments are enough afterwards.

Scope note for the web build

With the fixed default port (3080) the authority is constant, the cookie name is stable, and one row overwrites the previous one — that is why a plain dsh web user normally never hits this. It accumulates as soon as the port changes: --port 0, port-collision fallback, or several profiles listening on different ports. I used a fixed web port in the measurements above because it shows the ceiling and the fix without needing the desktop shell.

中文摘要

截至 0.2.2-alpha.2，dsh-auth-* cookie 按 sha256(host:port) 命名、Max-Age 30 天、从不清理；HTTP cookie 只按 host 隔离不按端口隔离，于是同一 127.0.0.1 上历史累积的每一枚都会进入之后每个请求的 Cookie: 头，超过 Node 默认 maxHeaderSize（16384 B）后服务端回 431。master 的 93bef27 只在 apps/desktop 清理 Electron cookie 库，web 侧没有对应实现。

这里补的是服务端自愈：mint 新 cookie 时，读取请求的 Cookie: 头，对所有不属于当前 authority 的 dsh-auth-* 回 Max-Age=0。服务端是唯一能点出这些名字的一方。两处改动缺一不可——frontend-static 的 writeHead 适配层用的是 new Headers(nextHeaders)，会先把数组 String() 成一条畸形头（Set-Cookie 不能用逗号合并），必须逐条 append。

实测：68 枚 → 401、71 枚 → 431；打完补丁后，带 3 枚旧 cookie 的 token 请求回 4 条 Set-Cookie（1 新 + 3 过期），控制组只回 1 条；浏览器里预置 72 枚旧 cookie 后打开 token URL，加载完成只剩 1 枚、界面正常、console 零错误。首次应用需要一次 --max-http-header-size=65536 启动（否则清理指令本身也发不出去）。

如果维护者认为服务端退 cookie 的方式可以接受，我可以把它整理成符合仓库规范的补丁；如果不接受，也建议至少在 web 侧补上 93bef27 的等价清理。