Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
401 Commits 27 Branches 0 Tags
730c2af245e65bbdb162eb484e6e4ce9c334db55
Commit Graph

4 Commits

Author SHA1 Message Date
uncle6me-web 10d150ac2b fix(mcp): MCP 用登入者的身分查詢，不再去找一把服務內部金鑰 
leo 2026-08-12：「人類進 Portal 輸入帳密表示你是主人，可以查到你權限所有東西；
AI 透過輸入帳密的 MCP 查詢表示是授權的 AI，可以查到主人允許查的任何東西。」
「掛上 MCP 並輸入帳密，那個動作本身就是授權」⇒ 下游不得再要求第二次認證。

病根（不是金鑰沒同步，是身分沒接住）：
  oauth/routes.ts 驗完 Portal 帳密只留下 `loginOk = res.ok` 一個布林值，身分當場丟棄，
  namespace 改從 `MCP_OWNER_NAMESPACE || "leo"` 拿。於是查詢時手上沒有身分可帶，
  只好用 KBDB_INTERNAL_TOKEN 直打 KBDB——那條路繞過 portal 所有庫過濾，
  而且不管誰登入都看到同一格、看到全部。CLI 也從不注入 MCP_OWNER_NAMESPACE，
  所以那個 "leo" 預設值是每台實例的實際行為，不是理論上的邊角。

修法（走既有那條路，不發明新的）：
1. 接住身分：/authorize 解析 /portal/login 回應，把 portal session token ＋
   display_name/role/libraries 存進 authorization code → access token。
   /portal/login 補回 session_expires_in，access_token TTL 夾成
   min(自己的 TTL, portal session TTL)——不讓「MCP 還連著、底下 session 早死」。
   cypher 回 200 但沒給 session_token（舊版）→ 不發碼，不簽一張沒有身分的 token。
2. 攜帶身分：kbdb_* 全部改走 cypher `/portal/data/*`，Authorization 帶登入者的
   session。庫過濾／租戶注入／停用即時生效全在 server 側，與人類走 portal 網頁同一道閘。
   kbdb_graph_neighbors 因此不再需要 kbdb_base（server 自己知道查哪個庫）。
   藏書地圖（含連線時注入 instructions 的那份）同樣只回有權限的庫，快取改 per-session
   分格——地圖本身就是情報，不能讓先連上的人把視野留給下一個。
3. fail-closed：舊 token 沒有身分 → 誠實要求重新連線，不偷偷退回服務金鑰那條老路。
   服務級憑據（static token / partner key）維持既有 KBDB 直連，arcrun_* 零回歸。

新增 cypher portal 資料面端點（能力長在 API，MCP 只暴露；rule 07）：
  GET  /portal/data/map、/portal/data/map/:library
  GET  /portal/data/templates、POST /portal/data/templates
  GET  /portal/data/records/by-template/:t、GET /portal/data/records/:id
  POST /portal/data/records
全部：呼叫端自帶 owner_id 一律不生效；越權與不存在同回 404；寫入 owner_id 由 server 定死。

KBDB base：`GET /records/:id` 與 by-template 補回 owner_id 欄位——原本不回，
呼叫端無從判斷「這筆是不是我的」，按 id 直讀等於沒有租戶邊界。

沒動：KBDB fail-closed 閘、任何金鑰、租戶字串仍不下發給呼叫端。

