Arcrun

Leo/Arcrun

Fork 0

Commit Graph

Author	SHA1	Message	Date
Claude	417d69ceb3	fix(portal): 傳播空窗期不再銷毀 session——讀不到 ≠ 這個人不存在（arcrun-rag#66） leo 2026-08-10 在 youlin stage 改完密碼被登出，之後怎麼登都回不去。病灶是「這一瞬間讀不到」被當成「這個人不存在」，而且做的是不可逆的動作。認證的家是 CF Workers Secret，改它會產生 worker 新版本，既有 isolate 讀到的還是舊 env（#55 實測 ≥15 秒）。舊的 requirePortalUser 在那個空窗裡直接把 session 從 KV 刪掉——不是擋下讓你重試，是當場銷毀，等 secret 鋪開也回不來。 #55 補的「讀不到就再問一次加速器」只加在登入路徑（findAndVerifyUser），這道門沒有。三處修法（缺一不可）： 1. requirePortalUser 先問一次加速器再判定（與登入路徑同一招、同一支函式） 2. 永不因「讀不到」刪 session；仍讀不到且正在傳播空窗 → 回 503 `auth_store_propagating` 而不是 401（讀得到 record 的「已停用」照舊刪，那是確定的事實） 3. 前端 boot() 從「任何非 2xx 都 dropSession」收斂成只有 401 才算被登出 ——後端不刪、前端卻自己丟掉 localStorage 的 token，症狀一模一樣順帶修掉同一族的一個資料遺失路徑：mutateAuthStore 舊版拿「可能是舊版 env」當底稿做 read-modify-write，而 writeAuthStore 會重切分片並刪掉多出來的舊分片 ⇒ 底稿若是「某帳號被建立之前」的版本，那個帳號會在這次寫入中被抹掉且無法還原（secret 是唯一真相源）。改成先問加速器、再把 env 版與 overlay 版取聯集當底稿；刪除仍有效（fn() 在聯集之後才跑）。驗證：tsc 與 baseline 同為 23 個既有錯誤（零新增）；tests/portal-auth.test.ts 27/27 綠。 stage 實測見交付回報。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss	2026-08-10 13:22:34 +00:00
uncle6me-web	c4cee35adb	feat(auth): 認證與資料分離——搬動知識資料時登入不再跟著壞掉（D61 / arcrun-rag#55） leo 2026-08-10 下令：「登入認證資料要分離⋯⋯就算只有我一個人存在單獨的 json 檔也好，它不能被改資料庫的連結導致無法登入。」「昨天不能登入 portal，今天不能登入 mcp，這根本就是一個問題。」病：portal 帳號住 KBDB（owner_id = {CONSOLE_TENANT}::portal），console 管理員帳密住 SESSIONS_KV。兩者都靠 binding 指過去，重裝/遷移一定會被重新指一次 ⇒ 保險箱的鑰匙放在保險箱裡。2026-08-09 leo 資料一個位元組都沒動，卻被鎖在門外。修：認證搬到 CF Workers per-script Secrets（掛在 script 上，與 bindings 兩套資源，重部不會洗掉；journeys/gemini-key-lost-on-reinstall.md 與 installer worker.js:1148 皆有實證）。 - 新增 lib/portal-auth-store.ts：自足的 JSON，讀取零網路呼叫，>4.6KB 自動溢位分片 - portal.ts 的帳號讀寫全部改走它；KBDB 只留為舊實例的回退讀路徑，登入成功順手搬過去 - console-auth.ts 的第二份認證資料同樣搬離 KV - 不牴觸 D38：KBDB 三張核心表不增不減，本案是把東西搬出去 - 沿用 credentials.ts 既有的 putWorkerSecret/deleteWorkerSecret，不另造第二套寫入路徑（D36）明顯失敗（把 #10「寧可明顯失敗，不要靜默錯置」套到門鎖上）： - 「這台實例讀不到任何登入資料」回 503 + code=auth_store_empty，且不計入 5 次鎖定（08-09 leo 就是被系統自己的誤判鎖了 15 分鐘） - /console/setup 遇既有帳號改說「你剛才輸入的密碼沒有被採用」，不再只說「已設定過」 - /health 與 /console/auth-status 吐 auth_store 狀態（住哪、寫不寫得進去） stage 實測撞到並修掉的坑：改 secret 會產生 worker 新版本，既有 isolate 讀到的還是舊 env ⇒ 「建好帳號立刻登入」有 15 秒以上 401，還被算進鎖定。加一層短 TTL 的 KV 加速器（非真相源，只在 secret 查不到/密碼對不上時問一次），換 KV 不影響不變量。驗收：stage（youlin）把知識資料庫換成另一顆空的 + 換租戶代號 + SESSIONS_KV 換成空的，三樣一起換之後 portal / MCP /authorize / console 三條登入路徑仍全綠（複跑 3 次）。對照組（舊版程式碼同樣換庫）：登入回「email 或密碼錯誤」，5 次後鎖 15 分鐘。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-10 14:13:37 +08:00

Author

