वेबहुक क्या है?
वेबहुक वह HTTP रिक्वेस्ट है जो कोई सर्विस आपके रजिस्टर किए URL पर किसी घटना पर भेजती है — भुगतान सेटल हुआ, मैसेज डिलीवर हुआ, बिल्ड पूरा हुआ — ताकि आपका सिस्टम पोलिंग के बजाय घटनाओं पर प्रतिक्रिया दे। इसे टेस्ट करने का मतलब है जो वास्तव में भेजा गया उसे कैप्चर करना (मेथड, हेडर, बॉडी), रिट्राई और क्रम जाँचना, और उस सिग्नेचर को सत्यापित करना जो साबित करता है कि कॉल भेजने वाले से ही आई है।
सुरक्षा नोट: वेबहुक एंडपॉइंट एक सार्वजनिक URL है जिस पर कोई भी पोस्ट कर सकता है। भेजने वाले के सिग्नेचर (आमतौर पर कच्ची बॉडी पर HMAC) को कॉन्स्टेंट-टाइम तुलना से सत्यापित करें, पुराने टाइमस्टैम्प अस्वीकार करें, और पेलोड को अविश्वसनीय इनपुट मानें।
गाइड पढ़ें: API टेस्टिंग क्या है? REST API कैसे टेस्ट करें
Webhook इंस्पेक्टर कैसे इस्तेमाल करें
- capture URL बनाएँ (या पहले वाला ही इस्तेमाल करें) और उस पर कोई webhook भेजें।
- डिलीवरी चुनें; Headers टैब डिफ़ॉल्ट रूप से खुलता है।
- Signature समूह और event का विवरण देखें, फिर Signature एनालाइज़र में signature सत्यापित करें।
- अपने हैंडलर को टेस्ट करने के लिए replay कमांड कॉपी करें।
Webhook इंस्पेक्टर की खूबियाँ
- हर कैप्चर की गई डिलीवरी का गहन व्यू: श्रेणीबद्ध हेडर (Signature, Provider, Content, Client, Network, Other)
- प्रोवाइडर, event टाइप, event id और signature scheme की पहचान
- tree व्यू, अहम फ़ील्ड और timestamp रूपांतरण के साथ डिकोड की गई JSON/form बॉडी
- कच्चा HTTP मैसेज व्यू और signature हेडर सुरक्षित रखते हुए cURL replay
- capture endpoint Webhook टेस्टर के साथ साझा होता है
Webhook इंस्पेक्टर का उदाहरण
GitHub की push डिलीवरी
इनपुट:
X-GitHub-Event: push · X-Hub-Signature-256: sha256=… · X-GitHub-Delivery: 72d3…आउटपुट:
Provider: GitHub (high confidence) · Event: push · Signature header: X-Hub-Signature-256 (GitHub scheme)
Signature: X-Hub-Signature-256 · Provider: X-GitHub-Event, X-GitHub-Delivery · Content: Content-Type, Content-LengthWebhook इंस्पेक्टर के बारे में अक्सर पूछे जाने वाले सवाल
कौन-से प्रोवाइडर पहचाने जाते हैं?
Stripe, GitHub, Shopify, Slack, Twilio, PayPal, GitLab, Bitbucket, SendGrid और Mailgun — उनके हेडर, user agent या payload की बनावट से; बाक़ी सबको सामान्य (generic) माना जाता है।
हेडर कैसे व्यवस्थित होते हैं?
उन्हें Signature, Provider, Content, Client, Network और Other में बाँटा जाता है, और हर एक को आसान भाषा में समझाया जाता है।
क्या मैं यहीं signature सत्यापित कर सकता हूँ?
इंस्पेक्टर signature हेडर और scheme दिखाता है; इसे लोकल रूप से सत्यापित करने के लिए कच्ची बॉडी और हेडर अपने secret के साथ Webhook सिग्नेचर एनालाइज़र में कॉपी करें।
कुछ हेडर वैल्यू क्यों नहीं दिखतीं?
Cookie, Set-Cookie और सभी cf-* हेडर कभी रिकॉर्ड नहीं होते। Authorization, API-key और credential जैसे दूसरे हेडर (जिनके नाम में token, secret, password या api-key हो) [redacted] वैल्यू के साथ दिखते हैं, ताकि credential ख़ुद कभी स्टोर न हो; signature हेडर बने रहते हैं। replay कमांड Host और Content-Length जैसे hop-by-hop हेडर भी छोड़ देता है।
संदर्भ
- RFC 9421: HTTP Message SignaturesHTTP मैसेज पर हस्ताक्षर करने का मानक तरीका ताकि रिसीवर उनके स्रोत और अखंडता की जाँच कर सके — आधुनिक वेबहुक सिग्नेचर का आधार।
- RFC 2104: HMAC: Keyed-Hashing for Message AuthenticationHMAC संरचना: एक सीक्रेट की और हैश फ़ंक्शन मिलकर मैसेज ऑथेंटिकेशन कोड कैसे बनाते हैं।
- OWASP Cheat Sheet Series: REST SecurityREST API के सुरक्षा नियम: HTTPS, हर रिक्वेस्ट पर ऑथेंटिकेशन, इनपुट वैलिडेशन, सुरक्षित एरर रिस्पॉन्स, रेट लिमिटिंग।