使用 Webhook 的最佳做法

应仅订阅需要的 Webhook 事件。这可减少服务器需要完成的工作量。有关订阅事件的详细信息，请参阅“创建网络钩子”和“测试 Webhook”。

使用 Webhook 机密

警告

为避免意外泄露敏感信息，请勿在有效负载 URL 中包含敏感信息****。这包括你自己的 API 密钥和其他身份验证凭据。相反，为了验证 webhook 的交付确实由 GitHub 发送且未被篡改，请使用 webhook 密钥。有关详细信息，请参阅“验证 Webhook 交付”。

Webhook 密钥应选择高熵的随机文本字符串。应以服务器可以访问的方式安全存储 Webhook 密钥。

使用 HTTPS 和 SSL 验证

应确保服务器使用 HTTPS 连接。默认情况下， GitHub 在传送 Webhook 时，将验证 SSL 证书。 GitHub 建议启用 SSL 验证。

在 10 秒内响应

服务器应在收到 Webhook 传递后的到 30 秒内响应 2XX 状态码。如果服务器花费的时间超过响应时间，则 GitHub 终止连接，并考虑传递失败。

为了及时响应，您可能需要设置一个队列来异步处理 webhook 数据负载。服务器可以在收到 Webhook 时进行响应，然后在后台处理有效负载，而不阻止未来的 Webhook 传递。例如，可以使用Hookdeck等服务或Resque、RQ（Python），或RabbitMQ（Java）等库。

在处理事件之前检查事件类型和操作

Webhook 事件类型有多种，并且许多事件都可以有多个操作类型。 GitHub 继续向现有事件类型添加新事件类型和新操作。在处理 Webhook 有效负载之前，应用程序应检查该有效负载的事件类型和操作。若要确定事件类型，可以使用 X-GitHub-Event 请求标头。要确定操作类型，可以在事件负载中使用顶级 action 键。

重新投递未送达的件

如果服务器出现故障，应在服务器备份后重新传递遗漏的 Webhook。有关详细信息，请参阅“重新传递 Webhook”。

使用 `X-GitHub-Delivery` 标头

在重播攻击中，不良参与者截获 Webhook 交付并重新发送交付。若要防止重播攻击，可以使用 X-GitHub-Delivery 标头来确保每个事件的传递都是唯一的。

注意

如果请求重新传送，X-GitHub-Delivery 标头将与原始传递中的标头相同。

其他阅读材料

        [AUTOTITLE](/rest/guides/best-practices-for-integrators)

        [AUTOTITLE](/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)

在本文中