ModelContextProtocol Inspector 中Bearer Token被代理会话Token覆盖的问题分析

问题背景

在ModelContextProtocol Inspector工具的使用过程中，开发者发现了一个关于HTTP授权头处理的缺陷。当用户尝试测试自己的Bearer Token认证实现时，如果自定义头名称也是"Authorization"，工具中输入的Bearer Token会被代理会话Token覆盖，导致无法正确测试自定义的Bearer Token授权机制。

问题现象

具体表现为：当用户在工具侧边栏输入测试用的Bearer Token（例如"test"）并连接到本地服务器时，服务器实际接收到的授权头中的Token并非用户输入的测试值，而是工具自动生成的代理会话Token。这使得开发者无法验证自己的Bearer Token授权实现是否正常工作。

技术原理分析

该问题的根源在于HTTP头合并策略的实现上。ModelContextProtocol Inspector工具在处理请求时，会同时考虑两种授权机制：

1. 用户自定义的Bearer Token授权
2. 工具内部的代理会话Token授权

当这两种机制都使用标准的"Authorization"头时，工具在合并HTTP头时采用了简单的对象展开操作，导致后展开的对象属性会覆盖先前设置的相同属性。具体来说，代理会话Token的设置发生在用户Token之后，因此最终生效的是代理会话Token。

影响范围

这个问题主要影响以下场景：

• 开发者使用ModelContextProtocol Inspector测试自己的Bearer Token认证实现
• 使用标准"Authorization"头进行认证的服务
• 需要验证自定义Token是否被正确传递的调试场景

解决方案

目前有两种临时解决方案：

1. 使用非标准的自定义头名称替代标准的"Authorization"头
2. 设置环境变量DANGEROUSLY_OMIT_AUTH=true来禁用代理授权机制

从代码层面来看，问题的根本解决方案应该是改进头合并策略，确保用户显式设置的Bearer Token不会被自动生成的代理Token覆盖。这可以通过以下几种方式实现：

• 优先保留用户显式设置的Token
• 为代理Token使用不同的头名称
• 提供明确的配置选项让用户选择使用哪种授权机制

最佳实践建议

对于使用ModelContextProtocol Inspector进行API测试的开发者，建议：

1. 在测试自定义认证时，优先使用非标准头名称以避免冲突
2. 如果必须使用标准"Authorization"头，确保了解工具的授权头处理机制
3. 定期更新工具版本以获取最新的修复和改进
4. 在关键认证流程中，同时验证服务器端接收到的头信息以确保符合预期

总结

HTTP头处理是Web开发中的基础但关键的部分，特别是在涉及多层认证机制时更需要谨慎处理。ModelContextProtocol Inspector中的这个案例提醒我们，在设计和实现类似工具时，需要特别注意标准头的处理策略，确保不会意外覆盖用户显式设置的配置值。