Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

CLI stored-auth flags (--use-stored-auth, --list-stored-auth, --wait-for-auth) miss tokens stored under byIssuer

Đã đóng
  • Có gì không ổn?
#2,517 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
authentication, cli

Hướng nghiên cứu

Start in clients/cli/src/cli.ts at findStoredToken and the --list-stored-auth and --use-stored-auth handlers; inspect the existing stored-auth tests for the byIssuer shape. Reproduce with the OAuth test server and an isolated MCP_STORAGE_DIR. Done means list, use, wait, and refresh write-back operate on the active issuer's joined token view and the tests cover this shape.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug v2

Problem

The CLI's stored-auth flags can't see a token the shared OAuth store actually holds:

  • --use-stored-auth exits 3 with no_stored_token, and its message lists the very URL it failed to match under "Stored keys".
  • --list-stored-auth returns "storedServerUrls": [].
  • --wait-for-auth goes through the same lookup (findStoredToken), so going by the code it waits until it times out even after the token lands. I haven't run this one.

The lookups in clients/cli/src/cli.ts read the token at the server level: state.tokens?.access_token / state.tokens?.refresh_token (on v2/main: L325 findStoredToken, L388, L1010 --list-stored-auth, L1120–1121 --use-stored-auth). Since the OAuth store was re-keyed per issuer (#1625), acquired tokens are stored at servers[url].byIssuer[activeIssuer].tokens, so none of these lookups ever matches. --stored-auth-only is unaffected because it goes through the normal auth provider path, which does read byIssuer.

Found while smoke testing #2482, where it reproduced identically on v2/main (30a9a897) and on the PR head (fc55e11a). So it is not caused by that PR. The PR does change where the tokens live, since they move to the secret store and are joined back on read, so a fix should read the joined view.

Reproduce

  1. Start an OAuth test server: node test-servers/build/server-composable.js --config test-servers/configs/oauth-revocation-http.json (:8083).
  2. With an isolated MCP_STORAGE_DIR, complete an interactive CLI login: mcp-inspector --cli --server-url http://localhost:8083/mcp --method tools/list.
  3. Check the token is there: --stored-auth-only --method tools/list succeeds, and oauth.json shows servers["http://localhost:8083/mcp"].byIssuer["http://localhost:8083"].tokens.
  4. mcp-inspector --cli --list-stored-auth prints storedServerUrls: [].
  5. mcp-inspector --cli --server-url http://localhost:8083/mcp --use-stored-auth --method tools/list exits 3 with {"error":{"code":"no_stored_token",…"Stored keys: http://localhost:8083/mcp."}}.

Expected

  • --list-stored-auth lists the URL.
  • --use-stored-auth refreshes (or injects) the active issuer's token and succeeds.
  • --wait-for-auth returns as soon as the token lands.
  • The refresh write-back persists the rotated tokens under the active issuer.

The existing stored-auth tests should cover the byIssuer shape, so this can't regress silently again.

Ngôn ngữ chính
TypeScript
Star
11.1k
Fork
1.6k
Merge trung bình
4 giờ 56 phút
Pull request đã merge (30 ngày)
155

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/inspector

Tất cả issue của modelcontextprotocol/inspector

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.