{"meta":{"title":"使用 Webhook 的最佳做法","intro":"在使用 Webhook 时遵循以下最佳做法以提高安全性和性能。","product":"Webhook","breadcrumbs":[{"href":"/zh/enterprise-cloud@latest/webhooks","title":"Webhook"},{"href":"/zh/enterprise-cloud@latest/webhooks/using-webhooks","title":"使用网络钩子（Webhook）"},{"href":"/zh/enterprise-cloud@latest/webhooks/using-webhooks/best-practices-for-using-webhooks","title":"最佳做法"}],"documentType":"article"},"body":"# 使用 Webhook 的最佳做法\n\n在使用 Webhook 时遵循以下最佳做法以提高安全性和性能。\n\n## 订阅的事件数应尽可能少\n\n应仅订阅需要的 Webhook 事件。 这可减少服务器需要完成的工作量。 有关订阅事件的详细信息，请参阅“[创建网络钩子](/zh/enterprise-cloud@latest/webhooks/using-webhooks/creating-webhooks)”和“[测试 Webhook](/zh/enterprise-cloud@latest/webhooks/using-webhooks/editing-webhooks)”。\n\n## 使用 Webhook 机密\n\n> \\[!WARNING]\n> 为避免意外泄露敏感信息，请勿在有效负载 URL 中包含敏感信息\\*\\*\\*\\*。\n> 这包括你自己的 API 密钥和其他身份验证凭据。 相反，为了验证 webhook 的交付确实由 GitHub 发送且未被篡改，请使用 webhook 密钥。 有关详细信息，请参阅“[验证 Webhook 交付](/zh/enterprise-cloud@latest/webhooks/using-webhooks/validating-webhook-deliveries)”。\n\nWebhook 密钥应选择高熵的随机文本字符串。 应以服务器可以访问的方式安全存储 Webhook 密钥。\n\n## 使用 HTTPS 和 SSL 验证\n\n应确保服务器使用 HTTPS 连接。 默认情况下， GitHub 在传送 Webhook 时，将验证 SSL 证书。\nGitHub 建议启用 SSL 验证。\n\n## 允许 GitHub的 IP 地址\n\n可以为您的服务器设置一个 IP 允许列表，并添加 GitHub 使用于 Webhook 传输的 IP 地址。 这可以阻止对服务器的欺骗请求。\n\n可以使用 `GET /meta` 端点来查找GitHub的当前 IP 地址列表。 有关详细信息，请参阅“[元数据的 REST API 端点](/zh/enterprise-cloud@latest/rest/meta/meta#get-github-meta-information)”。\nGitHub 偶尔会对其 IP 地址进行更改，因此应定期更新 IP 允许列表。\n\n有关详细信息，请参阅“[关于GitHub的 IP 地址](/zh/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses)”。\n\n## 在 10 秒内响应\n\n你的服务器应在收到 Webhook 传递后的 10 秒内返回 2XX 响应。 如果服务器花费的时间超过响应时间，则 GitHub 终止连接，并考虑传递失败。\n\n为了及时响应，您可能需要设置一个队列来异步处理 webhook 数据负载。 服务器可以在收到 Webhook 时进行响应，然后在后台处理有效负载，而不阻止未来的 Webhook 传递。 例如，可以使用[Hookdeck](https://hookdeck.com)等服务或[Resque](https://github.com/resque/resque/)、[RQ](http://python-rq.org/)（Python），或[RabbitMQ](http://www.rabbitmq.com/)（Java）等库。\n\n## 在处理事件之前检查事件类型和操作\n\nWebhook 事件类型有多种，并且许多事件都可以有多个操作类型。\nGitHub 继续向现有事件类型添加新事件类型和新操作。 在处理 Webhook 有效负载之前，应用程序应检查该有效负载的事件类型和操作。 若要确定事件类型，可以使用 `X-GitHub-Event` 请求标头。 要确定操作类型，可以在事件负载中使用顶级 `action` 键。\n\n## 重新投递未送达的件\n\n如果服务器出现故障，应在服务器备份后重新传递遗漏的 Webhook。 有关详细信息，请参阅“[重新传递 Webhook](/zh/enterprise-cloud@latest/webhooks/testing-and-troubleshooting-webhooks/redelivering-webhooks)”。\n\n## 使用 `X-GitHub-Delivery` 标头\n\n在重播攻击中，不良参与者截获 Webhook 交付并重新发送交付。 若要防止重播攻击，可以使用 `X-GitHub-Delivery` 标头来确保每个事件的传递都是唯一的。\n\n> \\[!NOTE]\n> 如果请求重新传送，`X-GitHub-Delivery` 标头将与原始传递中的标头相同。\n\n## 其他阅读材料\n\n* [使用 REST API 的最佳做法](/zh/enterprise-cloud@latest/rest/using-the-rest-api/best-practices-for-using-the-rest-api)\n* [创建GitHub应用的最佳做法](/zh/enterprise-cloud@latest/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)"}