获授权 Webhook 捕获与接收端信任检查

目标与适用范围

在获授权的测试环境捕获并回放受控 Webhook 请求，分别检查投递证据和接收端 HTTPS 证书，不把证书有效误写成业务信任证明。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 只使用明确批准的测试或 staging 环境和一次性捕获会话。不要提交生产凭据、正在使用的签名密钥、访问令牌、Cookie 或个人数据。

• 准备合成事件、预期 HTTP 方法和响应范围、准确的接收端主机名及脱敏规则。

• 如果测试包含签名校验，只使用测试专用密钥和已记录的签名请求头，并提前确定回放批准人和保留期限。

• 决策点: 应该先捕获事件，还是立即回放？. 当投递、请求头或签名行为不明确时，先从获授权环境发送合成事件。已有请求只有在来源获授权、完成脱敏且目标和方法得到批准后才能回放。

• 决策点: 问题在传输层，还是业务应用层？. 用 webhook-debugger-relay 检查请求和响应，用 ssl-checker 检查 DNS、证书、链和协议。HTTPS 证书有效只说明传输检查通过，不说明业务归属、授权策略或事件处理正确。

按步骤完成工作流

1. 创建一次性捕获会话

用 webhook-debugger-relay 创建会话，设置测试目标、必要时收窄方法或请求体过滤条件，并限制保存条目数量。从获授权环境向生成的捕获地址发送合成事件。 使用 webhook-debugger-relay.

2. 先检查投递证据，再决定回放

查看方法、请求头、请求体、签名头和响应行为。需要签名时配置一次性测试密钥并对照结果；复核通过后才把脱敏请求回放到批准的接收端。 使用 webhook-debugger-relay.

3. 单独检查 HTTPS 并收口

对接收端主机名运行 ssl-checker，记录 DNS、证书身份、有效期、链信息和协议结果。结合中继和业务证据形成结论，然后删除临时数据。 使用 ssl-checker, webhook-debugger-relay.

交付前验收结果

• 捕获和回放只针对获授权的测试目标，数据为合成或完全脱敏数据，证据中没有真实密钥或个人数据。
• 记录分别保存方法、选定请求头、载荷指纹或脱敏载荷、响应状态、回放决定和证书发现。
• 签名检查写明测试请求头、密钥策略、规范化假设和结果，缺失或无效签名不能被静默绕过。
• 复核人能够重现用例，区分捕获、传输和业务失败，并确认临时数据已清理或按规则保留。

常见问题

• 内部端点可以使用真实 Webhook 密钥吗？ 不可以。应使用一次性测试密钥或脱敏 fixture。捕获会话可能保存请求头和请求体，内部标签不能让生产密钥适合存储。
• HTTPS 证书有效，是否就证明 Webhook 端点可信？ 不是。它只表示证书通过了连接检查，不能证明应用归属、调用授权、路由安全或 Webhook 语义正确。
• 证书通过但投递仍失败，下一步看什么？ 分层检查方法、路径、签名头、载荷编码、响应状态、超时和获授权环境中的应用日志。证书通过不能解释 4xx、5xx、路由错误或业务拒绝。