Подписка на минимальное количество событий
Вы должны подписаться только на нужные события веб-перехватчика. Это приведет к сокращению объема работы, необходимой для сервера. Дополнительные сведения о подписке на события см. в разделе [AUTOTITLE и Создание веб-перехватчиков](/webhooks/using-webhooks/editing-webhooks).
Использование секрета веб-перехватчика
Warning
Чтобы избежать случайного раскрытия конфиденциальной информации, не включайте конфиденциальную информацию в URL-адрес полезных данных. Это включает собственные ключи API и другие учетные данные проверки подлинности. Вместо этого, чтобы убедиться, что поставки веб-перехватчика были отправлены GitHub и не были изменены, используйте секрет веб-перехватчика. Дополнительные сведения см. в разделе Проверка доставки веб-перехватчика.
Секрет веб-перехватчика должен быть случайной строкой текста с высокой энтропией. Вы должны безопасно хранить секрет веб-перехватчика таким образом, чтобы к серверу можно было получить доступ.
Использование проверки HTTPS и SSL
Убедитесь, что сервер использует подключение HTTPS. По умолчанию GitHub проверяет SSL-сертификаты при доставке веб-перехватчиков. GitHub рекомендует оставить включенную проверку SSL.
Разрешить ip-адреса GitHub.
Вы можете настроить список разрешений IP-адресов для сервера и добавить IP-адреса, которые GitHub используются для доставки веб-перехватчиков. Это может блокировать спуфинированные запросы к серверу.
Вы можете использовать конечную точку GET /meta для поиска текущего списка данных . Дополнительные сведения см. в разделе Конечные точки REST API для метаданных. GitHub иногда вносит изменения в его IP-адреса, поэтому периодически следует обновлять список разрешений IP-адресов.
Дополнительные сведения см. в разделе Сведения об IP-адресах GitHub.
Ответ в 10 секунды
Сервер должен отвечать на ответ 2XX в 10 секунды получения доставки веб-перехватчика. Если сервер занимает больше времени, чем для ответа, GitHub завершает подключение и рассматривает сбой доставки.
Чтобы своевременно реагировать, может потребоваться настроить очередь для обработки полезных данных веб-перехватчика асинхронно. Сервер может реагировать, когда он получает веб-перехватчик, а затем обрабатывать полезные данные в фоновом режиме, не блокируя будущие поставки веб-перехватчика. Например, можно использовать такие службы, как Hookdeck или библиотеки, такие как Resque (Ruby), RQ (Python) или RabbitMQ (Java).
Проверка типа события и действия перед обработкой события
Существует несколько типов событий веб-перехватчика, и многие события могут иметь несколько типов действий. GitHub продолжает добавлять новые типы событий и новые действия в существующие типы событий. Приложение должно проверить тип события и действие полезных данных веб-перехватчика перед обработкой полезных данных. Чтобы определить тип события, можно использовать X-GitHub-Event заголовок запроса. Чтобы определить тип действия, можно использовать ключ верхнего уровня action в полезных данных события.
Redeliver пропущенные поставки
Если сервер выходит из строя, вы должны повторно создать пропущенные веб-перехватчики после резервного копирования сервера. Дополнительные сведения см. в разделе Повторное создание веб-перехватчиков.
Использование заголовка X-GitHub-Delivery
В атаке воспроизведения плохой субъект перехватывает доставку веб-перехватчика и повторно отправляет доставку. Для защиты от атак воспроизведения можно использовать X-GitHub-Delivery заголовок, чтобы убедиться, что каждая доставка уникальна для каждого события.
Note
Если запросить повторное создание, заголовок будет таким же, X-GitHub-Delivery как и в исходной доставке.