เมื่อเชื่อมระบบด้วย webhook เราจะมี endpoint สำหรับรับเหตุการณ์จากอีกบริการ เช่น แจ้งว่างานประมวลผลจบหรือข้อมูลโครงการเปลี่ยน จุดที่เปิดรับนี้ช่วยให้อีกฝั่งส่งข่าวมาได้ทันที แต่ใครที่เข้าถึง URL ได้ก็ยังอาจส่ง HTTP request หน้าตาคล้ายกันเข้ามาได้ด้วย
การได้รับ JSON ที่มี field ครบจึงยังไม่บอกว่ามาจากผู้ส่งที่ตั้งใจเชื่อมไว้ และแม้ตรวจที่มาแล้ว เหตุการณ์เดิมก็อาจถูกส่งซ้ำตามระบบ retry ได้ สิ่งที่ต้องดูจึงมีทั้งความถูกต้องของการส่ง ขอบเขตเวลา และสิ่งที่จะทำเมื่อพบ event ที่เคยรับแล้ว
ก่อนนำ webhook ไปเปลี่ยนข้อมูล ควรตรวจตามกติกาของผู้ให้บริการให้ครบครับ โดยแยกขั้นยืนยันการส่งออกจากขั้นประมวลผลธุรกิจ จะได้ไม่รับทุก request เป็นคำสั่งที่มีสิทธิ์ทำงานเพียงเพราะส่งมาถึง endpoint ถูกแห่ง
ผู้ให้บริการอาจใช้ signature ที่คำนวณจาก payload กับข้อมูลประกอบตาม scheme ของตัวเอง ฝั่งรับต้องใช้ secret หรือข้อมูลตรวจที่กำหนดไว้ถูกชุด แล้วเทียบตามวิธีในเอกสาร ไม่สร้างสูตรกลางขึ้นมาใช้กับ webhook ทุกเจ้า
ตัวอย่าง GitHub มีแนวทางใช้ webhook secret กับ signature ของ payload ส่วน Standard Webhooks เสนอรูปแบบที่รวมรหัสเหตุการณ์ เวลา attempt และ body ในข้อมูลที่ลงนาม ทั้งสองแหล่งช่วยอธิบายหลักการ แต่ไม่ได้หมายความว่า header และรูปแบบเวลาของทุกเจ้าจะเหมือนกัน
สิ่งสำคัญคือ byte ที่ใช้ตรวจต้องตรงกับข้อมูลที่ผู้ส่งลงนาม หากรับ JSON แล้ว parse จากนั้น serialize ใหม่ก่อนคำนวณ อาจเปลี่ยนช่องว่างหรือลำดับรูปแบบจน signature ไม่ตรง ทั้งที่ความหมายของ JSON ดูเหมือนเดิม จึงต้องจัดทางเข้าถึง raw body ตาม framework ที่ใช้
การเทียบ signature ควรใช้วิธีที่ไลบรารีรองรับอย่างถูกต้อง รวมถึง constant-time comparison สำหรับ scheme ที่ต้องเทียบค่าลับ ไม่ใช้การเทียบข้อความทั่วไปแทนโดยไม่อ่านเงื่อนไขของการเข้ารหัสกับรูปแบบ signature
Secret ต้องถูกจัดเก็บในระบบที่ควบคุมสิทธิ์และไม่ถูกคัดลอกไปอยู่ใน log หรือ response ที่ช่วย debug การพิมพ์ค่าที่คำนวณได้ทั้งหมดพร้อมข้อมูลลับอาจทำให้เครื่องมือตรวจกลายเป็นจุดเผยข้อมูลแทน
หากมีหลายโครงการหรือหลายบัญชีที่เชื่อม ต้องรู้ว่าการส่งนี้ผูกกับการตั้งค่าใด แล้วใช้ key กับขอบเขตที่ถูกต้อง ไม่ให้ request ระบุบัญชีใดก็ได้แล้วได้รับสิทธิ์เข้าถึงข้อมูลของบัญชีนั้นโดยยังไม่ยืนยันความสัมพันธ์
เมื่อเปลี่ยน key ต้องวางช่วงเปลี่ยนผ่านตามที่บริการรองรับ และมีวิธีปลด key เก่าออกเมื่อจบ ไม่เก็บทุกฉบับให้ตรวจผ่านต่อไปไม่จำกัด หาก key ถูกเปิดเผยก็ต้องจัดการตามเหตุการณ์นั้น การมี signature ไม่ได้ทำให้ key ที่หลุดยังเชื่อถือได้เท่าเดิม
Signature ยังไม่แทนการตรวจสิทธิ์ระดับงาน ข้อมูลจากผู้ส่งที่ยืนยันแล้วอาจมี event ที่ไม่เกี่ยวกับทรัพยากรที่ระบบนี้อนุญาตให้เปลี่ยน จึงต้องตรวจชนิดเหตุการณ์ บัญชี และรายการเป้าหมายก่อนเรียกขั้นสร้างผลต่อด้วย
ใน scheme ที่ลงนามเวลา ต้องตรวจตามความหมายของ field นั้นและ tolerance ที่ตั้งใจรองรับ ไม่รับ timestamp ที่ผู้ส่งทั่วไปใส่มาเองเป็นหลักฐานเพียงเพราะอยู่ใน JSON ที่ parser อ่านได้
Standard Webhooks แยกเวลา event เดิมจากเวลา attempt ของการนำส่ง ซึ่งเกี่ยวข้องกับ retry ที่เกิดภายหลัง หากใช้เวลาสร้างเหตุการณ์แทนเวลาส่งที่ scheme ต้องตรวจ ก็มีโอกาสปฏิเสธการ retry ที่ถูกต้องหรือเปิดช่องให้รับการส่งเก่าโดยไม่ตั้งใจ
นาฬิกาฝั่งรับจึงต้องพร้อมตามระดับที่วิธีตรวจต้องใช้ และควรเก็บเหตุผลการปฏิเสธแบบไม่เปิดข้อมูลลับให้คนภายนอก หาก provider ไม่มี scheme เวลาแบบนี้ ต้องใช้กลไกที่เอกสารของเขารองรับ ไม่เติมกติกาที่อีกฝั่งไม่ได้ส่งมาให้แล้วสรุปว่า webhook เสีย
การตรวจช่วงเวลาช่วยลดการนำส่งเก่ามาเล่นซ้ำตามขอบเขต แต่ไม่แทนการจัดการ event เดิมที่ถูกส่งหลายครั้งภายในช่วงเวลาที่ยังยอมรับ ทั้งสองเรื่องต้องวางแยกกัน
ผู้ส่งอาจ retry เมื่อไม่ได้รับคำตอบที่คาด หรือฝั่งรับหยุดหลังทำผลไปบางส่วน จึงควรใช้รหัสเหตุการณ์ตามข้อตกลงของผู้ให้บริการมาผูกกับสถานะประมวลผล ไม่สร้างรหัสใหม่ทุกครั้งจนตามไม่ได้ว่าเป็นเหตุการณ์เดียวกัน
การตรวจซ้ำต้องทนต่อหลาย worker รับพร้อมกันด้วย การค้นก่อนว่าเคยรับหรือยังแล้วค่อยสร้างโดยไม่มีกลไกบังคับเงื่อนไข อาจทำให้ทั้งสองรอบผ่านพร้อมกันได้ ต้องเลือกวิธีบันทึกกับ unique constraint หรือกลไกที่เหมาะกับระบบจริง
สถานะที่บันทึกก็ควรแยกว่ารับไว้แล้ว กำลังทำ สำเร็จ หรือรอตรวจผล หากทำเครื่องหมายเสร็จก่อนทำงานจริง พอระบบหยุดก็อาจมอง event ที่ยังไม่ครบว่าไม่ต้องทำต่อ ส่วนการทำก่อนบันทึกก็มีช่วงที่ผลเกิดแล้วแต่หลักฐานยังไม่ถูกเก็บ ต้องมีแผนกู้คืนตามนั้น
ในงานที่ต้องตอบรับเร็ว อาจตรวจแล้วบันทึกงานในระบบที่ทนต่อการหยุดก่อนส่งคำตอบรับ แล้วให้ worker ประมวลผลต่อ แต่ต้องนิยามว่าการตอบรับหมายถึงรับไว้สำเร็จ ไม่ใช่อ้างว่างานปลายทางเสร็จแล้วตั้งแต่ตอนนั้น
ใช้ fixture หรือเครื่องมือที่ provider รองรับกับ endpoint ทดสอบ ตรวจ payload ที่ถูกต้อง การเปลี่ยน body หลังลงนาม signature ผิด key และเหตุการณ์ส่งซ้ำ รวมถึงเวลานอกขอบเขตเมื่อ scheme มีการตรวจเวลา
ควรตรวจเส้นทางผ่าน middleware และ proxy ที่ใช้จริงในชุดทดสอบ เพราะการแปลง body ก่อนถึงตัวตรวจสามารถทำให้ผลต่างจากการเรียกฟังก์ชันด้วยข้อมูลดิบตรงๆ ได้ ไม่ยืนยันจาก unit ของขั้นคำนวณเพียงส่วนเดียวว่าทั้งเส้นทางรับถูกแล้ว
เก็บรหัส event เวลา attempt ผลตรวจ และสถานะงานที่จำเป็นต่อการตามปัญหา โดยไม่เปิด secret หรือ payload ส่วนตัวทั้งหมด บทนี้เป็นแนวทางจัดขอบเขต ยังไม่มีการส่ง webhook ไปยังบริการของผู้ใช้หรือเปลี่ยน key จริง
Webhook ที่นำไปใช้ต่อควรถูกตรวจตาม scheme ของผู้ส่งจากข้อมูลที่ลงนามจริง แล้วแยกการยืนยันที่มา การตรวจเวลา และการจัดการ event ซ้ำออกจากกัน เมื่อผูกกับสถานะประมวลผลที่กู้คืนได้ เราจะรับข่าวจากภายนอกโดยรู้ว่าผ่านหลักฐานใด และไม่เปลี่ยนทุกการนำส่งให้กลายเป็นผลธุรกิจใหม่โดยอัตโนมัติ