वेबहुक सिग्नेचर की जाँच और आम समस्याएँ

वेबहुक सिग्नेचर की जाँच कैसे काम करती है

वेबहुक सिग्नेचर इस बात का छोटा-सा प्रमाण होता है कि इवेंट पेमेंट प्रदाता से आया है, किसी अनजान POST अनुरोध से नहीं। प्रदाता साझा सीक्रेट या निजी कुंजी से पेलोड पर हस्ताक्षर करता है। फिर आपका ऐप इवेंट पर भरोसा करने से पहले उस सिग्नेचर की पुष्टि करता है। अगर आप सोच रहे हैं कि वेबहुक सिग्नेचर कैसे जांचें, तो मूल प्रक्रिया है प्रदाता द्वारा भेजे गए सटीक पेलोड और सही सीक्रेट से सिग्नेचर को वेरिफ़ाई करना। अगर सिग्नेचर अमान्य हो, तो सबसे सुरक्षित प्रतिक्रिया 401 या 400 देना और ऑर्डर अपडेट न करना है।

सुनने में यह आसान लगता है। लेकिन अक्सर होता नहीं है।

असल में, सिग्नेचर की जाँच आपको नकली इनवॉइस, फर्जी रिफंड और छेड़छाड़ किए गए ऐसे पेलोड से बचाती है जो पहली नज़र में असली लगते हैं। अगर कोई भी व्यक्ति “भुगतान पूरा हुआ” वाला वेबहुक गढ़ सकता है, तो उसका कोई भरोसा नहीं। ईकॉमर्स के लिए क्रिप्टो पेमेंट गेटवे गाइड का इस्तेमाल करने वाली टीमों के लिए, यह जाँच भुगतान स्वीकार करने और ऑर्डर पूरा करने के बीच होती है। इसलिए एक गलत धारणा पूरे कामकाज को रोक सकती है।

ज़्यादातर प्रदाता पूरे रॉ बॉडी, टाइमस्टैम्प या दोनों पर हस्ताक्षर करते हैं। कुछ HMAC-SHA256 इस्तेमाल करते हैं, जबकि दूसरे कई सिग्नेचर वैल्यू वाले वर्ज़नयुक्त हेडर भेजते हैं। ज़रा-सी भी गड़बड़ी काफी है। प्रदाता सही हो सकता है, फिर भी आपका ऐप इवेंट को अस्वीकार कर सकता है—अगर आपने एक बाइट भी बदली हो।

पहले पक्का करें कि समस्या वाकई सिग्नेचर से जुड़ी है

लॉग से 5 मिनट से भी कम समय में इसका जवाब मिल जाना चाहिए। अगर ऐसा नहीं है, तो उनमें पर्याप्त जानकारी नहीं है।

सबसे पहले, सटीक रिस्पॉन्स कोड और एरर टेक्स्ट देखें। “invalid signature” के साथ 400 आने का मतलब कुछ और है, जबकि 500 या टाइमआउट किसी दूसरी समस्या की ओर इशारा करता है। डिलीवरी में गड़बड़ी, गलत रूट, TLS एरर और प्रॉक्सी टाइमआउट डैशबोर्ड में वेबहुक की समस्या जैसे दिख सकते हैं, लेकिन ये एक ही समस्या नहीं हैं। अगर प्रदाता “delivered” दिखा रहा है और आपका एंडपॉइंट 200 लौटा रहा है, तो संभवतः सिग्नेचर वेरिफिकेशन गड़बड़ी की वजह नहीं है।

