최소 이벤트 수 구독
필요한 웹후크 이벤트만 구독해야 합니다. 그러면 서버에서 수행해야 하는 작업의 양이 줄어듭니다. 이벤트 구독에 대한 자세한 내용은 AUTOTITLE 및 AUTOTITLE을(를) 참조하세요.
웹후크 비밀 사용
경고
중요한 정보가 실수로 노출되지 않도록 하려면 페이로드 URL에 중요한 정보를 포함하지 않도록 주의하세요. 여기에는 사용자 고유의 API 키 및 기타 인증 자격 증명이 포함됩니다. 대신 웹후크 제공이 GitHub에서 전송되었지만 변조되지 않았는지 확인하려면 웹후크 비밀을 사용합니다. 자세한 내용은 AUTOTITLE을(를) 참조하세요.
웹후크 비밀은 엔트로피가 높은 임의의 텍스트 문자열이어야 합니다. 서버에서 액세스할 수 있는 방식으로 웹후크 비밀을 안전하게 저장해야 합니다.
HTTPS 및 SSL 확인 사용
서버에서 HTTPS 연결을 사용하는지 확인해야 합니다. 기본적으로 GitHub은(는) 웹후크를 제공할 때 SSL 인증서를 확인합니다. GitHub은(는) SSL 확인을 사용하도록 설정하는 것이 좋습니다.
30 초 내에 응답
서버는 웹후크 제공을 받은 후 30 초 내에 2XX 응답으로 응답해야 합니다. 서버가 응답하는 데 이보다 더 오래 걸리면 GitHub가 연결을 종료하고 제공을 실패로 간주합니다.
적시에 응답하기 위해 웹후크 페이로드를 비동기적으로 처리하도록 큐를 설정할 수 있습니다. 서버는 웹후크를 받을 때 응답한 다음 이후 웹후크 제공을 차단하지 않고 백그라운드에서 페이로드를 처리할 수 있습니다. 예를 들어 Hookdeck 같은 서비스 또는 Resque(Ruby)와 같은 라이브러리를 사용할 수 있습니다. ), RQ(Python) 또는 RabbitMQ(Java).
이벤트를 처리하기 전에 이벤트 유형 및 작업 확인
여러 가지 웹후크 이벤트 유형이 있으며, 많은 이벤트에 다양한 작업 유형이 있을 수 있습니다. GitHub은(는) 기존 이벤트 형식에 새 이벤트 유형과 새 작업을 계속 추가합니다. 애플리케이션은 페이로드를 처리하기 전에 웹후크 페이로드의 이벤트 유형 및 작업을 확인합니다. 이벤트 유형을 확인하려면 X-GitHub-Event 요청 헤더를 사용할 수 있습니다. 작업 유형을 확인하기 위해 이벤트 페이로드에서 최상위 키를 사용할 수 있습니다.
누락된 제공 다시 제공하기
서버가 다운된 경우 서버가 백업되면 누락된 웹후크를 다시 제공해야 합니다. 자세한 내용은 AUTOTITLE을(를) 참조하세요.
`X-GitHub-Delivery` 헤더 사용
리플레이 공격에서는 악의적인 주체가 웹후크 전송을 가로채 해당 전송을 다시 보냅니다. 재생 공격으로부터 보호하기 위해 X-GitHub-Delivery 헤더를 사용하여 각 배달이 이벤트별로 고유하도록 할 수 있습니다.
참고 항목
다시 배달을 요청하는 경우 X-GitHub-Delivery 헤더는 원래 배달과 동일합니다.
추가 참고 자료
- AUTOTITLE
- AUTOTITLE