डेटाबेस सत्र टोकन पर जेएसओएन वेब टोकन (जेडब्ल्यूटी) लाभ

Question

डेटाबेस सत्र टोकन सिस्टम के साथ मैं उपयोगकर्ता नाम/पासवर्ड के साथ एक उपयोगकर्ता लॉगिन कर सकता हूं, सर्वर एक टोकन उत्पन्न कर सकता है (उदाहरण के लिए एक यूयूआईडी) और इसे स्टोर में डेटाबेस और क्लाइंट को टोकन वापस कर दें। उसमें से प्रत्येक अनुरोध में टोकन शामिल होगा और सर्वर यह देखेगा कि टोकन मान्य है या नहीं और यह किस उपयोगकर्ता से संबंधित है।

जेडब्ल्यूटी का उपयोग करना सर्वर पर रखी गई गुप्त कुंजी के संयोजन के लिए सत्र/टोकन के संबंध में डेटाबेस में कुछ भी सहेजने की आवश्यकता नहीं होगी और क्लाइंट द्वारा हस्ताक्षरित टोकन रखता है और प्रत्येक अनुरोध के साथ भेजता है।

यह अच्छा है लेकिन डाटाबेस को सहेजने के अलावा प्रत्येक अनुरोध की जांच करें (जो कि अभी भी एक हैश टेबल की जांच करने के बाद से तेज़ होगा) यह मुझे स्पष्ट नहीं है कि जेडब्ल्यूटी का उपयोग करने के क्या फायदे हैं। क्या आप इस से परिचित किसी को समझा सकते हैं? चलो कुकीज़ को अनदेखा करते हैं, यह विशेष रूप से एक डेटाबेस कस्टम टोकन जैसा ऊपर वर्णित है और जेडब्ल्यूटी है कि मैं के लाभों की तुलना करने और समझने की कोशिश कर रहा हूं।

Answer 1

एक JSON आधारित टोकन (जेडब्ल्यूटी) निम्न समस्याओं पर काबू पा:

1. मोबाइल्स मुद्दों: मूल मोबाइल एप्लिकेशन कुकीज़ के साथ काम करने में समस्या हो तो यदि हम एक दूरस्थ एपीआई क्वेरी करने के लिए की जरूरत है लगता है, हो सकता है सत्र प्रमाणन नहीं है सबसे अच्छा समाधान।
2. सीएसआरएफ मुद्दे: यदि आप कुकीज़ के तरीके का पालन कर रहे हैं तो आपको क्रॉस साइट अनुरोधों से बचने के लिए सीएसआरएफ होना चाहिए।

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

इस टोकन को क्लाइंट स्थानीय स्टोरेज/सत्र भंडारण में स्टोर किया जाता है, इसलिए आप इन टोकन को अन्य ग्राहकों को भी पास कर सकते हैं लेकिन आपको यह जेडब्ल्यूटी उत्पन्न करने के लिए उपयोग की जाने वाली वही प्रमाण-पत्र साझा करना होगा।

Answer 2

मुख्य अंतर यह सत्र भंडारण आकार और देखने काम सर्वर से आवश्यक है:

• सर्वर साइड पर जेडब्ल्यूटी भंडार एक एकल कुंजी स्मृति में (या कॉन्फ़िग फ़ाइल में) - कहा जाता गुप्त कुंजी। उस कुंजी के दो उद्देश्य हैं, यह नए एन्क्रिप्टेड टोकन बनाने में सक्षम बनाता है और यह एक मास्टर कुंजी की तरह काम करता है जो "सभी ताले खोलता है" - या वास्तविक जीवन में सभी टोकन सत्यापित करता है। परिणामस्वरूप सर्वर ऑथ अनुरोधों के लिए बहुत तेज प्रतिक्रिया देता है, क्योंकि इससे कोई फर्क नहीं पड़ता कि आपके पास दो या दो मिलियन उपयोगकर्ता लॉग इन हैं - रिकॉर्ड्स की एक ही संख्या (एक, वह सर्वर कुंजी) का उपयोग सभी क्लाइंट अनुरोधों को प्रमाणित करने के लिए किया जाएगा ।

• पारंपरिक प्रमाणीकरण जो डेटाबेस में उपयोगकर्ता सत्र संग्रहीत करता है, प्रत्येक उपयोगकर्ता के लिए डीबी में एक रिकॉर्ड बनाता है, जिसके परिणामस्वरूप एकाधिक कुंजी होती है। तो यदि आपके पास दो मिलियन उपयोगकर्ता लॉग इन हैं, तो सर्वर दो मिलियन रिकॉर्ड बनाएगा और प्रत्येक ग्राहक अनुरोध के साथ सर्वर को डेटाबेस * में प्रासंगिक सत्र रिकॉर्ड का पता लगाने की आवश्यकता होगी।

जेडब्ल्यूटी इसे पूरे सत्र/उपयोगकर्ता ऑब्जेक्ट को स्टोर और संभालने के लिए क्लाइंट साइड तक छोड़ देता है। यह वास्तव में और अधिक समझ में आता है क्योंकि प्रत्येक ग्राहक केवल अपना डेटा ही संभालता है, इसलिए इससे क्लाइंट पक्ष के लिए भारी भारोत्तोलन नहीं होता है।

आपके पिछले पैराग्राफ में जो लिखा गया है, उसके लिए यह केवल डीबी कॉल नहीं है जिसे हम यहां सहेजते हैं। जेडब्ल्यूटी वास्तव में स्केलेबल अपनी स्वतंत्र और हल्के प्रकृति की वजह से है, यह असफल अनुरोधों के रूप में विफल नहीं होता है और यह सर्वर को सर्वर के किनारे सत्रों के प्रबंधन के बिना उपकरणों और सेवाओं में ऑथ को संभालने की अनुमति देता है।

सुरक्षा के बावजूद, डीबी सत्रों का तर्क है कि वे ऊपरी हाथ हैं: वे अधिक सुरक्षित हो सकते हैं क्योंकि उस विलंबता के कारण, और उपयोगकर्ता लॉगआउट के बाद सत्र अपहरण के लिए भी कम असुरक्षित हैं।

* डीबी संग्रहीत सत्र विधि प्रभावी कैशिंग के साथ अनुकूलित किया जा सकता है और एक तेज कुंजी/मूल्य सर्वर जैसे रेडिस में केवल सत्र आईडी (पूरे उपयोगकर्ता ऑब्जेक्ट के विपरीत) को संग्रहीत करके अनुकूलित किया जा सकता है। उस ने कहा, मैं अभी भी ज्यादातर मामलों के लिए डीबी पर जेडब्ल्यूटी विधि का चयन करूंगा।