इन तीनों को एक साथ देखें: प्रदाता का डिलीवरी लॉग, आपके ऐप्लिकेशन का लॉग और—अगर आपके पास रिवर्स प्रॉक्सी है—उसका लॉग। जो अनुरोध आपके कोड तक पहुँचा ही नहीं, उसकी सिग्नेचर जाँच विफल नहीं हो सकती। जो अनुरोध आपके कोड तक पहुँचकर 401 लौटाता है, उसमें आम तौर पर सिग्नेचर की समस्या हो सकती है। एक बात ध्यान रखें: अगर लॉग में इवेंट दिख रहा है, लेकिन सिग्नेचर एरर नहीं है, तो हो सकता है कि आपका कोड वेरिफिकेशन के बाद पेलोड को अस्वीकार कर रहा हो।

सीधी बात: कोड बदलने से पहले समस्या की पुष्टि करें।

शेयर्ड सीक्रेट या साइनिंग की जाँचें

यह सबसे आम गलती है—और इतनी मामूली लगती है कि खतरनाक बन जाती है। आपके ऐप्लिकेशन में मौजूद वेबहुक सीक्रेट, पेमेंट डैशबोर्ड के मौजूदा सीक्रेट से हूबहू मेल खाना चाहिए। टेक्स्ट फ़ील्ड से कॉपी करते समय आए छिपे स्पेस भी इसमें शामिल हैं। अगर प्रदाता ने पिछले मंगलवार को सीक्रेट बदला था, तो किसी के अपडेट करने तक पुरानी कुंजी आपके एनवायरनमेंट में बनी रहेगी।

डैशबोर्ड वाले सीक्रेट की तुलना अपने डिप्लॉयमेंट एनवायरनमेंट के सीक्रेट से करें, सिर्फ़ अपने लैपटॉप वाले से नहीं। प्रोडक्शन, स्टेजिंग और लोकल डेवलपमेंट—तीनों के लिए अलग-अलग वैल्यू होनी चाहिए। अगर कोई टीम टेस्ट सीक्रेट को प्रोडक्शन में कॉपी कर देती है, तो एक कॉपी-पेस्ट की गई स्ट्रिंग के कारण सिग्नेचर की समस्या ढूँढ़ने में 2 घंटे लग सकते हैं। लॉन्च के समय और एक प्रोसेसर से दूसरे पर माइग्रेट करते वक्त ऐसी दिक्कत आम है। ईकॉमर्स के लिए क्रिप्टो पेमेंट गेटवे गाइड इस्तेमाल करने वाली टीमों को अक्सर नई चेकआउट रिलीज़ के ठीक बाद सीक्रेट में गड़बड़ी दिखती है।

पुरानी कुंजियाँ तभी रखें, जब प्रदाता कुछ समय तक दोनों कुंजियाँ मान्य रखकर की रोटेशन की सुविधा देता हो। अगर कुछ समय के लिए पुरानी और नई—दोनों कुंजियाँ मान्य हैं, तो आपका वेरिफ़ायर पहले सक्रिय कुंजी और फिर पिछली कुंजी आज़माए। अगर प्रदाता यह सुविधा नहीं देता, तो हर एनवायरनमेंट से पुरानी कुंजी हटा दें। अंदाज़ा न लगाएँ।

रॉ रिक्वेस्ट बॉडी को ठीक उसी रूप में दोबारा तैयार करें

यहीं कई अच्छे इम्प्लीमेंटेशन भी नाकाम हो जाते हैं। सिग्नेचर की जाँच आम तौर पर प्रदाता के भेजे गए सटीक रॉ बाइट्स पर निर्भर करती है, न कि आपके फ़्रेमवर्क द्वारा पार्स करने के बाद बने JSON ऑब्जेक्ट पर। यही वजह है कि यह जानना ज़रूरी है कि वेबहुक के लिए रॉ रिक्वेस्ट बॉडी कैसे सुरक्षित रखें: अगर आपका कोड संख्याओं को बदलता है, फ़ील्ड का क्रम बदलता है, खाली जगह हटाता है या लाइन एंडिंग को सामान्य रूप में बदलता है, तो पेलोड देखने में “एक जैसा” होने पर भी कंप्यूट किया गया सिग्नेचर बदल सकता है।

