这是提交给由 森特里 支持的 开发者社区夏季漏洞大扫除：故事分享 的活动作品。
支付网络钩子听起来很简单，直到你发现一次成功的支付并没有真正带来客户所购买的服务。
这是我在构建“倾听之耳”（一个预约和在线咨询平台）时遇到的比较有趣的漏洞之一。
需求很直接：
客户支付会话费用 → 应用程序确认支付 → 客户的预约被预订 → 创建 Zoom 会议。
现实情况要复杂得多。
项目概述
“倾听之耳”将在线支付与预约调度以及基于 Zoom 的咨询连接起来。
该应用程序使用了一系列技术构建，包括 Next.js 14、TypeScript、Supabase、Prisma、PostgreSQL、Zoom 以及支付提供商的应用程序接口。
支付流程尤为重要，因为支付确认实际上是后续所有预订体验的关卡。
预期的流程如下：
客户
│
▼
支付提供商
│
│ 网络钩子
▼
Next.js 网络钩子
│
├── 验证/解析支付
│
├── 创建 Zoom 会议
│
└── 创建预约记录
│
▼
客户获得对其预定会话的访问权限
问题在于，网络钩子直接位于所有这些操作的中间。
漏洞修复还是性能改进
这个漏洞出现在我实现用于解锁 Zoom 调度流程的支付网络钩子时。
我的初始实现监听支付事件，并检查该事件是否为：
if (event === 'charge.success') {
一旦满足该条件，网络钩子便立即继续进入预订流程。
该流程包括：
- 从支付事件中读取预约元数据。
- 处理特殊的紧急预约。
- 构建 Zoom 会议负载数据。
- 调用 Zoom 会议应用程序接口。
- 在数据库中创建预约记录。
- 向支付提供商返回成功响应。
问题在于，所有这些操作都有效地耦合到了网络钩子请求中。
支付网络钩子是一个异步的外部事件。它可能会被重试、多次交付，或者在系统的另一部分仍在处理时到达。
我的初始实现将其过于当作普通的同步应用程序接口请求来处理。
这造成了一个瓶颈：
支付确认 → 网络钩子 → Zoom 应用程序接口 → 预约应用程序接口 → 响应
如果其中一个下游操作缓慢或失败，网络钩子本身可能会失败。
这意味着支付提供商可能会重试该网络钩子。
然后，我可能会最终再次处理同一笔成功的支付。
这才是我需要解决的实际漏洞。
调试之旅
第一个症状很容易被误解。
用户已成功完成支付，但预期的 Zoom 调度体验并不总能正确完成。
我的第一直觉自然是查看 Zoom 集成。
但逆向追踪请求暴露了一个更有趣的依赖关系：
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
