LGTM (40 частей серии)
Теперь, когда у нас есть настройка шаблонов, пришло время взглянуть на то, что дает нам GitHub данных через WebHook, когда мы делаем запрос на вилку.
Я собираюсь настроить Webhooks для репо и скажу, чтобы он отправил мне только Webhooks для Forks.
Некоторые из настройки, которые я использовал:
- URL полезной нагрузки В конечном итоге это будет наша конечная точка облачных функций. Я использую чрезвычайно полезный ngrok Служба временного туннелирования конечной точки, оснащенной HTTS, на мою локальную машину без необходимости иметь дело с DNS и PortForbaring.
- Тип контента Я хочу использовать данные JSON, так что это установлено на
Приложение/JSON - Секрет WebHook будет использовать этот секрет для расчета подписи и добавить его в заголовок запроса в качестве дополнительного уровня безопасности, чтобы мы могли отклонить самозванцев, пытаясь запустить нашу конечную точку с помощью поддельных данных.
- SSL -проверка Это заставляет GitHub проверить, что наша конечная точка имеет действительный сертификат SSL при отправке данных. Наличие этого является нормой в наши дни, необычно не иметь его. Поскольку мы используем функции Firebase, SSL уже будет настроен для нас, поэтому нам не нужно беспокоиться об этом
- Какие события? Нам нужно только услышать о вилках на данный момент, поэтому я выбираю это
С помощью этой настройки сохраните его, а затем идите, создайте еще одну учетную запись GitHub, из которой я могу попытаться разобраться в этом репо (я назвал учетную запись «LGTM-Garry», потому что я буду использовать эту учетную запись для одной из NPC позже). Как только я это сделаю, я смогу запустить NGROK, вставить новый временный URL в раздел GitHub Webhooks и получать данные WebHook. Поскольку у меня на самом деле нет конечной точки для Ngrok для пересылки, он генерирует ошибку Bad Gateway 502, но я все еще могу получить доступ к полезной нагрузке через локальный веб -интерфейс Ngrok.
Та же самая полезная нагрузка доступна в разделе «Показания» Github:
Вся полезная нагрузка довольно большая и, кажется, полон URL -адресов, которые могут быть полезны. Я предполагаю, что политика GitHub по этому поводу состоит в том, чтобы создать все URL -адреса, чтобы потребитель API было легким, чтобы потребитель не имел необходимости использовать любую логику на своем конце для построения URL -адресов. Это означает, что GitHub могут свободно изменять формат URL, не нарушая потребительский код.
После просмотра полезной нагрузки JSON, это, кажется, единственные соответствующие части, которые нам нужны:
{
"forkee": {
"owner": {
"login": "LGTM-garry",
"id": 76662434,
},
"url": "https://api.github.com/repos/LGTM-garry/lgtm"
},
"repository": {
"full_name": "meseta/lgtm"
}
}
Эта полезная нагрузка содержит:
- Имя пользователя GitHub и удостоверение личности аккаунта, которая развела. Нам нужно это, чтобы ассоциировать игровые данные с учетной записью, и я думаю, что нам нужно также хранить идентификатор, чтобы избежать разрыва вещей, если они меняют свое имя пользователя.
- API URL результирующей вилки. Нам нужно это, чтобы мы могли отправить проблемы позже. Я Подумайте Это этот URL, который нам нужен, хотя я вполне могу узнать, что это другой URL позже, посмотрим.
- Репозиторий, который был раздвоен. Нам нужно, чтобы это дважды проверило это репо, который был разднулся. Если в будущем по какой -то причине у нас есть несколько репо, я не хочу путать, какой из них был просто раздвоен.
В то время как заголовок содержит эти заголовки для проверки:
- X-hub-signature: подпись SHA1
- X-Hub-Signature-256: SHA256 Подпись
GitHub’s Документация Об этих подписях описывает нам, как реализовать проверку подписи, и быстрый поиск в Google показывает некоторые Примеры Python/Flask что мы можем прикрутить.
LGTM (40 частей серии)
Оригинал: “https://dev.to/meseta/lgtm-devlog-10-capturing-the-github-webhook-for-fork-requests-3o3e”