Arcrun

Leo/Arcrun

Fork 0

Commit Graph

Author	SHA1	Message	Date
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

Author

SHA1

Message

Date

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

3 Commits