驗證：
  mcp        tsc 綠；vitest 113/113 綠（改前 48 綠 29 紅）
  cypher     vitest 400 綠 / 14 紅，14 紅與 base commit a24f291 逐條相同（既有）
  kbdb       vitest 208 綠 / 5 紅，5 紅同為既有（migrations/*.sql 被 gitignore）
  端到端     ◐ 未驗：需部署到 leo21c，那道閘要 leo 親手解（見 PR）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 19:33:12 +08:00
Leo b8ca98cb49 MCP 認證改用 Portal 帳密，廢掉 MCP_OWNER_SECRET（leo 指定做法） 
leo：「claude 裡有一個直接輸入帳密連線的，為什麼不用那個？跟他輸入 portal 的帳密一樣不就好了？」

為什麼換（三個封測撞出來的實際問題）：
① 沒人給得了封測者——安裝器產生後從不顯示（完成頁 grep「Owner 祕密」=0），
   CF secret 又唯寫讀不回 ⇒ 用戶卡在同意頁，只能找 leo 手動 wrangler 覆寫
② 多一把要記的金鑰——違反「拿一把金鑰就很難了」
③ 全實例共用一把，無法分辨誰連上來（企業多人版必要）

風險評估（leo 判斷，總管原本誇大成「繞過帳密的旁路」已認錯）：
secret 要貼進 claude.ai（本身有帳密保護）⇒ 洩漏 secret 與洩漏 portal 帳密風險相同。

改動：
- consent.ts：一個「Owner 祕密」欄位 → email ＋ password 兩欄
- routes.ts POST /authorize：constantTimeEqual(MCP_OWNER_SECRET)
  → 走 CYPHER_EXECUTOR binding 打 /portal/login（認證下沉到唯一真相源，
    同樣吃它的節流與停用檢查）
- routes.ts GET /authorize：移除「未設 MCP_OWNER_SECRET → 503」
  （那是「每個封測者都死在這頁」的直接原因）

驗：tsc 零錯誤；已部署 youlin。
 2026-07-31 00:44:15 +08:00
Claude 5fa3b79a4c fix(mcp): validate/normalize RFC 8707 resource at issuance; store canonical aud 
leo review 最後一條：簽發端沒驗證/正規化 resource → 失敗劇本「OAuth 全程成功但每次打 /mcp 401 aud
mismatch」（尾斜線/canonical 變體，錯誤離根因最遠最難 debug）。改在簽發端 fail fast：

- metadata.ts 加 normalizeResource（scheme/host 小寫、去預設 port、path 去尾斜線，與 resourceUri
  canonical 一致）+ resourceMatches。
- /authorize（GET+POST）：帶 resource 且正規化後 != canonical → redirect 帶 error=invalid_target
  （redirect_uri 已驗過才 redirect）；一律把 canonical resource 存進 code（不存 client 原樣值）。
- /token：帶 resource 且正規化後 != canonical → 400 invalid_target；aud 一律存 canonical
  resourceUri(origin) → 與 partner-auth 嚴格比對 at.aud===resourceUri(origin) 恆一致。

裁決：尾斜線/大小寫等「正規化後等價」的 resource → 接受（存 canonical aud，/mcp 必過），非拒絕——
否則 claude.ai 真送變體會永久授權失敗連不上（把 401 問題換位重現）。只有正規化後真正不同的
resource（別 host/path）才 fail-fast 拒。詳見 OAUTH.md §2。

測試：normalizeResource/resourceMatches 單元 + 尾斜線變體→正常發碼且 aud canonical、別 host→
/authorize redirect invalid_target 不發碼、/token 別 host→400 invalid_target。
mcp vitest 52/52、tsc exit 0。

Refs #15

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 05:38:35 +00:00
Claude 7d9d478baa feat(mcp): OAuth 2.1 server for claude.ai remote connector; close plaintext-namespace bearer hole 
在 arcrun-mcp worker 實作 MCP Authorization 規範（OAuth 2.1 + PKCE S256），
讓 claude.ai 遠端 connector 安全登入；並修掉「Bearer 明碼 namespace 直接放行」漏洞。

安全模型
- /authorize 同意頁以 owner secret（CF Secrets MCP_OWNER_SECRET）把關，只有 owner 知道 →
  只知 URL 的人走不完 OAuth、拿不到 token。
- access_token 是 /mcp 唯一接受的 bearer（預設）；明碼 namespace 舊路徑移除（步驟 5 直接 401）。

實作 endpoint（掛 worker 根路徑）
- RFC 9728 /.well-known/oauth-protected-resource（+/mcp 變體）＋ 401 帶
  WWW-Authenticate: Bearer resource_metadata=...
- RFC 8414 /.well-known/oauth-authorization-server（response_types=code, S256, none）
- RFC 7591 /register（public client，無 secret，無狀態不落地）
- GET/POST /authorize（PKCE S256 + owner-secret 閘 + redirect_uri 白名單）
- POST /token（authorization_code + PKCE 驗證 → access_token 綁定 owner namespace）

儲存鐵律
- authorization code / access token → 短效 KV OAUTH_KV（key 用 SHA-256 hash、帶 TTL、code 一次性）
- owner secret / static token → CF Secrets（非 KV、非明碼 var）
- DCR client / refresh token → 不落地（無狀態 / 不實作，避免長效機密進 KV）

相容決策
- 本機 CLI/GUI/Claude Code → 用真祕密 MCP_STATIC_TOKEN（CF Secret）取代舊明碼 namespace
- 官方 SaaS partner-key 路徑行為不變
- ALLOW_PLAINTEXT_NAMESPACE 逃生門預設關（僅遷移期）

驗證：tsc exit 0；vitest 42/42（oauth 22 + partner-auth 10 改測真實 middleware + 既有 10）；
wrangler deploy --dry-run 打包過、OAUTH_KV binding 正確識別。設計文件 mcp/OAUTH.md。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 03:59:00 +00:00