कुछ फ़्रेमवर्क बॉडी को एक बार पढ़कर मूल स्ट्रीम हटा देते हैं। कुछ में आपका मिडलवेयर चलने से पहले ही JSON अपने-आप पार्स हो जाता है। ऐसे में वेरिफ़ायर को रॉ बॉडी नहीं, बल्कि दोबारा बनाया गया ऑब्जेक्ट मिलता है। आम तौर पर इसका हल यह है कि पहले बिना छेड़ी गई पेलोड को कैप्चर करें और फिर उसी बफ़र को सिग्नेचर वेरिफिकेशन फ़ंक्शन में दें। फ़्रेमवर्क की एक सेटिंग तय कर सकती है कि बॉडी जस की तस रहेगी या बदल दी जाएगी।

मिसाल के तौर पर, 14 फ़ील्ड वाला पेलोड तय बाइट क्रम में आ सकता है, लेकिन अगर पार्सर कीज़ को क्रम में लगा दे, तो आपका कोड वह क्रम कभी देख ही नहीं पाएगा। आखिर में लगा न्यूलाइन भी मायने रख सकता है। UTF-8 में एक बार कन्वर्ज़न करने से भी फर्क पड़ सकता है। हाँ, एक अदृश्य कैरेक्टर पूरी जाँच को विफल कर सकता है।

अगर आपका टेक स्टैक इसकी सुविधा देता है, तो पार्स करने से पहले बॉडी की लंबाई और रॉ रिक्वेस्ट बॉडी का हैश लॉग करें। सीक्रेट लॉग न करें। स्ट्रीम पढ़ने वाले कोड पाथ को ज़रूर लॉग करें। इससे यह पता लगाना बहुत आसान हो जाता है कि क्रिप्टो पेमेंट की जाँच कैसे करें, यह कभी Postman में पास तो होता है, लेकिन असली प्रदाता वेबहुक के साथ विफल क्यों होता है।

टाइमस्टैम्प, घड़ी का सिंक और रीप्ले सुरक्षा जाँचें

कई वेबहुक स्कीम में टाइमस्टैम्प होता है, ताकि पुराने इवेंट को बाद में दोबारा भेजकर इस्तेमाल न किया जा सके। अगर टाइमस्टैम्प तय समय-सीमा से बाहर हो—अक्सर 5 मिनट या प्रदाता की तय की गई कोई दूसरी सीमा—तो आपका वेरिफ़ायर अनुरोध को अस्वीकार कर सकता है। इससे रीप्ले अटैक से सुरक्षा मिलती है, लेकिन इसका मतलब यह भी है कि आपके सर्वर की घड़ी सही होनी चाहिए।

वेबहुक संभालने वाले हर सर्वर की सिस्टम घड़ी जाँचें। अगर घड़ी 3 मिनट भी आगे-पीछे है, तो पेलोड सही होने पर भी सिग्नेचर विफल हो सकता है। अगर सर्वर कंटेनर में चलता है, तो होस्ट का समय भी जाँचें। वेरिफिकेशन का फ़ैसला करने वाली मशीन पर NTP या कोई दूसरी टाइम-सिंक सेवा चालू होनी चाहिए। 10 मिनट का अंतर रखने वाला सर्वर सही वेबहुक को भी गलत तरीके से विफल कर सकता है।

यहाँ रीप्ले सुरक्षा भी मायने रखती है। अगर आपका कोड पहले देखे गए सिग्नेचर या इवेंट ID कैश करता है, तो सुनिश्चित करें कि कैश का TTL प्रदाता की अपेक्षित रीप्ले अवधि से मेल खाता हो। कैश में बची पुरानी एंट्री किसी सही दोबारा डिलीवर हुए इवेंट को अस्वीकार कर सकती है। प्रदाता की ओर से एक रीट्राई और दुर्भावनापूर्ण रीप्ले—दो अलग बातें हैं, इसलिए कोड को दोनों समझने चाहिए। यह छोटी-सी बात बड़े नतीजे ला सकती है।

