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