[nakaterm]

Summary

v2 設計の M1 のうち「Express 形式 Cookie の削除・依存更新」(1/3)。ユースケース層とテスト基盤は別 PR。

 browserIdMiddleware
-  getSignedCookie(COOKIE_SECRET)            -> 有効なら再発行
-  Cookie が無い                              -> 新規発行
-  unsignExpressCookie(COOKIE_SECRET)        -> 有効なら新形式で再発行
-  それ以外                                   -> 400
+  for secret in [COOKIE_SECRET, ...COOKIE_SECRET_PREVIOUS]
+    getSignedCookie(secret)                 -> 有効なら採用
+  Cookie が無い                              -> 新規発行
+  どの鍵でも検証できない                       -> 400 (従来どおり。警告ログを追加)
+  常に COOKIE_SECRET で署名し直して再発行

• c236557 Express 形式の検証と node:crypto の import を削除
• f7f3717 依存を semver 範囲内で更新 (package-lock.json のみ)
• af34310 署名鍵のローテーション対応 (COOKIE_SECRET_PREVIOUS、カンマ区切り)
• 206b40f server/.env.sample に PORT と COOKIE_SECRET_PREVIOUS を追加し、各変数に説明を付ける

Evidence

テストはまだ無い (PR 2 でテスト基盤を入れた後に追加する)。ローカルでサーバーを起動して curl で確認した。

鍵のローテーション:

鍵 old で発行した Cookie: 753d65da-...
COOKIE_SECRET=new COOKIE_SECRET_PREVIOUS=old  -> 200、同じ 753d65da-... を new で署名し直して発行
COOKIE_SECRET=new (PREVIOUS 未設定)           -> 400 + 警告ログ「browserId Cookie の署名を検証できませんでした」

npm run check と cd server && npm run build は通る。

Merge Danger

Door: two-way (コードは戻せる)

署名が不正な Cookie の扱いは変わらない (400)。変わるのは Express 形式の Cookie が 400 になる点だけ。Hono 移行から約 10 ヶ月経ち、残っている利用者はほぼいない想定。

Blast Radius: browserId

• 本番の COOKIE_SECRET は変えないので、既存の有効な Cookie には影響しない。環境変数の追加は不要 (COOKIE_SECRET_PREVIOUS は省略可)。
• 鍵の差し替え時に COOKIE_SECRET_PREVIOUS を入れ忘れると、既存の Cookie を持つ全員が 400 になる。手順は .local/docs/v2設計.md §3.1。

🤖 Generated with Claude Code