सुनिश्चित करें कि सिग्नेचर हेडर सही तरह पार्स हो रहा है

सभी सिग्नेचर हेडर एक जैसे नहीं होते। कुछ प्रदाता एक हैश वाला हेडर भेजते हैं, जबकि दूसरे कॉमा से अलग किए गए की-वैल्यू पेयर, वर्ज़न लेबल और टाइमस्टैम्प भेजते हैं। आपका पार्सर ठीक उसी फ़ॉर्मैट के मुताबिक होना चाहिए। अगर वह v1= की अपेक्षा करता है, लेकिन प्रदाता t= और कई वर्ज़न भेजता है, तो क्रिप्टोग्राफ़ी शुरू होने से पहले ही जाँच विफल हो जाएगी।

स्पेस हटाने की गलती से बचें। शुरुआत या आखिर के स्पेस भी मायने रखते हैं। इसी तरह, अगर फ़्रेमवर्क हेडर को UTF-8 के बजाय Latin-1 के रूप में डिकोड करता है, तो एन्कोडिंग से जुड़ी गड़बड़ी हो सकती है। एनवायरनमेंट वेरिएबल में गलती से जुड़ा न्यूलाइन तुलना विफल कर सकता है। जब तक प्रदाता इसकी अनुमति न दे, हेडर को सामान्य रूप में न बदलें। जिस वैल्यू को बाइनरी-सेफ़ रहना चाहिए, उसे लोअरकेस में न बदलें। इन दो बातों से ज़रूरत से ज़्यादा परेशानी होती है।

एक से ज़्यादा स्कीम होने पर भी सावधानी से काम लें। कुछ प्रदाता बदलाव की अवधि के दौरान मौजूदा और पिछला—दोनों सिग्नेचर देते हैं। आपके वेरिफ़ायर को पता होना चाहिए कि वह कौन-सा वर्ज़न इस्तेमाल कर रहा है और अनजान वर्ज़न को सही तरीके से अस्वीकार करना चाहिए। अगर हेडर में टाइमस्टैम्प और सिग्नेचर दोनों हैं, तो दोनों की पुष्टि करें। अगर प्रदाता ने साइनिंग प्रीफ़िक्स के बारे में बताया है, तो उसे ठीक उसी तरह इस्तेमाल करें। सुरक्षित वेबहुक हैंडलिंग के बारे में और जानने के लिए क्रिप्टो पेमेंट सुरक्षा के बेहतरीन तरीके देखें।

पहले से सत्यापित वेबहुक इवेंट से जाँच करें

सही-सलामत इवेंट से समय बचता है। प्रदाता के डैशबोर्ड से कोई इवेंट दोबारा भेजें या दस्तावेज़ में दिया गया सैंपल पेलोड इस्तेमाल करें। फिर अपेक्षित सिग्नेचर की तुलना अपने कोड से कंप्यूट किए गए सिग्नेचर से करें। अगर सैंपल वेरिफ़ाई हो जाता है, लेकिन लाइव ट्रैफ़िक नहीं, तो समस्या शायद कॉन्फ़िगरेशन, एनवायरनमेंट या सीक्रेट रोटेशन में है। अगर दोनों वेरिफ़ाई नहीं होते, तो कोड पाथ गलत है।

एक इवेंट ID और एक टाइमस्टैम्प इस्तेमाल करें। फिर चार चीज़ों की तुलना करें: रॉ बॉडी, हेडर वैल्यू, सीक्रेट और घड़ी। ज़्यादातर समस्याओं की जड़ तक पहुँचने के लिए इतना काफी है। लोकल फ़ाइल में कॉपी किए गए टेस्ट पेलोड में ऐसी फ़ॉर्मैटिंग हो सकती है जो आपके असली एंडपॉइंट तक कभी पहुँचती ही नहीं। इसलिए, अगर प्रदाता का री-सेंड टूल उपलब्ध हो, तो हमेशा उसी को प्राथमिकता दें। 20 अंदाज़े लगाने से बेहतर है एक बार फिर से भेजना।

