Misskey项目中用户查询重定向问题的技术分析与解决方案

问题背景

在Misskey社交平台的最新版本(2024.11.0)中，开发团队发现了一个影响用户体验的重要问题：当用户尝试通过包含重定向的URL查询其他用户信息时，系统会返回500内部服务器错误。这个问题在之前的版本(2024.10.1)中并不存在，表明这是新引入的回归性问题。

技术细节分析

该问题主要发生在ActivityPub协议实现的核心组件中。具体表现为：

1. 当用户尝试通过类似"mi.7mi.site/@[e-mail]"这样的跨实例URL查询用户信息时
2. 系统需要先向mi.7mi.site服务器发起请求
3. 该服务器应返回302重定向到实际的misskey.io服务器
4. 但在新版本中，重定向后的请求处理出现了异常

安全考量与设计决策

问题的根源在于Misskey团队近期加强的安全措施。为了防止恶意服务器通过重定向返回伪造的用户信息，系统新增了严格的URL验证机制：

1. 在ApResolverService中实现了assertActivityMatchesUrls检查
2. 确保获取的ActivityPub对象确实来自声明的权威来源
3. 该检查会验证返回对象的URL/URI属性是否与请求的域名匹配

虽然这些安全措施是必要的，但它们意外地影响了正常的重定向查询流程。

解决方案的探讨

开发团队讨论了多种可能的解决方案：

1. 严格验证方案：检测到重定向时向用户显示错误和解决方法
2. 用户确认方案：检测到重定向时弹出确认对话框，用户同意后继续
3. 放宽检查方案：考虑到已有签名验证(signedGet)，可以适当放宽检查
4. 双重验证方案：比较重定向前后获取的信息，确认一致后显示

经过深入讨论，团队最终选择了在保持安全性的前提下优化验证逻辑的方案。

最终实现方案

解决方案的核心修改包括：

1. 在ap/show端点允许NonCanonicalId和CrossOrigin情况
2. 保留核心安全验证的同时，处理合法的重定向场景
3. 确保用户查询流程的顺畅性

这一修改既解决了重定向查询失败的问题，又维持了系统的安全防护级别。

对开发者的启示

这个案例为分布式社交网络开发提供了宝贵经验：

1. 安全措施需要与用户体验保持平衡
2. 重定向处理在联邦式系统中具有特殊重要性
3. 版本升级时需要对边缘案例进行充分测试
4. 安全验证逻辑需要考虑实际应用场景

Misskey团队通过这个问题进一步优化了ActivityPub协议实现，为后续开发奠定了更坚实的基础。