使用 CloudEvents 架构验证终结点

Webhook 是从 Azure 事件网格接收事件的多种方式之一。 当新事件准备就绪时，事件网格服务会向已配置的终结点 POST HTTP 请求，并在请求正文中包含该事件信息。

与众多支持 Webhook 的其他服务一样，事件网格需要你证明对 Webhook 的所有权，然后才能开始向该终结点传送事件。 此要求可防止恶意用户用大量事件淹没你的终结点。

CloudEvents v1.0 使用 HTTP OPTIONS 方法实现自己的滥用保护语义。 使用 CloudEvents 架构进行输出时，事件网格将使用 CloudEvents v1.0 滥用防护取代事件网格验证事件机制。

任何允许向任意 HTTP 端点注册和传递通知的系统都有可能被滥用，例如有人恶意或无意中注册了一个不期望接收此类请求的系统地址，并且注册方无权进行此类注册。 在极端情况下，通知基础结构可能会被滥用，用来对任意网站发起拒绝服务攻击。

为了保护发送方免受这种滥用危害，合法的传递目标需要表明它同意接收通知。

传送协议的达成是使用以下验证握手实现的。 握手可以在注册时立即执行，也可以在传递前即时作为“起飞前”请求执行。

请务必了解握手的目的不是建立身份验证或授权上下文。 它只是用来避免发送方被告知向不期望流量的目的地进行推送。 虽然此规范强制要求使用授权模型，但如果任何网站没有实施访问控制并因此忽略了 Authorization 标头，则此要求不足以保护该网站免受不必要的流量干扰。

传送目标应当支持滥用保护功能。 如果某个目标不支持该功能，则发送方可以选择根本不向目标发送，或者只以非常低的请求速率发送。

验证请求使用 HTTP OPTIONS 方法。 请求将被定向到正在注册的确切资源目标 URI。 使用验证请求，发送方向目标请求发送通知的权限，并且它可以声明所需的请求速率（每分钟请求数）。 传送目标将以许可声明和允许的请求速率进行响应。 下面是几个要包含在验证请求中的标头字段。

WebHook-Request-Origin 标头必须包含在验证请求中，并请求从此发送方发送通知的权限，它包含标识了发送系统的域名系统 (DNS) 表达式，例如 eventemitter.example.com。 该值用于概括地标识代表某个系统行事的所有发送方实例，而非标识单个主机。

握手并授予权限后，发送方必须将 Origin 请求标头用于每个传送请求，其值与此标头的值匹配。

示例：

WebHook-Request-Origin: eventemitter.example.com

当且仅当传送目标允许传送事件时，它在答复请求时才必须包含 WebHook-Allowed-Origin 和 WebHook-Allowed-Rate 标头。 如果传送目标选择通过回调来授予权限，则它不会使用响应标头。

如果传送目标不允许传送事件或不期望传送事件，但仍处理 HTTP OPTIONS 方法，则不应将现有响应解释为同意，因此握手不能依赖于状态代码。 如果传送目标不处理 HTTP OPTIONS 方法，则应以 HTTP 状态代码 405 进行响应，就像 OPTIONS 不受支持一样。

OPTIONS 响应应包括 Allow 标头，以指示允许 POST 方法。 资源上可能允许使用其他方法，但它们的功能不在此规范的范围内。

当传送目标同意源服务发送通知时，必须返回 WebHook-Allowed-Origin 标头。 其值必须是 WebHook-Request-Origin 标头中提供的源名称，或者是单一星号字符 ('*')，指示传送目标支持来自所有源的通知。

WebHook-Allowed-Origin: eventemitter.example.com

或

WebHook-Request-Origin: *

请参阅以下文章，了解如何排查事件订阅验证问题：排查事件订阅验证问题。