अगर प्रदाता सिग्नेचर कैलकुलेटर देता है, तो उसी पेलोड को उसमें जाँचें। अगर आपके आउटपुट में एक कैरेक्टर का भी फर्क है, तो समस्या पार्सिंग या बॉडी को जस का तस रखने में है। अगर आउटपुट मेल खाता है, लेकिन प्रदाता फिर भी अनुरोध अस्वीकार करता है, तो सीक्रेट या हेडर पार्सिंग में गड़बड़ी है। इससे पता चल जाता है कि आगे कहाँ देखना है।

यही वह समय भी है जब स्टेजिंग और प्रोडक्शन को साफ़ तौर पर अलग रखना चाहिए। प्रोडक्शन सीक्रेट के साथ भेजा गया स्टेजिंग इवेंट हर बार विफल होगा। एनवायरनमेंट लेबल देखने तक यह विफलता टूटी हुई सिग्नेचर जाँच जैसी ही लगेगी।

वेबहुक एंडपॉइंट को सुरक्षित और निगरानी में रखें

सिग्नेचर की जाँच काम करने लगे, तो उसे लगातार सही बनाए रखें। इवेंट ID, वेरिफिकेशन का नतीजा, प्रदाता का नाम और एनवायरनमेंट का नाम लॉग करें। पूरा सीक्रेट लॉग न करें। अगर रॉ बॉडी में ग्राहक का संवेदनशील डेटा है, तो उसे भी पूरा लॉग न करें। ऑपरेटरों के लिए छोटा और आसानी से समझ आने वाला एरर मैसेज रखें और प्रदाता को सीधा अस्वीकार जवाब दें।

वेबहुक सीक्रेट तय समय पर बदलें और बदलाव की प्रक्रिया दर्ज करें। दो चरणों में की गई रोटेशन ज़्यादा सुरक्षित है: नई कुंजी जोड़ें, ओवरलैप की सुविधा हो तो दोनों कुंजियों के काम करने की पुष्टि करें, फिर पुरानी कुंजी हटाएँ। टेस्ट और प्रोडक्शन एंडपॉइंट अलग रखें, ताकि स्टेजिंग की गलती से लाइव ऑर्डर प्रभावित न हों। यह बात साफ़ लगती है, फिर भी टीमें अक्सर इन्हें मिला देती हैं।

सिग्नेचर की कई विफलताओं पर अलर्ट दें, किसी एक विफल प्रयास पर नहीं। एक विफलता खराब रीट्राई हो सकती है। 1 मिनट में पाँच विफलताएँ ध्यान देने लायक हैं। अलर्ट में रूट, प्रदाता और रिस्पॉन्स कोड शामिल करें, ताकि ऑन-कॉल व्यक्ति समझ सके कि समस्या सीक्रेट के मेल न खाने, पार्सर की गड़बड़ी या घड़ी में है। अगर आप अभी एंडपॉइंट सेट अप कर रहे हैं, तो क्रिप्टो पेमेंट कैसे सेट अप करें वाला लेख शुरुआत से ही वेबहुक पाथ को आसान रखने में मदद कर सकता है।

आखिरी बात: विफल क्रिप्टो पेमेंट वेबहुक सिग्नेचर को ठीक करने के सटीक चरणों वाली एक छोटी रनबुक रखें। उसमें यह भी लिखें कि सीक्रेट कहाँ है, किसी इवेंट को दोबारा कैसे भेजना है और कौन-सी लॉग लाइन वेरिफिकेशन की पुष्टि करती है। 10 लाइन की रनबुक रात के 2 बजे आपका एक घंटा बचा सकती है।