डेवलपर टूल · UUID जनरेटर
इडेम्पोटेंसी कुंजियाँ: पुनर्प्रयासों को सुरक्षित बनाने के लिए क्लाइंट-जनरेटेड UUID का उपयोग करना
· यह क्यों मायने रखती है
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
भुगतान अनुरोध पर समय समाप्त होने से आप अनिश्चित हो जाते हैं कि यह पूरा हुआ या नहीं। इडेम्पोटेंसी कुंजियाँ आपको सुरक्षित रूप से पुनः प्रयास करने देती हैं, और CSPRNG-जनित UUID प्राकृतिक कुंजी है। यह पोस्ट पैटर्न को शुरू से अंत तक समझाती है।
वह टाइमआउट जिसके लिए ग्राहक से दो बार शुल्क लिया जा सकता है - विफलता मोड निष्क्रियता कुंजियाँ ठीक करने के लिए मौजूद हैं
भुगतान अनुरोध के दौरान टाइमआउट ग्राहक और सिस्टम के लिए वास्तविक अनिश्चितता पैदा करता है। आपके HTTP क्लाइंट ने प्रतिक्रिया की प्रतीक्षा करना छोड़ दिया है, लेकिन भुगतान सर्वर ने कनेक्शन बंद होने या समय समाप्त होने से पहले लेनदेन संसाधित कर लिया होगा। यदि आप वही अनुरोध पुनः प्रयास करते हैं, तो आप ग्राहक से दोगुना शुल्क ले सकते हैं। यदि आप पुनः प्रयास नहीं करते हैं, तो भुगतान कभी पूरा नहीं होगा। भुगतान प्रणाली एक दुखद मध्य स्थिति में विफल हो जाती है: ग्राहक का पैसा चला गया हो सकता है, कल आ सकता है, प्रसंस्करण कतार में फंस सकता है, या खाता बिल्कुल भी नहीं छोड़ा हो सकता है। यह अस्पष्टता वित्तीय प्रणालियों के लिए अस्वीकार्य है।
इडेम्पोटेंसी कुंजियाँ कैसे काम करती हैं - सर्वर पहली प्रतिक्रिया को कुंजी के नीचे संग्रहीत करता है और इसे दोहराव के लिए पुनः चलाता है
इडेम्पोटेंसी कुंजियाँ पुनर्प्रयासों को सुरक्षित और नियतिवादी बनाकर इस समस्या को सुरुचिपूर्ण ढंग से हल करती हैं। ग्राहक प्रत्येक इरादे के लिए एक अद्वितीय कुंजी उत्पन्न करता है - एक भुगतान, एक हस्तांतरण, एक शुल्क - और इसे हर अनुरोध में शामिल करता है। सर्वर भुगतान संसाधित करता है, उस कुंजी के तहत प्रतिक्रिया को कैश करता है और कुंजी और परिणाम दोनों को संग्रहीत करता है। यदि वही कुंजी रिटेंशन विंडो के भीतर दोबारा आती है, तो सर्वर भुगतान को दोबारा संसाधित किए बिना कैश्ड प्रतिक्रिया को दोबारा चलाता है। ग्राहक यह जानकर विश्वासपूर्वक पुनः प्रयास कर सकता है कि एक ही कुंजी हमेशा एक ही परिणाम देगी, चाहे इसे कितनी भी बार भेजा गया हो। यह पैटर्न अस्पष्टता को समाप्त करता है और पुनः प्रयास तर्क को सुरक्षित बनाता है।
पहले प्रयास से पहले उत्पन्न करें - अनुरोध समाप्त होने से पहले कुंजी क्यों मौजूद होनी चाहिए और पुनः प्रयास करने पर शब्दशः पुन: उपयोग की जानी चाहिए
यह पैटर्न आधुनिक HTTP विशिष्टताओं से पुराना है, लेकिन बड़े पैमाने पर वित्तीय घाटे और डुप्लिकेट शुल्कों से ग्राहकों की शिकायतों के बाद भुगतान में इसे प्रमुखता मिली। प्रत्येक भुगतान API और कई वेब सेवा API अब idempotency कुंजियों का समर्थन करते हैं। CSPRNG-जनित UUID कुंजी के लिए स्वाभाविक पसंद है क्योंकि यह ग्राहकों के बीच किसी भी समन्वय के बिना अद्वितीय, अद्वितीय है और इसके लिए सर्वर-साइड आवंटन या केंद्रीय प्राधिकरण की आवश्यकता नहीं है। क्लाइंट इसे पहले प्रयास से पहले उत्पन्न करता है, प्रत्येक पुनः प्रयास पर इसे शब्दशः पुन: उपयोग करता है और हर बार एक ही प्रतिक्रिया प्राप्त करता है। कुंजी पीढ़ी के समन्वय के लिए किसी सर्वर-साइड स्थिति की आवश्यकता नहीं है।
क्यों एक यादृच्छिक UUID और काउंटर या पेलोड हैश नहीं - समन्वय के बिना विशिष्टता और इरादों में कोई आकस्मिक पुन: उपयोग नहीं
अनुरोध क्लाइंट को छोड़ने से पहले कुंजी मौजूद होनी चाहिए क्योंकि पुन: प्रयास पर इसे उत्पन्न करने में निष्क्रियता सुनिश्चित करने के लिए बहुत देर हो चुकी है। यदि पहला अनुरोध सफल हो जाता है और ग्राहक से शुल्क लिया जाता है, तो पुनः प्रयास करने पर एक नई कुंजी उत्पन्न करने से समस्या छिप जाएगी और फिर से शुल्क लगेगा। क्लाइंट को पहले प्रयास से पहले एक कुंजी के लिए प्रतिबद्ध होना होगा, इसे मेमोरी या लगातार स्टोरेज में संग्रहीत करना होगा, और यदि टाइमआउट या पुनः प्रयास आवश्यक हो जाता है तो उसी कुंजी का पुन: उपयोग करना होगा। मैन्युअल API परीक्षण के लिए, ToolAcre जनरेटर कुंजियाँ उत्पन्न करता है जिन्हें आप कर्ल या REST क्लाइंट में पेस्ट कर सकते हैं, कॉपी कर सकते हैं और निष्क्रिय व्यवहार का परीक्षण करने के लिए कई अनुरोधों में पुन: उपयोग कर सकते हैं।
दायरा और जीवनकाल - प्रति ऑपरेशन, प्रति खाता कुंजी, और सर्वर को उन्हें कितनी देर तक याद रखना चाहिए
इडेम्पोटेंसी कुंजियों के लिए हैश या अनुक्रमिक काउंटर के बजाय UUID क्यों? अनुरोध पेलोड का हैश सहज लगता है—समान पेलोड को समान हैश और इस प्रकार समान कुंजियाँ मिलती हैं। लेकिन इस उपयोग के मामले में हैश कमजोर हैं क्योंकि अलग-अलग मात्रा, अलग-अलग प्राप्तकर्ता या अलग-अलग मापदंडों के साथ दो लगभग समान अनुरोध पूरी तरह से अलग-अलग हैश उत्पन्न करते हैं और इस प्रकार अलग-अलग शुल्क उत्पन्न करते हैं, जो सही है लेकिन सभी आवश्यक सुरक्षा प्रदान नहीं करता है। अनुक्रमिक काउंटर के लिए समन्वय और वितरित स्थिति की आवश्यकता होती है: यदि दो ग्राहक आपके बुनियादी ढांचे पर काउंटर-आधारित कुंजी उत्पन्न करते हैं, तो उनके काउंटर टकरा सकते हैं। UUID के लिए किसी केंद्रीय प्राधिकरण की आवश्यकता नहीं है, यह अकल्पनीय है और पूरे इंटरनेट पर हर समय संयोग से टकराने की अत्यधिक संभावना नहीं है।
कार्यान्वित उदाहरण - एक ही कुंजी के साथ एक पुनः प्रयास अनुक्रम, जो दिखाता है कि क्लाइंट क्या भेजता है और सर्वर हर बार क्या लौटाता है
सर्वर-साइड कार्यान्वयन प्रतिक्रियाओं को कुंजियों के अंतर्गत संग्रहीत करता है और दोहराव पर कैश्ड प्रतिक्रियाएँ लौटाता है। व्यावहारिक परिचालन प्रश्नों को तय करने में जटिलता है: प्रतिधारण अवधि, एक कुंजी को कितने समय तक याद रखना है, कैश का आकार, कितनी कुंजियों को याद रखना है, लॉक करना, एक ही कुंजी के साथ दो समवर्ती अनुरोधों को दो बार भुगतान संसाधित करने से कैसे रोकना है और एक कुंजी को भूलने पर सफाई करना। ये UUID जनरेटर के दायरे से बाहर भंडारण और विश्वसनीयता के प्रश्न हैं। ग्राहक का काम एक अच्छी कुंजी उत्पन्न करना और पुनः प्रयास पर उसका पुन: उपयोग करना है; सर्वर का काम कैश को सही और टिकाऊ ढंग से लागू करना है।
इसमें क्या शामिल नहीं है - पैटर्न को लागू करने के लिए आवश्यक सर्वर-साइड स्टोरेज और लॉकिंग, जो एक अलग डिज़ाइन है
एक कार्यशील उदाहरण व्यवहार में एक विशिष्ट अनुक्रम दिखाता है। एक मोबाइल ऐप को API का उपयोग करके किसी मित्र को धन हस्तांतरित करने की आवश्यकता होती है जो निष्क्रियता का समर्थन करता है। अनुरोध भेजने से पहले, ऐप अपनी स्थानीय क्रिप्टो लाइब्रेरी का उपयोग करके UUID उत्पन्न करता है या परीक्षण उद्देश्यों के लिए ToolAcre जनरेटर से एक प्राप्त करता है: 3fa85f64-5717-4562-b3fc-2c963f66afa6। ऐप JSON बॉडी और HTTP हेडर Idempotency-Key: 3fa85f64-5717-4562-b3fc-2c963f66afa6 के साथ /transfers को POST अनुरोध भेजता है। सर्वर स्थानांतरण की प्रक्रिया करता है, 3fa85f64-5717-4562-b3fc-2c963f66afa6 → {स्थिति: "सफलता", ट्रांसफरID: "xfer-12345"} को अपने कैश में संग्रहीत करता है और परिणाम के साथ 200 प्रतिक्रिया देता है।
टेकवे: एक इरादा, एक कुंजी - ToolAcre जनरेटर आपको हाथ से एकीकरण का परीक्षण करते समय कुंजी के रूप में उपयोग करने के लिए CSPRNG-समर्थित UUID देता है
नेटवर्क का समय समाप्त हो गया है और क्लाइंट को पहले प्रयास से प्रतिक्रिया नहीं दिख रही है। ऐप कोई नया UUID उत्पन्न किए बिना उसी अनुरोध को उसी idempotency कुंजी के साथ पुनः प्रयास करता है। सर्वर अपने कैश में कुंजी को पहचानता है, कैश्ड प्रतिक्रिया पाता है और बिना कोई नया ट्रांसफर संसाधित किए और ग्राहक से दोबारा शुल्क लिए बिना तुरंत {स्थिति: "सफलता", ट्रांसफरID: "xfer-12345"} लौटाता है। ऑपरेशन निरर्थक है: पुनः प्रयास करने से हर बार एक ही देखने योग्य परिणाम मिलता है। एक कार्यशील परीक्षण के लिए, ToolAcre जनरेटर कुंजी प्रदान कर सकता है; एक UUID उत्पन्न करें, इसे हेडर में शामिल करें, प्रतिक्रिया का निरीक्षण करें और सर्वर द्वारा कैशिंग को सही ढंग से लागू करने की पुष्टि करने के लिए उसी कुंजी के साथ पुनः भेजें।