SHA1

Message

Date

Claude

417d69ceb3

fix(portal): 傳播空窗期不再銷毀 session——讀不到 ≠ 這個人不存在（arcrun-rag#66）

leo 2026-08-10 在 youlin stage 改完密碼被登出，之後怎麼登都回不去。
病灶是「這一瞬間讀不到」被當成「這個人不存在」，而且做的是**不可逆**的動作。

認證的家是 CF Workers Secret，改它會產生 worker 新版本，既有 isolate 讀到的
還是舊 env（#55 實測 ≥15 秒）。舊的 requirePortalUser 在那個空窗裡直接把
session 從 KV 刪掉——不是擋下讓你重試，是當場銷毀，等 secret 鋪開也回不來。
#55 補的「讀不到就再問一次加速器」只加在登入路徑（findAndVerifyUser），這道門沒有。

三處修法（缺一不可）：

1. requirePortalUser 先問一次加速器再判定（與登入路徑同一招、同一支函式）
2. **永不因「讀不到」刪 session**；仍讀不到且正在傳播空窗 → 回 503
   `auth_store_propagating` 而不是 401（讀得到 record 的「已停用」照舊刪，那是確定的事實）
3. 前端 boot() 從「任何非 2xx 都 dropSession」收斂成**只有 401 才算被登出**
   ——後端不刪、前端卻自己丟掉 localStorage 的 token，症狀一模一樣

順帶修掉同一族的一個資料遺失路徑：mutateAuthStore 舊版拿「可能是舊版 env」當底稿做
read-modify-write，而 writeAuthStore 會重切分片並刪掉多出來的舊分片 ⇒ 底稿若是
「某帳號被建立之前」的版本，那個帳號會在這次寫入中被抹掉且無法還原（secret 是唯一真相源）。
改成先問加速器、再把 env 版與 overlay 版取聯集當底稿；刪除仍有效（fn() 在聯集之後才跑）。

驗證：tsc 與 baseline 同為 23 個既有錯誤（零新增）；tests/portal-auth.test.ts 27/27 綠。
stage 實測見交付回報。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss

2026-08-10 13:22:34 +00:00

uncle6me-web

c4cee35adb

feat(auth): 認證與資料分離——搬動知識資料時登入不再跟著壞掉（D61 / arcrun-rag#55）

leo 2026-08-10 下令：「登入認證資料要分離⋯⋯就算只有我一個人存在單獨的 json 檔也好，
它不能被改資料庫的連結導致無法登入。」「昨天不能登入 portal，今天不能登入 mcp，
這根本就是一個問題。」

病：portal 帳號住 KBDB（owner_id = {CONSOLE_TENANT}::portal），console 管理員帳密住
SESSIONS_KV。兩者都靠 binding 指過去，重裝/遷移一定會被重新指一次 ⇒ 保險箱的鑰匙
放在保險箱裡。2026-08-09 leo 資料一個位元組都沒動，卻被鎖在門外。

修：認證搬到 CF Workers per-script Secrets（掛在 script 上，與 bindings 兩套資源，
重部不會洗掉；journeys/gemini-key-lost-on-reinstall.md 與 installer worker.js:1148 皆有實證）。
- 新增 lib/portal-auth-store.ts：自足的 JSON，讀取零網路呼叫，>4.6KB 自動溢位分片
- portal.ts 的帳號讀寫全部改走它；KBDB 只留為舊實例的回退讀路徑，登入成功順手搬過去
- console-auth.ts 的第二份認證資料同樣搬離 KV
- 不牴觸 D38：KBDB 三張核心表不增不減，本案是把東西搬出去
- 沿用 credentials.ts 既有的 putWorkerSecret/deleteWorkerSecret，不另造第二套寫入路徑（D36）

明顯失敗（把 #10「寧可明顯失敗，不要靜默錯置」套到門鎖上）：
- 「這台實例讀不到任何登入資料」回 503 + code=auth_store_empty，且**不計入 5 次鎖定**
  （08-09 leo 就是被系統自己的誤判鎖了 15 分鐘）
- /console/setup 遇既有帳號改說「你剛才輸入的密碼沒有被採用」，不再只說「已設定過」
- /health 與 /console/auth-status 吐 auth_store 狀態（住哪、寫不寫得進去）

stage 實測撞到並修掉的坑：改 secret 會產生 worker 新版本，既有 isolate 讀到的還是舊 env
⇒ 「建好帳號立刻登入」有 15 秒以上 401，還被算進鎖定。加一層短 TTL 的 KV 加速器
（非真相源，只在 secret 查不到/密碼對不上時問一次），換 KV 不影響不變量。

驗收：stage（youlin）把知識資料庫換成另一顆空的 + 換租戶代號 + SESSIONS_KV 換成空的，
三樣一起換之後 portal / MCP /authorize / console 三條登入路徑仍全綠（複跑 3 次）。
對照組（舊版程式碼同樣換庫）：登入回「email 或密碼錯誤」，5 次後鎖 15 分鐘。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 14:13:37 +08:00

2 Commits