身份验证 Webhook：在不查询服务商的情况下恢复待处理状态

问题：没有回调的待处理会话

一位卖家开始托管身份验证。你的服务写入一个带截止时间的待处理会话，然后等待。回调可能丢失、延迟，或被配置错误的端点拦截。如果截止时间到了却没有任何处理，会话将永远停留在待处理状态。用户被卡住，支持团队也没有清晰的状态可查。诱人的捷径是等一段时间后直接批准，或者悄悄拒绝。两者都把缺失的证据变成了决定。你真正的选择更窄：截止时间过后，把会话移到一个表示“没有收到答复”的终止状态，再把下一步引导到人工审核，或由你自己的集成负责的、经授权的状态刷新。

本地示例实际实现了什么

可下载的示例是一个无依赖的 Python 3.10+ 夹具，不需要凭据，也不访问网络。Identity 类把会话存入 SQLite，字段包括 status、deadline、granted、grants，以及 policy_version 和 allow_action。create 只接受以 fixture- 开头的标识符，超时时间须在 1 到 3600 秒之间，并写入 status 为 pending、deadline 等于 now 加 timeout。recover 接收会话和当前时间：如果 deadline 小于或等于 now，且 status 为 pending、review 或 unknown，就把 status 设为 expired。随后返回读取结果，并附加 next 为 review_or_authorized_provider_refresh、provider_polled 为 false。这个标志是字面意义上的：recover 不调用任何服务商。事件只接受 mode 为 synthetic_fixture 且 source 为 fixture_callback，其他情况会抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED。这里没有真实的签名验证。它也不同于匿名的三场景 HTTP 试用，以及四分支的电话示例。

假设场景与预期夹具输出

假设：在时间 0 创建合成会话 fixture-session，使用默认的 60 秒超时，因此 deadline 为 60。没有回调到达。你将自行构建的调度器在时间 61 调用 recover。经过测试的输出是：mode 为 synthetic_fixture，session 为 fixture-session，status 为 expired，deadline 为 60，permission_granted 为 false，grant_count 为 0，live_permission_changed 为 false，policy_version 为 1，allow_action 为 true，next 为 review_or_authorized_provider_refresh，provider_polled 为 false。由于状态保存在 SQLite 中，使用同一个数据库文件重启进程后再调用 recover，结果相同。如果截止时间之后才到达一个合成的 Approved 事件，处理程序会记录它，但会话保持过期，不授予任何权限。allow_action 为 true 只表示本地策略允许某个操作，并不等于授权。

由你的应用负责的故障处理

以下是建议的设计，而非已实现的行为：从持久化的调度器运行 recover，而不是从创建会话的那个请求中运行。把 expired 视为“没有答复”，而不是“被拒绝”，并给用户提供重试路径。如果你拥有经授权的服务商路线，可以随后进行有限次数的状态刷新，并配合该服务商特定的签名验证与对账；示例并未建立这两项能力。夹具中的错误是明确的：读取未知会话会抛出 SESSION_NOT_FOUND；针对未知会话、或 tenant 与 subject 不匹配的事件会抛出 BINDING_MISMATCH。重复事件按事件 id 记录，返回当前状态，不会再次授权。请记录这些错误码，而不是盲目重试。

需要牢记的限制

该夹具只证明本地状态转换。它不能说明真实用户完成了托管流程，不能说明服务商回调经过签名，也不能说明任何真实权限发生了变化。合成的 permission_granted 只是本地记录，绝不是真实的业务权限。hosted_link 指向一个无效的示例域名，link_executable 为 false。工程测试覆盖状态转换、绑定、重复事件、重启和超时，但它们不是生产成功或被采用的证据。真实路线是否可用需要另行确认。

验收清单

运行重启测试和超时恢复测试，确认全部通过。创建一个会话后重启，确认 status 仍为 pending，且 deadline 不变。在截止时间之后调用 recover，确认 status 为 expired、permission_granted 为 false、provider_polled 为 false。发送一个迟到的合成 Approved 事件，确认没有授权。确认未知会话会抛出 SESSION_NOT_FOUND 或 BINDING_MISMATCH。确认你的设计永远不会把 expired 映射为批准。在申请沙盒集成之前，写明将来由哪个组件负责签名验证和经授权的状态刷新。这样，团队在接入真实服务商之前，就能清楚区分本地已验证的行为与仍需补充的生产能力，避免把合成结果误读为真实的业务许可。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip，进入 verification_delivery，用 Python 3.10+ 运行。此本地示例不联网；独立身份实验请使用新的数据库。

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

来源与范围

https://gridzen.ai/guides/missing-verification-webhook/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。