Static OAuth client loses its SEP-2352 issuer stamp across SDK saves and restarts
维护者通常 1 天内回复
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 72/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Start in core/auth/providers.ts by tracing clientInformation(), saveClientInformation(), and resolveSdkRegistrationKind; then find the related auth provider tests. Reproduce the sequence in the issue: save a preregistered client, back-stamp { issuer }, and reinitialize with the same static config. Done when the issuer persists across that sequence and no warning fires.
由索引模型根据 Issue 内容生成。
描述
Problem
For a static (preregistered) OAuth client, the SEP-2352 issuer stamp doesn't survive SDK saves and CLI restarts, so the issuer binding is missing and the SDK warns again on every run.
In core/auth/providers.ts:
clientInformation()returns the preregistered slot first (issuer-independent).- The SDK's back-stamp after discovery goes through
saveClientInformation()with{ issuer }only. That routes throughresolveSdkRegistrationKindinto the per-issuer dynamic slot, which the preregistered read never looks at. - Re-seeding the static client at init then drops whatever was stamped.
The effect: the binding falls back to the SDK's unbound legacy behaviour, and the warning repeats on every restart. Reported against 2.11.0.
Expected
Once the SDK has stamped the issuer for a preregistered client, the stamp persists with that client and is returned on the next read. Re-seeding the same static client at startup keeps an existing stamp unless the client itself changed.
Notes
- Cover it with a test: save a preregistered client, SDK back-stamp with
{ issuer }, re-init with the same static config, then assert the issuer is present and no warning fires.
Priority score
Severity 3, Urgency 3, +1 bug, +1 milestone, Total 8 → Medium.
- 主要语言
- TypeScript
- 星标
- 11.2k
- 派生
- 1.6k
- 平均合并
- 3 小时 52 分钟
- 30 天内合并 PR
- 142
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
chore dependabot v2
难度 1/5 1-3 小时 新手友好度 76/100
modelcontextprotocol/inspector#2899 ·
维护者通常 1 天内回复
-
chore dependabot v2
难度 2/5 1-3 小时 新手友好度 82/100
modelcontextprotocol/inspector#2898 ·
维护者通常 1 天内回复
-
chore dependabot v2
难度 1/5 1-3 小时 新手友好度 82/100
modelcontextprotocol/inspector#2897 ·
维护者通常 1 天内回复
-
chore dependencies v2
难度 2/5 1-3 小时 新手友好度 78/100
modelcontextprotocol/inspector#2889 ·
维护者通常 1 天内回复
-
enhancement v2
难度 4/5 3-5 天 新手友好度 42/100
modelcontextprotocol/inspector#2914 · 1 条评论 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
area: web bug
难度 2/5 1-3 小时 新手友好度 76/100
kinqsradio/orbyn-engineering#227 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
joeldesante/TurfBuilder#258 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
ncecere/open-mcp-portal#85 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 63/100
loathers/garbage-collector#2865 ·
维护者通常 1 天内回复
-
test-reliability
难度 2/5 1-3 小时 新手友好度 78/100
Azure/azure-sdk-for-js#40672 · 1 个 reaction ·
维护者通常 1 天内回复