Рекомендации по использованию веб-перехватчиков

Вы должны подписаться только на нужные события веб-перехватчика. Это приведет к сокращению объема работы, необходимой для сервера. Дополнительные сведения о подписке на события см. в разделе [AUTOTITLE и Создание веб-перехватчиков](/webhooks/using-webhooks/editing-webhooks).

Использование секрета веб-перехватчика

Предупреждение

Чтобы избежать случайного раскрытия конфиденциальной информации, не включайте конфиденциальную информацию в URL-адрес полезных данных. Это включает собственные ключи API и другие учетные данные проверки подлинности. Вместо этого, чтобы убедиться, что доставки webhook были отправлены и GitHub не подвергались вмешательству, используйте секрет webhook. Дополнительные сведения см. в разделе Проверка доставки веб-перехватчика.

Секрет веб-перехватчика должен быть случайной строкой текста с высокой энтропией. Вы должны безопасно хранить секрет веб-перехватчика таким образом, чтобы к серверу можно было получить доступ.

Использование проверки HTTPS и SSL

Убедитесь, что сервер использует подключение HTTPS. По умолчанию GitHub будут проверять SSL-сертификаты при доставке вебхуков. GitHub рекомендую оставить включённой SSL-верификацию.

Разрешить GitHubIP-адреса

Вы можете настроить список разрешений IP-адресов для вашего сервера и добавить IP-адреса, используемые GitHub для доставки вебхуков. Это может блокировать спуфинированные запросы к серверу.

Вы можете использовать GET /meta конечную точку, чтобы найти текущий GitHubсписок IP-адресов . Дополнительные сведения см. в разделе Конечные точки REST API для метаданных. GitHub иногда меняет IP-адреса, поэтому периодически обновляйте список разрешений IP.

Дополнительные сведения см. в разделе О IP-адресах GitHub.

Ответьте в течение 10-30 секунд

Ваш сервер должен ответить ответом в 2XX в течение 10 секунд после получения доставки вебхука. Если ваш сервер отвечает дольше, то GitHub соединение прекращается и считает доставку неудачной.

Чтобы своевременно реагировать, может потребоваться настроить очередь для обработки полезных данных веб-перехватчика асинхронно. Сервер может реагировать, когда он получает веб-перехватчик, а затем обрабатывать полезные данные в фоновом режиме, не блокируя будущие поставки веб-перехватчика. Например, вы можете использовать сервисы вроде Hookdeck или библиотеки вроде Resque (Ruby), RQ (Python) или RabbitMQ (Java).

Проверка типа события и действия перед обработкой события

Существует несколько типов событий веб-перехватчика, и многие события могут иметь несколько типов действий. GitHub продолжает добавлять новые типы событий и новые действия к существующим типам событий. Приложение должно проверить тип события и действие полезных данных веб-перехватчика перед обработкой полезных данных. Для определения типа события можно использовать заголовок запроса X-GitHub-Event. Чтобы определить тип действия, можно использовать ключ верхнего уровня action в полезных данных события.

Redeliver пропущенные поставки

Если сервер выходит из строя, вы должны повторно создать пропущенные веб-перехватчики после резервного копирования сервера. Дополнительные сведения см. в разделе Повторное создание веб-перехватчиков.

Используйте заголовок `X-GitHub-Delivery`

В атаке воспроизведения плохой субъект перехватывает доставку веб-перехватчика и повторно отправляет доставку. Чтобы защититься от повторных атак, можно использовать заголовок 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)

Рекомендации по использованию веб-перехватчиков

В этой статье