सार्वजनिक रिसीविंग URL पर कोई भी अनुरोध भेज सकता है। हमलावर उस URL पर नकली इवेंट भेज सकता है, इसलिए किसी काम को शुरू करने से पहले अनुरोध का प्रमाणीकरण ज़रूरी है।
Bird Standard Webhooks साइनिंग स्कीम का उपयोग करता है। यह बॉडी के साथ-साथ इवेंट पहचानकर्ता और प्रयास के समय को भी प्रमाणित करता है, इसलिए इनमें से किसी को भी बदलने पर सिग्नेचर अमान्य हो जाता है।
Bird किन चीज़ों पर सिग्नेचर करता है?
Bird इवेंट पहचानकर्ता, डिलीवरी प्रयास के टाइमस्टैम्प और रॉ अनुरोध बॉडी को पूर्ण विराम (period) से जोड़कर उस पर सिग्नेचर करता है।
सिग्नेचर सत्यापित करने तक अनुरोध बॉडी को अपरिवर्तित रखें। JSON को पार्स और फिर से सीरियलाइज़ करने पर वे बाइट बदल सकते हैं जिन पर Bird ने सिग्नेचर किया था।
| हेडर | इसमें क्या होता है |
|---|---|
webhook-id | इवेंट पहचानकर्ता, जो फिर से प्रयास और रीप्ले में वही रहता है। |
webhook-timestamp | प्रयास का समय, सेकंड में Unix टाइमस्टैम्प के रूप में। |
webhook-signature | एक या अधिक सिग्नेचर, स्पेस से अलग किए हुए। हर सिग्नेचर v1, से शुरू होता है। |
मिलीसेकंड में समय बताने वाली घड़ी से तुलना करने से पहले टाइमस्टैम्प को सेकंड से बदल लें।
कुंजी के बाइट वापस पाने के लिए अपने एंडपॉइंट सीक्रेट से whsec_ प्रीफ़िक्स हटाएँ और बचे हुए हिस्से को base64 से डिकोड करें।
पहचानकर्ता, टाइमस्टैम्प और बिना बदली बॉडी को पीरियड से जोड़ें। डिकोड की गई कुंजी से उस स्ट्रिंग पर HMAC-SHA256 की गणना करें। परिणाम की तुलना हर दिए गए सिग्नेचर से कॉन्स्टेंट-टाइम तुलना से करें, जिसमें लगने वाला समय यह नहीं बताता कि कौन-से बाइट मेल खाते हैं।
मेरा सिग्नेचर कभी मेल क्यों नहीं खाता?
गलत सीक्रेट या बदली हुई अनुरोध बॉडी के कारण हर सिग्नेचर जाँच विफल हो सकती है।
वेब फ़्रेमवर्क अक्सर आपके हैंडलर के चलने से पहले ही JSON को पार्स कर देते हैं। उस ऑब्जेक्ट को फिर से सीरियलाइज़ करने पर व्हाइटस्पेस, कुंजियों का क्रम या संख्याओं का फ़ॉर्मैट बदल सकता है। तब बनने वाले JSON का अर्थ वही रह सकता है, फिर भी उसका सिग्नेचर अलग बनता है।
इस रूट को इस तरह कॉन्फ़िगर करें कि उसकी रॉ बॉडी सुरक्षित रहे। जाँचें कि सीक्रेट इसी एंडपॉइंट का है, खासकर डिप्लॉयमेंट या रोटेशन के बाद।
मेरे हैंडलर को किन अनुरोधों को अस्वीकार करना चाहिए?
जब कोई सिग्नेचर मेल न खाए या साइन किया गया टाइमस्टैम्प अनुमत समय सीमा से बाहर हो, तो अनुरोध अस्वीकार करें।
webhook-signature में हर सिग्नेचर आज़माएँ। सीक्रेट रोटेशन के दौरान एक डिलीवरी में कई मान्य सीक्रेट के सिग्नेचर होते हैं। किसी भी मेल खाते सिग्नेचर को स्वीकार करने से दोनों में से किसी भी सीक्रेट का उपयोग करने वाले रिसीवर काम करते रहते हैं।
अपनी घड़ी के दोनों ओर पाँच मिनट की टाइमस्टैम्प छूट रखें। तब दस मिनट पहले पकड़ा गया अनुरोध विफल हो जाता है, भले ही उसका सिग्नेचर न बदला हो। अपने सर्वर की घड़ी सटीक रखें, ताकि वह असली डिलीवरी अस्वीकार न करे।
webhook-id को पहले से संग्रहीत इवेंट से मिलाकर जाँचें। पहचाने गए डुप्लिकेट को उसका काम दोहराए बिना सफलता लौटाएँ, क्योंकि उसी डिलीवरी के लिए फिर से प्रयास करने से कोई नया इवेंट नहीं जुड़ता।
अगर मैं किसी डिलीवरी को अस्वीकार करूँ तो क्या होता है?
जिस डिलीवरी को त्रुटि प्रतिक्रिया मिलती है या टाइमआउट से पहले कोई प्रतिक्रिया नहीं मिलती, उसके लिए Bird फिर से प्रयास करता है।
उदाहरण के लिए, 400 प्रतिक्रिया अस्वीकृति दर्ज करती है और डिलीवरी को फिर से प्रयास के योग्य छोड़ देती है। 2xx के अलावा सभी प्रतिक्रियाओं पर फिर से प्रयास की नीति लागू होती है। यह कोड आपके लॉग में विफलता का कारण पता करने में मदद करता है।
समायोजन से पहले यह शेड्यूल लगभग 27.5 घंटे का होता है, जिससे आपको गलत सीक्रेट ठीक करने का समय मिलता है। विफल वेबहुक के लिए फिर से प्रयास में शेड्यूल और बाद में विफल डिलीवरी को रीप्ले करने का तरीका बताया गया है।
2xx तभी लौटाएँ जब आप इवेंट को सत्यापित करके सुरक्षित रूप से संग्रहीत कर चुके हों, या पहले से संग्रहीत डुप्लिकेट को पहचान चुके हों। रीप्ले के दौरान Bird सफल डिलीवरी को छोड़ देता है, इसलिए किसी असत्यापित अनुरोध को स्वीकार करने पर उस तरीके से रिकवरी नहीं हो पाती।
क्या मुझे सत्यापन खुद लागू करना होगा?
अगर आप Bird SDK में webhooks.unwrap का उपयोग करते हैं, तो आपको सत्यापन खुद लागू करने की ज़रूरत नहीं है। उसे रॉ बॉडी और अनुरोध हेडर दें।
यह हेल्पर डिकोड किया गया इवेंट लौटाने से पहले सिग्नेचर और टाइमस्टैम्प जाँचता है। फिर भी आपका एप्लिकेशन webhook-id के आधार पर डुप्लिकेट हटाता है, क्योंकि पूरे हो चुके काम का रिकॉर्ड उसी के पास होता है।
कोई संगत Standard Webhooks सत्यापन लाइब्रेरी भी यही जाँच कर सकती है। वेबहुक गाइड में उदाहरण और मैन्युअल कार्यान्वयन दिए गए हैं।
संक्षेप में
मूल बाइट्स का सत्यापन करें।
JSON को पार्स और फिर से सीरियलाइज़ करने पर वे बाइट्स बदल सकते हैं जिन्हें Bird ने साइन किया था। सत्यापन के लिए रॉ बॉडी को सुरक्षित रखें।
सिग्नेचर के साथ समय भी जाँचें।
पाँच मिनट की टाइमस्टैम्प सहनशीलता पकड़े गए अनुरोधों के दोबारा इस्तेमाल को सीमित करती है। संग्रहीत इवेंट्स के डुप्लिकेट webhook-id के आधार पर अलग से हटाएँ।
दिया गया हर सिग्नेचर आज़माएँ।
रोटेशन के दौरान कई सिग्नेचर एक साथ मान्य रहते हैं। किसी भी मान्य सिग्नेचर से मेल होने पर डिप्लॉयमेंट काम करता रहता है।
केवल सत्यापित और संग्रहीत इवेंट्स की पुष्टि करें।
Bird non-2xx प्रतिक्रियाओं पर फिर से प्रयास करता है और रीप्ले के दौरान सफल डिलीवरी छोड़ देता है। पहले से संग्रहीत डुप्लिकेट के लिए उनका काम दोहराए बिना सफलता लौटाएँ।