GitHub เพิ่ม IP webhook 48 ที่อยู่ แต่ยังต้องตรวจลายเซ็น
เปิด pull request แล้วบอต deployment กลับเงียบ คำขออาจถูกไฟร์วอลล์ปฏิเสธก่อนถึงแอป ประกาศ GitHub วันที่ 29 ตุลาคมเกี่ยวข้องกับเส้นทางขาเข้านี้
สามช่วงใหม่สำหรับฝั่งรับ
CIDR ใหม่คือ 9.234.98.160/28, 9.234.98.176/28 และ 9.234.106.48/28 ใช้กับ webhook จาก github.com ทุกแผนรวม GitHub Enterprise Cloud หากใช้รายการอนุญาตแบบคงที่ ให้เพิ่มโดยคงช่วงเดิมไว้
แต่ละ /28 มี 16 ที่อยู่ รวม 48 ภาพแสดงผลคำนวณจริงในเครื่องด้วย Python ipaddress ไม่ใช่จำนวนบัญชีหรือเซิร์ฟเวอร์ GitHub ระบุว่าผู้ที่อัปเดตรายการจาก hooks ของ GET /meta อยู่แล้วไม่ต้องเปลี่ยนเพิ่มสำหรับครั้งนี้
IP กับลายเซ็นตอบคนละคำถาม
รายการอนุญาตกำหนดว่าเครือข่ายใดเข้าถึงฝั่งรับได้ ต้องใช้ hooks ไม่ใช่ actions ซึ่งเป็นอีกเส้นทางของ runner การรับเหตุการณ์กับการเรียก API ภายนอกจาก CI มีทิศทางต่างกัน
จากนั้นตรวจ X-Hub-Signature-256 ด้วย secret ของ webhook นั้น GitHub สร้าง HMAC-SHA256 จาก secret และเนื้อหา ให้คำนวณจากไบต์ต้นฉบับและเปรียบเทียบแบบเวลาคงที่ เช่น hmac.compare_digest หรือ crypto.timingSafeEqual แม้ IP ผ่านก็ยังต้องตรวจ
JSON ความหมายเดิมแต่อาจเป็นคนละไบต์
แปลง {"action":"opened"} เป็น {"action": "opened"} จะเพิ่มช่องว่าง ความหมายเหมือนเดิมแต่ลายเซ็นอาจไม่ตรง ตัวอย่างในเครื่องใช้ secret สาธารณะสำหรับสาธิต ผลไบต์เดิมเป็น True และเมื่อเพิ่มช่องว่างเป็น False ไม่ใช่การจับ webhook จริงจาก GitHub
เก็บเนื้อหาดิบก่อนแปลง และตรวจว่าพร็อกซีหรือเฟรมเวิร์กแก้ไขหรือไม่ การใส่ secret ใน URL ของ payload จะเพิ่มช่องทางรั่วไหล ควรเก็บในค่าตั้งเซิร์ฟเวอร์ที่ปลอดภัย
กู้คืนโดยไม่ทำงานที่เสร็จแล้วซ้ำ
เมื่อแก้เครือข่ายแล้วให้ดูรายการส่งล้มเหลวและส่งซ้ำเท่าที่จำเป็น X-GitHub-Delivery ยังคงเดิมในการส่งซ้ำที่ร้องขอ จึงต้องแยกงานเสร็จจากงานล้มเหลวที่ทำต่อได้ การทิ้งทุก ID ที่เคยพบอาจขัดขวางการกู้คืน
GitHub แนะนำตอบ 2XX ภายในสิบวินาทีและใช้คิวสำหรับงานนาน เชื่อมการตรวจลายเซ็น การรับที่จัดเก็บถาวร และสถานะที่ลองใหม่ได้ เพื่อเห็นเส้นทางตั้งแต่มาถึง ตรวจสอบ จนงานเสร็จ