Learn-json-web-tokens: README में खतरनाक और गलत जानकारी

कुछ बहुत अच्छी तरह से सोचे-समझे और स्पष्ट रूप से व्यक्त की गई चिंताएँ जो निश्चित रूप से मुझे विचार के लिए कुछ भोजन दे रही हैं, जिन्होंने अभी-अभी रेपो को देखना शुरू किया है। मैं नोड के साथ एक जेडब्ल्यूटी ऑथ वर्किंग उदाहरण बनाने के लिए एक त्वरित उदाहरण की तलाश में था। JWT में मेरी रुचि CORS मुद्दों से बचते हुए REST API और js क्लाइंट दोनों के लिए सत्र प्रबंधन के लिए एक आधुनिक सर्वोत्तम अभ्यास दृष्टिकोण प्रदान करना है। मुझे सुरक्षा में थोड़ी दिलचस्पी है, लेकिन यह JWT का उपयोग करने के लिए मेरी प्रेरणा नहीं है, हालांकि मैं उस भूमिका की सराहना करता हूं जो टोकन OAUTH जैसे अधिक व्यापक सुरक्षित दृष्टिकोणों में निभा सकता है। जैसा कि मैंने पहली बार इस रेपो के माध्यम से पढ़ा था, इसने मुझे बहुत सारे नोट्स शामिल किए, जो लेखक ने एकत्र किए हैं क्योंकि वे जेडब्ल्यूटी उपयोग आदि के बारे में अपने ज्ञान का निर्माण कर रहे हैं। हालांकि इस रेपो में मेरा बहुत कम निवेश है, लेकिन मुझे विश्वास है कि एक है कुछ सहायक उपकरणों, संदर्भों के साथ लॉगिन/लॉगआउट के एक मंच विशिष्ट, न्यूनतम कार्यशील उदाहरण के लिए जगह। ऑन-बोर्डिंग कौशल की नींव के रूप में और एक शुरुआत के रूप में मुझे लगता है कि इस रेपो के उद्देश्य अच्छे हैं लेकिन शायद रीडमे को एक गंभीर पुनर्लेखन और जेडब्ल्यूटी के इस प्रकार के उपयोग के उद्देश्यों पर फिर से ध्यान देने की आवश्यकता है। मुझे कुछ सुझाव देने की कोशिश करने में खुशी होगी .. joepie91 - आपको स्पष्ट रूप से मुद्दों की अच्छी समझ है .. क्या आप कुछ विचार प्रदान कर सकते हैं कि JWT के इस तरह के उपयोग के वास्तविक लाभ क्या हैं?

हाय @ joepie91 , हम _stoked_ हैं जो आपने पाया है और _read_ JWT पर हमारे नोट्स!
अपनी चिंताओं को उठाने के लिए इस मुद्दे को खोलने के लिए समय निकालने के लिए धन्यवाद। ❤️
हमें खुशी होगी अगर आप अपनी हर चिंता को अलग-अलग मुद्दों में बांट दें या कम से कम उनकी संख्या बता दें ताकि चर्चा करना आसान हो जाए।

हम _सम्मानपूर्वक_ असहमत हैं कि इन नोटों की सामग्री "_खतरनाक_" है।

_कुकीज़ _ > ईयू रिकिटल 25 , cookies _का स्पष्ट रूप से उल्लेख किया गया है _ 5 बार:

देख:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
या:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX :32002L0058:EN:HTML

दी, _many_ वेबसाइट/ऐप्स (_जो तृतीय पक्ष ट्रैकिंग कुकीज का उपयोग नहीं कर रहे हैं_) ‘strictly necessary for the delivery of a service requested by the user’ अंतर्गत आते हैं ... यही कारण है कि हम अपने _प्रगतिशील रूप से उन्नत_ वेब एप्लिकेशन में _कुकीज़ का _उपयोग_ करते हैं। देखें: https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

JWT को _लोकलस्टोरेज _ में localStorage में स्टोर करने का मतलब है कि जावास्क्रिप्ट _required _ है (_हम इसे पसंद नहीं करते हैं , हम localStorage यह है कि " _ बैकएंड-ए-ए-सर्विस_" के साथ बनाए गए BaaS आमतौर पर कुकीज़ स्वीकार नहीं करते हैं... क्या आप सुझाव दे रहे हैं कि Google Firebase का उपयोग करने वाले आधा मिलियन डेवलपर हैं गलत कर रहे हो_"...? (_यह एक महान - अलग - चर्चा होगी...!_)

स्टेटलेस सत्र JWTs के साथ _possible_ हैं क्योंकि उनके पास एक अंतर्निहित exp (_expiration time_) विकल्प है, हालांकि हम सत्र आईडी ( jti स्टोर करने का विकल्प चुनने के बजाय अपने सत्रों को स्टेटलेस बनाने के लिए _चुना/पसंद करते हैं_ नहीं _ jti ) _inside_ JWT जो एक Redis दुकान में देखा जाता है _after_ जेडब्ल्यूटी सत्यापित किया गया है। इसका मतलब है कि जब कोई व्यक्ति लॉग आउट करता है या यदि उनका उपकरण चोरी हो जाता है और उन्हें एक सक्रिय सत्र को रद्द करने की आवश्यकता होती है, तो हम एक सत्र को _अमान्य_ कर सकते हैं।

हाँ, JWTs का _प्राथमिक_ उद्देश्य pass claims between parties in web application environment , यही _exactly_ है जिसके लिए हम उनका उपयोग कर रहे हैं।

हमारे सत्र आईडी या टोकन केवल एक यादृच्छिक स्ट्रिंग हो सकते हैं जो सर्वर-साइड की जांच की जाती है, लेकिन हमने सत्र डेटा को _format_ और _sign_ करने के लिए JWTs का उपयोग करने का निर्णय लिया।

निष्कर्ष: आइए रीडमी को _clarify_ चीजों में अपडेट करें। मैं

उठाए गए मुद्दों को @nelsonic द्वारा सुझाए गए मुद्दों के एक सेट में विभाजित करने के बजाय, मैं इस बात से सहमत हूं कि कार्यान्वयन के इरादे और उद्देश्यों को @joepie91 के मुद्दों को वेब अनुप्रयोगों के संदर्भ में JWTs के उपयोग की आलोचना के रूप में या बेहतर के रूप में कुकीज़ के समर्थन के रूप में नहीं पढ़ता; बल्कि मैं आलोचना को इस रूप में लेता हूं कि जेडब्ल्यूटी का विवरण इस तरह से प्रस्तुत किया जाता है जो जेडब्ल्यूटी को चुनने के कारण को ओवरप्ले या गलत तरीके से प्रस्तुत करता है।
यही चिंता #55 में भी व्यक्त की गई है (स्पष्ट करें कि JWT एन्क्रिप्शन नहीं है...)

मेरे लिए यह एक सामान्य दावे का उपयोग करके फायरबेस और मेरी अपनी सेवाओं को संचालित करने में सक्षम होने के लिए पर्याप्त है जो समाप्त हो रहा है। मैं इसे कुछ मामलों में कुछ राज्यों को शामिल करने के लिए बढ़ा सकता हूं और दूसरों में नहीं और फिर भी कुकीज़ या पुराने एक्सेस कंट्रोल http प्रमाणीकरण दृष्टिकोण का उपयोग करने के दृष्टिकोण को पसंद करता हूं।
मुझे यह पसंद है कि मैं अधिक परिष्कृत दृष्टिकोण के हिस्से के रूप में जेडब्ल्यूटी टोकन का उपयोग कर सकता हूं लेकिन मैं अभी भी सहमत हूं कि रीडमे के लाभों पर ध्यान उन समस्याओं पर होना चाहिए जिन्हें हम कम ठोस आधार पर भटकने के बजाय उनके साथ हल करना चाहते हैं। रीडमे में अधिकांश संदर्भ सामग्री को शायद नोट्स या यहां तक ​​​​कि विकी को चर्चा सामग्री के रूप में स्थानांतरित कर दिया जा सकता है?

मुझे नहीं पता कि क्या मैं जरूरी कहूंगा कि रीडमी खतरनाक है - थोड़ा मजबूत लगता है

कुकीज़ > EU ePrivacy निर्देश Recital 25 में, कुकीज़ का स्पष्ट रूप से 5 बार उल्लेख किया गया है:

क्षमा करें, ऐसा लगता है कि मैंने इसे अस्पष्ट रूप से कहा है। हालांकि पाठ में कई जगहों पर "कुकी" शब्द शामिल है, लेकिन यह इसे एक विशिष्ट अवधारणा के रूप में परिभाषित नहीं करता है जिसे विधायी किया जाना है; बल्कि, यह एक उदाहरण के रूप में प्रदान किया गया है (और इस प्रकार मेरी बाकी बात लागू रहती है, और "कुकीज़ का उपयोग नहीं करना" जादुई रूप से सहमति की आवश्यकता को दूर नहीं करेगा)।

localStorage यह है कि "बैकएंड-ए-ए-सर्विस" के साथ बनाए गए सभी एप्लिकेशन कैसे बनाए जाते हैं, क्योंकि BaaS आमतौर पर कुकीज़ स्वीकार नहीं करता है ...

यह अप्रासंगिक है, और उन सेवाओं की समस्या है। यह _not_ आपके अपने आवेदन में सत्रों के लिए JWT का उपयोग करने का औचित्य साबित करता है।

क्या आप सुझाव दे रहे हैं कि Google फ़ायरबेस का उपयोग करने वाले आधा मिलियन डेवलपर्स इसे "गलत" कर रहे हैं ...?

इस तथ्य के अलावा कि फायरबेस बेहद खराब तरीके से तैयार किया गया है, यह प्राधिकरण से अपील है और तकनीकी चर्चा में इसका कोई स्थान नहीं है। मुझे किसी विशेष उत्पाद के लिए किसी विशेष कंपनी के निर्णयों पर चर्चा करने में कोई दिलचस्पी नहीं है; मुझे केवल किसी दिए गए दृष्टिकोण की खूबियों और कमियों पर चर्चा करने में दिलचस्पी है।

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

जिस बिंदु पर अब JWT का उपयोग करने का कोई वास्तविक लाभ नहीं है। आप केवल express-session या कुछ अन्य युद्ध-परीक्षण, सहकर्मी-समीक्षा सत्र समाधान का उपयोग क्यों नहीं कर रहे हैं जो आपके स्टैक में फिट बैठता है? जेडब्ल्यूटी के लिए सिफारिश का यहां कोई मतलब नहीं है, क्योंकि लोगों को _अपने स्वयं के सत्र प्रबंधन को पहले स्थान पर नहीं रखना चाहिए_।

उल्लेख नहीं है कि सत्र समाप्ति को _server-side_ संभाला जाना चाहिए, और इसलिए आपके जेडब्ल्यूटी में exp अनिवार्य रूप से बेकार है।

हां, जेडब्ल्यूटी का प्राथमिक उद्देश्य वेब एप्लिकेशन वातावरण में पार्टियों के बीच दावों को पारित करना है, ठीक यही हम उनके लिए उपयोग कर रहे हैं।

JWTs "वेब अनुप्रयोग वातावरण" से जरा भी संबंधित नहीं हैं।

हमारे सत्र आईडी या टोकन केवल एक यादृच्छिक स्ट्रिंग हो सकते हैं जो सर्वर-साइड की जांच की जाती है, लेकिन हमने सत्र डेटा को प्रारूपित करने और हस्ताक्षर करने के लिए जेडब्ल्यूटी का उपयोग करने का निर्णय लिया।

दोबारा, बस अपने ढेर के लिए युद्ध-परीक्षण सत्र कार्यान्वयन का उपयोग करें। जेडब्ल्यूटी यहां करने की गलत सिफारिश है।

हम सम्मानपूर्वक असहमत हैं कि इन नोटों की सामग्री "खतरनाक" है।

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

@ pscott-au: joepie91 - आपको स्पष्ट रूप से मुद्दों की अच्छी समझ है .. क्या आप इस बारे में कुछ विचार दे सकते हैं कि JWT के इस तरह के उपयोग के वास्तविक लाभ क्या हैं?

जब तक आप Reddit पैमाने पर नहीं चल रहे हैं, तब तक मानक वेब अनुप्रयोगों के लिए JWT का उपयोग करने में कोई लाभ नहीं है। ऐसे मामलों के कुछ सामान्य उदाहरण जहां JWTs _are_ उपयोगी हैं:

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

मानक वेब एप्लिकेशन सत्रों के लिए, आप जिस भी स्टैक का उपयोग कर रहे हैं उसके लिए आपको बस एक अच्छी तरह से परीक्षण किए गए सत्र कार्यान्वयन का उपयोग करना चाहिए (उदाहरण के लिए express-session जब आप एक्सप्रेस का उपयोग कर रहे हों)।

यह चर्चा करना बहुत अच्छा है क्योंकि यह वास्तव में मेरे कुछ अनुभव को चुनौती देता है। शायद जेडब्ल्यूटी का उपयोग करने में मेरी व्यक्तिगत रुचि के लिए कुछ संदर्भ (इस तथ्य से अलग कि मैं फायरबेस का उपयोग करता हूं, जिसे मैं खराब इंजीनियरिंग मुद्दों को सीखने में दिलचस्पी लेता हूं, जिन पर मैं गौर करूंगा)। मोबाइल ऐप्स/एसपीए बनाते समय और विशेष रूप से एकाधिक सर्वर/डोमेन से प्राप्त सेवाओं का उपयोग करते समय मुझे लगता है कि मुझे अक्सर क्षमता पर एक ही संकेत की आवश्यकता होती है जो जेडब्ल्यूटी खुद को अच्छी तरह से उधार देती है। मेरी समझ यह है कि सत्र कुकीज़ का उपयोग उस अवधि में विकसित हुआ जिसमें ब्राउज़र और जेएस स्पेस में सुरक्षा कड़ी कर दी गई थी और सीओआरएस की शुरूआत अपवादों को संभालने के लिए विकसित हुई थी जिससे हमें एक हैकी समाधान के साथ छोड़ दिया गया था कि जेडब्ल्यूटी किसी तरह से संबोधित करता है .
वर्षों से कुकी सत्र दृष्टिकोणों ने निश्चित रूप से मूल मूल और डाइजेस्ट एचटीटीपी ऑथ की तुलना में बहुत बेहतर दृष्टिकोण प्रदान किया है और कई बार मैं वेब आधारित ऐप के लिए कुकी सत्र प्रबंधन समाधान का उपयोग करता हूं।
लेकिन .. मुझे लगता है कि अब मैं जिन अधिकांश ऐप्स का निर्माण कर रहा हूं वे मोबाइल या एसपीए हैं और आरईएसटी एपीआईएस का भारी उपयोग करते हैं। मुझे कुकी हैंडलिंग सामग्री को बंडल किए बिना या सत्र स्थापित करने के लिए एकाधिक अनुरोधों से निपटने के बिना सरल कर्ल अनुरोधों के साथ आसानी से परीक्षण करने में सक्षम होना पसंद है। इसलिए मुझे लगता है कि तेजी से लागू होने वाले एपीआई कि चीजें बस काम करती हैं जब मैं जेडब्ल्यूटी का उपयोग करता हूं। मेरे पेट में कुकीज़ की तुलना में लंबे समय तक चलने वाले सत्रों के लिए जेडब्ल्यूटी का उपयोग करना अधिक उपयुक्त लगता है, हालांकि मैं इस पर विचार करूंगा क्योंकि यह अच्छे अंतर्ज्ञान से अधिक आलस्य हो सकता है। मैं जरूरत पड़ने पर OAUTH की तर्ज पर सुरक्षा बढ़ा सकता हूं और मैं चीजों को और अधिक सुरक्षित करना चाहता हूं लेकिन अधिक बार ऐसा नहीं है कि सत्र ऐसा कुछ नहीं है जिसे मैं सुरक्षा के इस स्तर की आवश्यकता के रूप में देखता हूं। मेरे लिए महत्वपूर्ण बात वह लचीलापन है जो भविष्य में वास्तु परिवर्तनों के संबंध में JWT आधारित प्रमाणीकरण दृष्टिकोण प्रदान करता है। मैंने पाया है कि एक विकल्प के रूप में जेडब्ल्यूटी ऑथ प्रदान करने के लिए पुराने कोड को फिर से तैयार किया गया है और इसने आश्चर्यजनक रूप से कम रखरखाव जटिलता पेश की है लेकिन ज्यादातर मामलों में भविष्य के विकास को सुव्यवस्थित किया है और मुझे इसका कोई भी हिस्सा कुकी सत्रों से स्वाभाविक रूप से कम नहीं दिखता है।
जेडब्ल्यूटी टाइमआउट सुविधाओं का उपयोग करने के वास्तव में फायदे हैं, खासकर मोबाइल उपकरणों पर और कुछ सहायक पुस्तकालय इसका उपयोग करते हैं। उदाहरण के लिए आप एक ऐप को उपयोगकर्ता को लॉग आउट कर सकते हैं या इस टाइमआउट के आधार पर उन्हें लॉग इन छोड़ सकते हैं जब डिवाइस नेटवर्क कनेक्ट नहीं होता है।
मेरे लिए सत्र कुकीज़ पर जेडब्ल्यूटी के पैमाने के फायदे के बारे में मुझे कोई सम्मोहक तर्क नहीं दिखता है।
मैं लोगों को यह सुझाव देते हुए देखता हूं कि जेडब्ल्यूटी को एक सत्र कुकी के रूप में इस्तेमाल किया जा सकता है, जो मेरे लिए अच्छे से ज्यादा नुकसान करता है क्योंकि कुकीज़ की अपनी टाइमआउट अवधि होती है (पूरी तरह से प्रबंधित सर्वर साइड नहीं) और इनके संयोजन से भ्रमित होने की संभावना है।
कई आधुनिक JS फ्रेमवर्क कुकीज़ की तुलना में JWT के लिए अधिक समर्थन प्रदान कर रहे हैं, जो बताता है कि स्टैक के लिए युद्ध परीक्षण किया गया सहकर्मी समीक्षा समाधान वास्तव में कई अनुप्रयोगों के लिए JWT की ओर झुकाव कर सकता है। हालांकि वेब सेवाओं के लिए JWT की लोकप्रियता कोई तकनीकी तर्क नहीं है, लेकिन इसे अप्रासंगिक कहकर खारिज कर दिया जाता है क्योंकि ये सभी समान रूप से भ्रामक हैं। एक्सप्रेस एक मुख्य तत्व नहीं है जो ड्वाइल समूह द्वारा उपयोग किया जाने वाला स्टैक है जैसा कि मैं सबसे अच्छा बता सकता हूं इसलिए इसके साथ संरेखित करने का कोई कारण नहीं है।
मुझे आशा है कि मेरे इरादे का कुछ सूत्र है जिससे आप सहमत हो सकते हैं क्योंकि मैं चिंतित हूं लेकिन आपके तर्कों से पूरी तरह आश्वस्त नहीं हूं।
मैं सहमत हूं कि रीडमी को एक गंभीर ओवरहाल की आवश्यकता है और यह कि ऐसी लाइनें हैं जिनका यह अनुसरण करता है जिन्हें बेहतर तरीके से हटा दिया जाता है या पृष्ठभूमि चर्चा पाठ में वापस धकेल दिया जाता है न कि मुख्य रीडमे में।

(इस तथ्य के अलावा कि मैं फायरबेस का उपयोग करता हूं, जिसे मैं खराब इंजीनियरिंग मुद्दों को सीखने में दिलचस्पी लेता हूं, जिन पर मैं गौर करूंगा)

कुछ समस्याएं यह हैं कि इसकी जेएस क्लाइंट लाइब्रेरी बंद-स्रोत है और बल्कि अनुपयोगी त्रुटि आउटपुट के साथ बाधित है, "सरणी" जैसी कोई चीज नहीं है, क्लाइंट लाइब्रेरी में कई अजीब बग हैं जहां आपको प्रतिक्रिया वापस नहीं मिल सकती है अस्पष्ट कारण, एसीएल सिस्टम एक गैर-मानक JSON संस्करण का उपयोग करता है, यहां तक ​​कि उनका स्वयं का संपादक भी समर्थन नहीं करता है, JS API को सामान्य कॉलबैक API के बजाय एक छद्म-घटना API का उपयोग करने की आवश्यकता होती है (लेकिन लगातार व्यवहार नहीं करता है), और जल्द ही।

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

बिल्कुल सटीक नहीं। आपका एप्लिकेशन और तृतीय-पक्ष API अलग-अलग प्रमाणीकरण आवश्यकताओं के साथ अलग-अलग चीजें हैं। जबकि एक टोकन-आधारित प्रमाणीकरण प्रणाली किसी तृतीय-पक्ष एपीआई से बात करते समय किसी एप्लिकेशन में समझ में आ सकती है, यह आपके अपने आवेदन के लिए कोई मतलब नहीं है, भले ही वह एक एसपीए हो। यह "एकल साइन-ऑन" से भी असंबंधित है, जो एक ही लॉगिन सेवा का उपयोग करने वाली कई अंतिम-उपयोगकर्ता सेवाओं को संदर्भित करता है।

CORS एक अलग मुद्दा है, और वास्तव में इससे संबंधित नहीं है।

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

विकास में, आपकी कुछ परीक्षण आवश्यकताएं हो सकती हैं, लेकिन ये आपके द्वारा उत्पादन में लिए जाने वाले दृष्टिकोण को प्रभावित नहीं करना चाहिए। इस तथ्य के अलावा कि ज्यादातर चीजें जो एक एसपीए हैं, वास्तव में एसपीए नहीं होनी चाहिए (एसपीए वेबएप के लिए हैं, वेबसाइटों के लिए नहीं!), ऐसा कोई कारण नहीं है कि आप उनके साथ सत्रों का उपयोग नहीं कर सकते।

इसके अलावा, कर्ल कुकीज़ को ठीक से समर्थन करता है, और कई अन्य, बेहतर एपीआई परीक्षण क्लाइंट जैसे httpie या यहां तक ​​​​कि http-prompt भी हैं ।

मैं जरूरत पड़ने पर OAUTH की तर्ज पर सुरक्षा बढ़ा सकता हूं और मैं चीजों को और अधिक सुरक्षित करना चाहता हूं लेकिन अधिक बार ऐसा नहीं है कि सत्र ऐसा कुछ नहीं है जिसे मैं सुरक्षा के इस स्तर की आवश्यकता के रूप में देखता हूं।

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

मेरे लिए महत्वपूर्ण बात वह लचीलापन है जो भविष्य में वास्तु परिवर्तनों के संबंध में JWT आधारित प्रमाणीकरण दृष्टिकोण प्रदान करता है। मैंने पाया है कि एक विकल्प के रूप में जेडब्ल्यूटी ऑथ प्रदान करने के लिए पुराने कोड को फिर से तैयार किया गया है और इसने आश्चर्यजनक रूप से कम रखरखाव जटिलता पेश की है लेकिन ज्यादातर मामलों में भविष्य के विकास को सुव्यवस्थित किया है और मुझे इसका कोई भी हिस्सा कुकी सत्रों से स्वाभाविक रूप से कम नहीं दिखता है।

यहां कोई लचीलापन पेश नहीं किया गया है जिसकी 99.99% डेवलपर्स को कभी आवश्यकता होगी, और मैंने पहले से ही कुछ समस्याओं पर प्रकाश डाला है, जैसे कि पुराना डेटा और टोकन को अमान्य करने में असमर्थता।

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

यह JWT के लिए अद्वितीय नहीं है; आप इसे सर्वर-साइड सत्रों के साथ ठीक कर सकते हैं। वास्तव में, जेडब्ल्यूटी को (जटिल) स्टेटफुल आर्किटेक्चर को पेश किए बिना अमान्य नहीं किया जा सकता है, इसलिए सत्र वास्तव में यहां जीतते हैं।

मेरे लिए सत्र कुकीज़ पर जेडब्ल्यूटी के पैमाने के फायदे के बारे में मुझे कोई सम्मोहक तर्क नहीं दिखता है।

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

कई आधुनिक JS फ्रेमवर्क कुकीज़ की तुलना में JWT के लिए अधिक समर्थन प्रदान कर रहे हैं, जो बताता है कि स्टैक के लिए युद्ध परीक्षण किया गया सहकर्मी समीक्षा समाधान वास्तव में कई अनुप्रयोगों के लिए JWT की ओर झुकाव कर सकता है।

मुझे अभी तक एक ऐसा ढांचा नहीं दिख रहा है जो सत्र कुकीज़ का समर्थन नहीं करता है।

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

यही उनकी समस्या है। एक्सप्रेस केवल एक उदाहरण था, अच्छी तरह से परीक्षण किए गए सत्र कार्यान्वयन मूल रूप से हर सामान्य रूप से उपयोग किए जाने वाले ढांचे के लिए मौजूद हैं।

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

@ joepie91 मैं आपको यह नहीं बता सकता कि कैसे _delighted_ मैं हूं कि आपने हमारे रेपो/नोट्स ढूंढ लिए हैं और इसे पढ़ने और हमें प्रतिक्रिया देने के लिए अपना समय लगाया है! गंभीरता से, अगर मैं कभी आपसे व्यक्तिगत रूप से मिलूं, तो मैं आपको एक _पैलेट_ दूंगा कि आप जो भी पीना पसंद करते हैं! मैं

अगर मैं आपको इस रेपो में योगदानकर्ता बना दूं तो क्या आप इसे _सुधारने के लिए मेरे पुल अनुरोध की समीक्षा करेंगे? मैं

इसके अलावा, @AshleyPinner , @alfiepates , @sunny-g _you_ सज्जनों ने इस _particle_ चर्चा पर कैसे ठोकर खाई? क्या मुद्दा Redit/Hackernews पर साझा किया गया था? (_मैं बस उत्सुक हूं कि लोग हमारी पोस्ट कैसे ढूंढते हैं..._)

मैं कुछ दिनों से इसे चबा रहा हूं और आधुनिक एसपीए और मोबाइल ऐप में पारंपरिक सत्र कुकीज़ से पहले जेडब्ल्यूटी को डिफ़ॉल्ट विकल्प के रूप में उपयोग करने के खिलाफ कई तर्कों के साथ बोर्ड पर नहीं जा सकता।
मैं विशिष्ट आवश्यकताओं के लिए कुकीज़/जेडब्ल्यूटी ऑथ दृष्टिकोण के पेशेवरों और विपक्षों का वजन करने के लिए निर्णय मैट्रिक्स बनाने के बारे में सोच रहा था, या रीडमे को फिर से लिखने के बारे में सोचने से पहले उपयोग के मामलों के एक सेट में पेशेवरों और विपक्षों का विवरण देने के बारे में सोच रहा था। मुझे ऐसा लगता है कि जटिल ऐप्स बनाने में लोगों को जिन वास्तविक दुनिया की चुनौतियों का सामना करना पड़ता है, वे अधिकांश भाग के लिए कम सुरुचिपूर्ण ढंग से हल की जाती हैं या कम से कम कुकी सत्रों का उपयोग करने में समस्याग्रस्त होती हैं। मुद्दा पोस्टर बनाने वाली धारणा यह है कि जेडब्ल्यूटी कुछ अविश्वसनीय अपरिपक्व तकनीक है जो आधुनिक ऐप्स के लिए अनुपयुक्त है और यह दावा शायद उपयोगकर्ता को प्रमाणित करने के लिए इसका उपयोग करने का पूरी तरह से काम करने का उदाहरण प्रदान करने से भी अधिक खतरनाक है।
मुझे यह शपथ लेख मददगार लगा । मुझे लगता है कि उन चीजों में से एक जिसने इस रेपो के लिए इतनी मजबूत प्रतिक्रिया शुरू की है, लेकिन मुद्दा रिपोर्टर उन विशेषताओं की चर्चा है जो आम तौर पर जेडब्ल्यूटी का उपयोग करके कुकी सत्रों में अपेक्षित हैं जो जेडब्ल्यूटी के कुछ मुख्य लाभों से अलग हो जाते हैं, मुख्य रूप से इसमें शामिल हैं स्टेटलेस हो सकता है। लगातार भंडारण को शामिल करके राज्य का परिचय दें हम JWT के लिए मुख्य उपयोग के मामलों में से एक को समाप्त कर रहे हैं और कुकीज़ का उपयोग करके परिपक्व चीजों को फिर से लागू कर रहे हैं।
उस ने कहा, जटिल ऐप्स को राज्य की कुछ खोज की आवश्यकता होती है - भले ही केवल एक HTTP अनुरोध के जीवन से परे संसाधित कार्यों के लिए लेनदेन संबंधी अनुरोधों के लिए। इससे जेडब्ल्यूटी के उपयोग पर रोक नहीं लगनी चाहिए, लेकिन हमें इस बात पर विचार करने के लिए विराम देना चाहिए कि लेनदेन में जेडब्ल्यूटी की क्या भूमिका है। मुझे लगता है कि एक जेडब्ल्यूटी होना ठीक है जो किसी संसाधन तक पहुंच प्रदान करता है और संसाधन में उपयोगकर्ता के लिए एक स्थिति होती है जो किसी सेवा तक पहुंच से इनकार करती है; इस मामले में यह जेडब्ल्यूटी नहीं है जिसे समाप्त करने की आवश्यकता है, लेकिन उपयोगकर्ता की स्थिति जेडब्ल्यूटी का उपयोग करके सेवा तक पहुंच रही है।

परिवहन तंत्र के रूप में कुकीज़ का उपयोग करने के लिए आगे विस्तार करने से अन्य लाभों को समाप्त कर दिया जाता है और हमें कुकीज़ का उपयोग करने के लिए वापस लाया जाता है, लेकिन सामान्य पुस्तकालय कार्यक्षमता को अनदेखा करना और खरोंच से सुविधाओं को फिर से लिखना जो आगे अस्पष्टता का परिचय देता है क्योंकि हम डुप्लिकेट टाइमआउट आदि के साथ समाप्त होते हैं। जब मैंने पहले CORS का उल्लेख किया था शायद कुकीज़ के साथ एकाधिक डोमेन का उपयोग करने की कठिनाइयों को इंगित करने में स्पष्ट होना बेहतर था। ज़रूर, आप वाइल्डकार्ड डोमेन सेट कर सकते हैं, लेकिन अगर वे पर्याप्त रूप से भिन्न हैं तो पारंपरिक सत्र कुकीज़ जल्दी से बोझिल हो जाती हैं। यह तर्क दिया जा सकता है कि अधिकांश डेवलपर्स को कई डोमेन पर संरक्षित संसाधनों तक पहुंचने के लिए अपने प्रमाणित क्लाइंट की आवश्यकता नहीं होती है, लेकिन यह एक विदेशी बढ़त के मामले के बजाय एक सामान्य अभ्यास होता जा रहा है।
एक अर्थ में एक नए व्यक्ति के रूप में जो प्रमाणित सत्रों के प्रबंधन का पता लगाना शुरू कर रहा है, मैं सराहना करता हूं कि वेब ऐप में संसाधन तक पहुंच को सरलतम अर्थों में प्रमाणित उपयोगकर्ताओं तक सीमित करने के तरीके के बारे में सीखने का यह उचित तरीका नहीं हो सकता है, लेकिन इसका उपयोग जेडब्ल्यूटी केवल प्रमाणित सत्रों के शुरुआती बिंदु के रूप में और अधिक प्रमुख बनने जा रहा है, इसलिए इसे खारिज करने के लिए क्योंकि हमने लंबे समय तक सत्र कुकीज़ का उपयोग किया है, मेरे लिए यह विश्वास करने के लिए पर्याप्त नहीं है कि सभी को सत्र कुकीज़ से शुरू करना चाहिए और केवल जेडब्ल्यूटी के बारे में सीखना और उपयोग करना चाहिए जब वे पाते हैं कि वे सभी डोमेन में कुकीज़ साझा करने में असमर्थ हैं या किसी तृतीय पक्ष एपीआई का उपयोग करने की आवश्यकता है या सर्वर की जांच किए बिना समाप्ति का निर्धारण करने में सक्षम होने की आवश्यकता है, या मोबाइल डिवाइस आदि पर उपयोगकर्ता लॉगिन क्रेडेंशियल के भंडारण पर सवाल उठाते हैं। .

जब तक आप एक शीर्ष स्तरीय अवैध व्यापार साइट नहीं चला रहे हैं, तब तक स्टेटलेस टोकन के लाभों को महत्वहीन समझना गलत है। यहां तक ​​​​कि जब हम राज्य की एक नई परत पेश करके चीजों को उलझाते हैं, तो सर्वर से सत्र को अलग करने के कई फायदे हैं।

@nelsonic 4744cd1bb8991bc4057c749f86007fcecac19d1d को देखते हुए, यह बहुत स्पष्ट शब्दों की तरह लगता है। हालांकि, शीर्षलेख परिवर्तनों को प्रतिबिंबित नहीं करता है।

@ pscott-au: आधुनिक एसपीए और मोबाइल ऐप्स में।

यह सत्र तंत्र की आपकी पसंद के लिए _completely_ ओर्थोगोनल है। यह उल्लेख नहीं करने के लिए कि ज्यादातर चीजें जो आज एक एसपीए हैं, नहीं होनी चाहिए। किसी वेबसाइट के लिए एसपीए का उपयोग करना (वेब-ऐप के विपरीत) वेब को तोड़ देता है।

मुझे ऐसा लगता है कि जटिल ऐप्स बनाने में लोगों को जिन वास्तविक दुनिया की चुनौतियों का सामना करना पड़ता है, वे अधिकांश भाग के लिए कम सुरुचिपूर्ण ढंग से हल की जाती हैं या कम से कम कुकी सत्रों का उपयोग करने में समस्याग्रस्त होती हैं।

जैसे कि?

मुद्दा पोस्टर बनाने वाली धारणा यह है कि जेडब्ल्यूटी कुछ अविश्वसनीय अपरिपक्व तकनीक है जो आधुनिक ऐप्स के लिए अनुपयुक्त है

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

मैं यह नहीं कह रहा कि उपकरण खराब है, मैं कह रहा हूं कि आप इसका गलत उपयोग कर रहे हैं।

और यह दावा शायद उससे भी ज्यादा खतरनाक है

इसके लिए आपका तर्क क्या है?

मुझे यह शपथ लेख मददगार लगा।

इसे बिंदुवार संबोधित करते हुए:

• स्टेटलेस, स्केलेबल और डिकॉउप्ड: मैंने पहले ही स्वीकार कर लिया है कि यह एक सैद्धांतिक लाभ है, लेकिन एक ऐसा जिसकी वास्तव में वास्तव में किसी को आवश्यकता नहीं है। आपको यह भी विचार करना चाहिए कि Auth0 का यहां निहित स्वार्थ है, एक जो _not_ आपको एक डेवलपर के रूप में लाभान्वित करता है: _ "थर्ड पार्टी सेवाएं जैसे Auth0 टोकन जारी करने को संभाल सकती है और फिर सर्वर को केवल टोकन की वैधता को सत्यापित करने की आवश्यकता होती है। "_ आपके प्रमाणीकरण की आउटसोर्सिंग एक _भयानक_ विचार है, वैसे।
• क्रॉस डोमेन और कॉर्स: पूर्ण और पूरी तरह से बकवास। यह _storage method_ के बारे में बात करता है, जो कि टोकन _contains_ सत्र डेटा या नहीं से पूरी तरह से अलग है। आप मैन्युअल रूप से एक सत्र आईडी भेज सकते हैं, या आप एक कुकी में एक जेडब्ल्यूटी स्टोर कर सकते हैं। जेडब्ल्यूटी बनाम सत्रों से कोई लेना-देना नहीं है - जो लेख लेखक के पूर्वाग्रह/अज्ञान को भी दिखाता है, क्योंकि "कुकीज़ बनाम टोकन" की तुलना _ से शुरू करने का कोई मतलब नहीं है। यह सुरक्षा के इस मुद्दे को भी पूरी तरह से नजरअंदाज करता है।
• जेडब्ल्यूटी में डेटा स्टोर करें: सुविधा नहीं। सत्रों पर भी यही लागू होता है। और कुकीज़, वैसे।
• प्रदर्शन: यह केवल "स्टेटलेस" बिंदु का दोहराव है, ज्यादातर - इस तथ्य से अलग कि यह _at all_ स्पष्ट नहीं है कि क्या क्रिप्टोग्राफ़िक सत्यापन आवश्यक रूप से सत्र डेटा हैंडलिंग प्रदर्शन पर रेडिस जैसी किसी चीज़ को हरा सकता है (आरडीबीएमएस से उनकी तुलना अवास्तविक है) , यह लगभग हर वेब-ऐप के लिए पूरी तरह से नगण्य प्रदर्शन अनुकूलन भी है। इसे "समयपूर्व अनुकूलन" कहा जाता है, और इसे बहुत अच्छे कारण के लिए व्यापक रूप से अनुशंसित किया जाता है।
• मोबाइल तैयार: बकवास। यदि आपकी HTTP लाइब्रेरी कुकीज़ का समर्थन नहीं करती है, तो _बेहतर HTTP लाइब्रेरी की तलाश करें_। कुकीज़ ठीक समर्थित हैं, वे केवल HTTP शीर्षलेख हैं।

तो नहीं, यह लेख JWT के किसी भी नए लाभ को नहीं लाता है जिसे मैंने पहले ही कवर नहीं किया है। यह कभी-कभी-लाभ (स्टेटलेसनेस) को गलत तरीके से प्रस्तुत करता है जो प्रत्येक एप्लिकेशन पर लागू होता है (ऐसा नहीं होता है), और फिर निरर्थक तुलना करता है और शेष के लिए सत्र प्रदर्शन पर अधिक जोर देता है।

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

जैसा कि मैंने कहा है, व्यवहार में यह लगभग कभी भी लाभ नहीं होता है। आप स्टेटलेसनेस के इसी बिंदु को बार-बार दोहरा सकते हैं, लेकिन यह इसे और अधिक मान्य या लागू नहीं करेगा। यह एक सामान्य प्रयोजन की आवश्यकता _बिल्कुल नहीं_ है।

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

इस मामले में आपको किसी प्रकार की नियमित सत्र आईडी पर कोई लाभ नहीं है।

[...] जब मैंने पहले CORS का उल्लेख किया था, तो कुकीज़ के साथ कई डोमेन का उपयोग करने की कठिनाइयों को इंगित करने में स्पष्ट होना बेहतर था। ज़रूर, आप वाइल्डकार्ड डोमेन सेट कर सकते हैं, लेकिन अगर वे पर्याप्त रूप से भिन्न हैं तो पारंपरिक सत्र कुकीज़ जल्दी से बोझिल हो जाती हैं।

यह बिंदु तक पूरी तरह से ऑर्थोगोनल भी है। यह पूरी तरह से इस बारे में है कि आप अपने पहचानकर्ताओं को कहां _store_ करते हैं, न कि इस बारे में कि वे सत्र डेटा को स्वयं _contain_ करते हैं या नहीं। और फिर, सुरक्षा जोखिम ।

लेकिन जेडब्ल्यूटी का उपयोग केवल प्रमाणित सत्रों के शुरुआती बिंदु के रूप में अधिक प्रमुख होने जा रहा है

और यह मुझे बहुत चिंतित करता है, क्योंकि वह प्रमुख उपयोग अज्ञानता और प्रचार पर आधारित है, और कई सुरक्षा समस्याओं के साथ आता है। यह एक बड़ा कदम पीछे है।

इसलिए इसे खारिज करने के लिए क्योंकि हमने लंबे समय से सत्र कुकीज़ का उपयोग किया है

मैंने कभी ऐसा कुछ नहीं कहा। मैंने सत्र प्रबंधन के लिए JWT _वस्तुनिष्ठ रूप से हीन_ क्यों है, इसके कई _बहुत_ स्पष्ट कारण प्रदान किए हैं।

और JWT के बारे में तभी जानें और उसका उपयोग करें जब उन्हें पता चले कि वे सभी डोमेन में कुकीज़ साझा करने में असमर्थ हैं

ऐसे में सुरक्षा की समस्या है । कुकीज़ _वैकल्पिक नहीं हैं_।

या किसी तृतीय पक्ष API को एक्सेस करने की आवश्यकता है

सत्रों के लिए अप्रासंगिक।

या सर्वर की जांच किए बिना समाप्ति का निर्धारण करने में सक्षम होना चाहिए

संभव नहीं है, क्योंकि सर्वर को सत्र को स्पष्ट रूप से अमान्य करने की क्षमता बनाए रखने की आवश्यकता है - जैसे। जब उपयोगकर्ता अपना पासवर्ड बदलता है या अन्य सत्रों को जबरन बंद कर देता है।

या मोबाइल डिवाइस आदि आदि पर उपयोगकर्ता लॉगिन क्रेडेंशियल के भंडारण पर सवाल उठाएं।

कुकीज़। किया हुआ।

जब तक आप एक शीर्ष स्तरीय अवैध व्यापार साइट नहीं चला रहे हैं, तब तक स्टेटलेस टोकन के लाभों को महत्वहीन समझना गलत है। यहां तक ​​​​कि जब हम राज्य की एक नई परत पेश करके चीजों को उलझाते हैं, तो सर्वर से सत्र को अलग करने के कई फायदे हैं।

फिर भी आप उनमें से किसी का भी उल्लेख नहीं करते हैं जिसे मैंने पहले ही संबोधित नहीं किया है, और अपने निष्कर्षों में ध्यान में रखा है। मुझे खेद है, लेकिन आप उपन्यास दृष्टिकोण होने के लिए उपन्यास दृष्टिकोण का बचाव कर रहे हैं, और विभिन्न दृष्टिकोणों के _objective, तकनीकी गुणों_ को पूरी तरह से अनदेखा कर रहे हैं।

इसे ही "हाइप" कहा जाता है, और यह बेहद हानिकारक है।

स्टेटलेस: महत्वपूर्ण जब किसी ऐप को ऑफ़लाइन कार्य करने और किसी प्रकार का अर्थ बनाए रखने की आवश्यकता होती है।

ऑफ़लाइन एप्लिकेशन को प्रमाणीकरण की आवश्यकता नहीं है, _बिल्कुल_। परिभाषा के अनुसार, अन्य प्रणालियों के साथ कोई सहभागिता नहीं है।

क्रॉस डोमेन क्रेडेंशियल प्रमाणीकरण: महत्वपूर्ण यदि आप अपने एप्लिकेशन को कई सर्वरों का उपयोग करके माइक्रोसर्विसेज में विभाजित करते हैं

सही। लेकिन इस मामले में, आप अपने सत्र तंत्र_ के रूप में JWT _ का उपयोग नहीं करते हैं, आप इसे एकल-उपयोग टोकन के रूप में उपयोग करते हैं जो एक सत्र के लिए _exchanged_ हो सकता है। दोनों और इसके द्वारा प्रस्तुत किए जाने वाले ट्रेडऑफ़ में बहुत बड़ा अंतर है।

( संपादित करें: निश्चित रूप से यह _stateful_ माइक्रोसर्विसेज मानता है, और 'स्टेटफुल' के साथ मैं _not_ सत्र का जिक्र कर रहा हूं, लेकिन सेवा के लिए। स्टेटलेस कार्यों को करने वाले माइक्रोसर्विसेज के लिए, एक सत्र का उपयोग करके _बिना_के एकल-उपयोग टोकन पर्याप्त है, एप्लिकेशन सर्वर द्वारा जारी किए जा रहे एकल-उपयोग टोकन के साथ। माइक्रोसर्विसेज से बात करने वाले एप्लिकेशन सर्वर के लिए, JWT भी ठीक है - यहां "सत्र" की कोई अवधारणा नहीं है, और हस्ताक्षर कुंजी को बदलकर टोकन निरस्तीकरण किया जा सकता है।)

आप JWT की उपयोगिता को नकारना जारी रख सकते हैं

दोबारा, मैं ऐसा कुछ नहीं कर रहा हूं। ये पूरी तरह से आपके शब्द हैं।

जब मैं अधिक विवरण प्रदान करने का प्रयास करता हूं तो आप मेरे मामलों को अप्रासंगिक या बुरे व्यवहार के रूप में खारिज कर देते हैं .. मेरी राय में गलत तरीके से।

फिर मैं आपसे _why_ के बारे में विस्तार से बताने की अपेक्षा करता हूं कि यह गलत है, न कि केवल "यह गलत है!" और उम्मीद है कि मैं इसे अंकित मूल्य पर ले जाऊंगा। मैं ठीक इसी कारण से आपके द्वारा प्रदान किए जाने वाले प्रत्येक बिंदु को ठोस रूप से संबोधित कर रहा हूं।

IOS लॉगिन सत्र को प्रबंधित करने के लिए कुकी पर निर्भर होना डिफ़ॉल्ट रूप से सबसे अच्छा समाधान नहीं है।

क्यों?

कुकीज़ का दुरुपयोग किया जा सकता है

यह एक खाली बयान है। दुरुपयोग _कैसे_? और यह स्थानीय संग्रहण में संग्रहीत मूल्यों पर कैसे लागू नहीं होता है? और इसका JWT _at all_ से क्या लेना-देना है, यह देखते हुए कि "कुकीज़" एक भंडारण विधि है, सत्र तंत्र नहीं? "जेडब्ल्यूटी बनाम कुकीज़" की तुलना सेब और संतरे की तुलना कर रही है, वे एक ही वर्ग की चीज भी नहीं हैं!

सत्र प्रबंधन के लिए JWT का उपयोग अलग है और कुकी सत्रों की तुलना में अलग-अलग गुण हैं - यह इसे हीन नहीं बनाता है, लेकिन एक उपयुक्त समाधान को तैयार करने में बस अलग-अलग ऑपरेटिंग पैरामीटर मानदंड हैं। यदि आप कुकीज़ का उपयोग करना चाहते हैं तो कुकीज़ का उपयोग करें - यदि वे आपकी आवश्यकताओं को पूरा करती हैं तो उनका उपयोग करें - आप अन्य लोगों को किसी अन्य दृष्टिकोण पर विचार करने से क्यों रोकना चाहते हैं?

मैं नहीं। मेरे पास _बहुत स्पष्ट रूप से संकेतित अपवाद हैं जहां JWT _is_ सही समाधान है। मैंने _बहुत स्पष्ट रूप से_ संकेत दिया है कि जेडब्ल्यूटी एक सामान्य प्रयोजन सत्र तंत्र के रूप में अनुपयुक्त है। मेरे मुंह में शब्द डालना बंद करो।

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

क्योंकि ऐसा कोई कारण नहीं है कि आप विभिन्न प्रयोजनों के लिए _both_ JWT और सत्रों का उपयोग नहीं कर सकते। इसके लिए सभी को एक ही तंत्र में ढालने की कोशिश करना पूरी तरह से गुमराह करने वाला है। उपयुक्त उपकरण का उपयोग करें - "नई कुकीज़ बनाने की आवश्यकता नहीं है" एक पूरी तरह से मनमाना मीट्रिक है और वास्तविक रूप से, वह लाभ नहीं है जिसका आप अनुमान लगा रहे हैं।

यदि आप सुरक्षा समस्याओं को देखते हैं तो उन्हें पहचानें और उन्हें ध्वजांकित करें - वे शो स्टॉपर नहीं हो सकते हैं लेकिन निर्णय लेने में जागरूक होने के लिए उपयोगी हो सकते हैं। आप विट्रियल शब्दांकन इसे स्वीकार नहीं करते हैं या इसे एक संभावना भी मानते हैं क्योंकि आप यह बताना जारी रखते हैं कि सत्र कुकीज़ का उपयोग प्रत्येक http ऐप के लिए किया जाना चाहिए जो कि हास्यास्पद है।

फिर से। नहीं। मैंने कहा। मेरे मुंह में शब्द डालना बंद करो।

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

यह एक विशेषता है कि _requires_ किसी प्रकार के स्टेटफुल सत्र, वास्तुशिल्प रूप से। मैं बहस नहीं कर रहा हूं कि यह सत्र कुकीज़ द्वारा प्रदान किया जाता है - मैं तर्क दे रहा हूं कि यह स्टेटलेस टोकन के साथ _impossible_ है।

यदि आप सत्र के जीवन के लिए संसाधन तक पहुंचने के लिए डीबी की जांच किए बिना प्रमाणित पहुंच प्रदान करने में काफी सहज हैं तो आप क्यों जोर देते हैं कि यह इस दृष्टिकोण की विफलता है।

दोबारा, मैंने जो कहा वह नहीं।

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

बात ऊपर की नहीं है। बिंदु आजमाए हुए और परीक्षण किए गए समाधानों का

आप कुकीज़ के लिए अनुरोधों की संख्या को अनदेखा करते हैं और सुझाव देते हैं कि केवल प्रदर्शन पर विचार ही लुकअप है। रिफ्रेश आदि को समन्वित करने और निर्भर करने की आवश्यकता .. ओह कोई बात नहीं ... (यहाँ छोड़ दिया)

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

आपको यह पसंद आ सकता है कि कुकीज़ डोमेन तक ही सीमित हैं और यह मानते हैं कि उन्हें क्रॉस-डोमेन का उपयोग करने की अनुमति देने से सुरक्षा समस्याएं आती हैं जो उनके उपयोग को रोकती हैं - यह ठीक है - मैं नहीं करता।

दोबारा, मैंने जो कहा वह नहीं।

जेडब्ल्यूटी सभी सत्र कुकीज़ को बदलने के लिए अगली चीज नहीं है, लेकिन न ही वे उतने गंभीर घृणित हैं (जब सत्रों का प्रबंधन करने के लिए उपयोग किया जाता है) जैसा कि आप इंगित करते हैं।

हाँ वे हैं। सत्र के लिए JWT का उपयोग करने का एकमात्र कारण यह है कि विकल्प बदतर या असंभव हैं, और यह एक _extremely_ दुर्लभ बढ़त मामला है।

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

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

प्रचार नहीं - अज्ञानता पर आधारित नहीं है, लेकिन हाइब्रिड ऐप बनाते समय नियमित रूप से सामना की जाने वाली समस्याओं का एक वैध समाधान है, जिसके लिए सेवाओं के लिए क्रॉस प्रमाणीकरण की आवश्यकता होती है, जो कि पूर्ण सख्त सुरक्षा प्रदान करने का लक्ष्य नहीं रखते हैं जो कि प्रौद्योगिकी प्रदान कर सकती है और अच्छे कारण के लिए - बहुत व्यावहारिक - बहुत व्यापक रूप से अपनाया - सब कुछ बकवास में बदल नहीं जाता है।

अपने दावे को दोहराने से यह और सच नहीं हो जाता। मैंने पहले ही कवर कर लिया है कि यह गलत क्यों है, और प्रचार कारणों से सुरक्षा से समझौता करना स्वीकार्य नहीं है।

हममें से कुछ के लिए कुकीज़ द्वारा प्रदान की गई बारीक ग्रैन्युलैरिटी के साथ सत्र को नियंत्रित करने के लिए लचीलापन अधिक लचीलापन देता है - यदि आप उपयोग के मामलों को नहीं देखते हैं तो ठीक है - मैं उम्मीद करता हूं कि यदि आप कई हाइब्रिड ऐप्स बनाते हैं जो आप करेंगे और शायद तब आप मेरे द्वारा प्रस्तुत किए गए कुछ बिंदुओं के प्रतिवादों को बेहतर ढंग से स्पष्ट करने में सक्षम होंगे I

वहाँ _is_ कोई "अधिक लचीलापन" नहीं है। दोबारा, अगर आपको लगता है कि वहाँ है, तो समझाएँ कि कैसे।

वैसे भी - आप मुझसे कहीं अधिक वाक्पटु हैं और अपनी स्थिति में स्पष्ट रूप से अडिग हैं

नहीं, मैं केवल यह अपेक्षा करता हूं कि कोई ठोस, तर्कपूर्ण, तकनीकी रूप से सही तर्क प्रदान करे, यदि वे मेरे विचार बदलना चाहते हैं। आपने ऐसा नहीं किया है।

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

... और यह इस तरह की भ्रांति का एक आदर्श उदाहरण होगा।

लब्बोलुआब यह है कि आपके आधे बयान मेरे मुंह में ऐसे शब्द डाल रहे हैं जो मैंने कभी नहीं बोले, न ही निहित, और न ही इरादा। दूसरा आधा सुरक्षा में अनावश्यक समझौता करने का तर्क देता है, या बिना किसी और आगे जाने के "अन्य लाभ" या "अन्य समाधान" होने के बारे में हाथ से चलने वाले दावे करता है।

सच कहूं तो मैं इससे थक गया हूं - मुझे नहीं लगता कि यह चर्चा रचनात्मक दिशा में जा रही है, और यह धागे को खराब कर रही है। मेरे द्वारा प्रत्युत्तर देने का एकमात्र कारण यह है कि आपके गैर-तर्कों द्वारा लोगों को गलत सूचना दिए जाने का जोखिम है।

यदि आप यह मानते रहना चाहते हैं कि उस धारणा का समर्थन करने के लिए कोई तकनीकी तर्क नहीं होने के बावजूद जेडब्ल्यूटी पवित्र कब्र है, तो यह आपकी पसंद है - लेकिन आप मुझे तब तक नहीं मनाएंगे जब तक कि आप वास्तविक तकनीकी तर्कों के साथ नहीं आते हैं, और उसी दावे को दोहराना जारी रखते हैं और फिर से किसी की मदद करने वाला नहीं है।

पूरी चर्चा पर ध्यान न देने वालों के लिए मेरे बिंदुओं को संक्षेप में प्रस्तुत करने के लिए:

• JWT को सत्रों के लिए नहीं, बल्कि हस्ताक्षरित दावों को स्थानांतरित करने के लिए डिज़ाइन किया गया है, आमतौर पर एकल-उपयोग।
• जेडब्ल्यूटी सत्र के लिए अनुपयुक्त है, क्योंकि टोकन को अमान्य करने में असमर्थता, पुराने डेटा के साथ समस्याएं, और इसे काम करने के लिए अप्रयुक्त कार्यान्वयन लिखने की आवश्यकता है। ये सुरक्षा मुद्दे हैं।
• "कुकीज़ बनाम जेडब्ल्यूटी" एक मान्य तुलना नहीं है; एक स्टोरेज मैकेनिज्म है जबकि दूसरा टोकन फॉर्मेट है। कुकीज़ वैकल्पिक नहीं हैं, चाहे आप JWT का उपयोग कर रहे हों या नहीं। किसी भी प्रकार के टोकन को कुकी के बाहर संग्रहीत करना एक सुरक्षा समस्या है।
• कभी-कभी आप स्टेटफुल सत्रों का उपयोग नहीं कर सकते क्योंकि आप बहुत बड़े पैमाने पर काम कर रहे हैं, और उन मामलों में JWT _can_ 'कम से कम खराब' विकल्प उपलब्ध है - लेकिन ये मामले दुर्लभ हैं, और जब तक आप किसी बड़ी साइट के लिए काम नहीं करते हैं रेडिट, आप शायद उनमें कभी नहीं चलेंगे।

(वैसे, Reddit स्टेटफुल सेशन का उपयोग करता है।)

मेरा मानना ​​​​है कि इस रेपो का उद्देश्य मोबाइल हाइब्रिड एसपीए के कार्यान्वयन का मार्ग प्रशस्त करना है और कुकी सत्रों के प्रतिस्थापन के रूप में जेडब्ल्यूटी का उपयोग एक सामान्य और लगभग मानक दृष्टिकोण है।
इसके लिए ड्राइवरों में से एक यह मुद्दा है कि कुकीज़ को एक डोमेन के लिए बाध्य किया जाता है जब एक एसपीए को वास्तव में विभिन्न प्लेटफार्मों पर कई डोमेन में सूक्ष्म सेवाओं तक पहुंच की आवश्यकता हो सकती है। JWT इस संदर्भ में कुकीज़ की सीमाओं के लिए एक साफ-सुथरा दृष्टिकोण है। OAUTH या OAUTH2 दृष्टिकोण का उपयोग सुरक्षा के दृष्टिकोण से अधिक मजबूत होगा, लेकिन जटिलता का परिचय देता है जो कई अनुप्रयोगों के लिए आवश्यक नहीं हो सकता है। JWT वाहक सत्र जो AUTH टोकन पर बातचीत पर निर्भर नहीं है, JWT का दुरुपयोग नहीं है, बल्कि सरलता हासिल करने के लिए कम सुरक्षित दृष्टिकोण का एक अनुप्रयोग है और उन अनुप्रयोगों के लिए जिन्हें अधिक से अधिक प्रदान की गई अतिरिक्त सुरक्षा की तुलना में तेजी से कार्यान्वयन से अधिक लाभ होता है। मजबूत दृष्टिकोण। एक ही समय में तेजी से कार्यान्वयन को सुव्यवस्थित करने के रूप में यह एकल उपयोग टोकन के लिए एक स्पष्ट प्रवास पथ प्रदान करता है फिर अन्य दृष्टिकोण।
सत्र कुकीज़ के प्रतिस्थापन के रूप में जेडब्ल्यूटी बियरर टोकन हेडर के उपयोग के खिलाफ कुछ प्रतिक्रिया और विट्रियल वास्तव में कुछ लोगों पर आधारित है जो उन्हें कुकीज़ पर एक विकास या सुधार के रूप में पेश करते हैं जो मैं मानता हूं कि ऐसा नहीं है। मैं आपसे मेरे उपयोग के मामलों पर विचार करने के लिए कहता हूं और आप कुकीज़ का उपयोग करके उनसे कैसे संपर्क करेंगे।
प्रमाणीकरण सत्र प्रबंधन के लिए जेडब्ल्यूटी का उपयोग सावधानी से किया जाना चाहिए और कमियों को स्पष्ट किया जाना चाहिए, हालांकि उन्हें हमेशा संदर्भ से बाहर इस्तेमाल किए जाने वाले बेकार प्रचार के रूप में खारिज करना भ्रामक और गलत है।
JWT का उपयोग करने का अर्थ है कि जब भी आप क्लाइंट से सर्वर से संपर्क करते हैं, तो आपको हर बार कुकीज़ को रीफ्रेश करने की आवश्यकता नहीं होती है। डेटाबेस की जांच किए बिना उचित आत्मविश्वास का आश्वासन दिया जा सकता है, हालांकि इस चेक को विस्तारित करना उतना ही आसान है जितना कि यह सत्र कुकीज़ का उपयोग कर रहा है।
जेडब्ल्यूटी का उपयोग करने का अर्थ है कि अवरुद्ध कुकीज़ वाले ग्राहकों को बैकफिल के रूप में छिपे हुए पोस्ट चर आदि का उपयोग करने के लिए वापस आने के लिए मजबूर नहीं किया जाएगा।
कई सेवाओं में जेडब्ल्यूटी का उपयोग करने से ऐसी सेवा की अनुमति मिलती है जिसके लिए प्रमाणीकरण की आवश्यकता नहीं होती है लेकिन यूआईडी जैसे साधारण डेटा फ़ील्ड की वैधता का कुछ संकेत चाहता है जिसे जेडब्ल्यूटी में लपेटा जा सकता है और पारित किया जा सकता है।
JWT दृष्टिकोण खुद को अधिक परिष्कृत OAUTH दृष्टिकोणों के लिए उधार देता है।
JWT REST अनुरोध क्रेडेंशियल पोस्ट किए बिना या सेवा तक पहुँचने से पहले कुकी के लिए अनुरोध की आवश्यकता के बिना किया जा सकता है जो REST/SPA कार्यान्वयन को सरल बना सकता है।
जब सुरक्षा की बात आती है तो बियरर हेडर या कुकी हेडर का उपयोग नाटकीय रूप से भिन्न नहीं होता है (डोमेन प्रतिबंधों को छोड़कर जो वैध रूप से अवांछनीय हो सकते हैं। (एनबी मैं आपके मुंह में शब्द नहीं डाल रहा हूं, लेकिन यह कहने की कोशिश कर रहा हूं कि आप क्या कह रहे हैं) सुरक्षा बदतर है)
जहां लंबे समय तक अनुपस्थिति सामान्य/अपेक्षित है जैसे कि मोबाइल एप्लिकेशन के साथ, कुकीज JWT दृष्टिकोण से कम वांछनीय हो सकती हैं। क्रेडेंशियल की स्वयं जांच के लिए एक स्पष्ट रास्ता होने से सर्वर के साथ जांच किए बिना व्यवहार को सुविधाजनक बनाया जा सकता है।
यदि आप स्वीकार करते हैं कि ऐसे सत्रों के लिए उपयोग के मामले हैं जिनकी ऑफ़लाइन अवधि लंबी हो सकती है तो सत्र आवश्यक रूप से स्टेटफुल नहीं हैं।
यदि आप यह स्वीकार करने में सक्षम हैं कि क्लाइंट और सर्वर के परिप्रेक्ष्य से कई राज्यों के साथ सत्र सफलतापूर्वक मौजूद हो सकते हैं तो शायद आप उन मामलों का उपयोग करने के करीब आ सकते हैं जिनमें सर्वर के साथ लंबे समय तक गैर-कनेक्टिविटी की अवधि शामिल है (उदाहरण के लिए बैच अपडेट के लिए उपयोगकर्ता डेटा एकत्र करना पुन: कनेक्ट करने पर)। ऐसे मामले हैं जहां क्लाइंट यह जानकर अधिक प्रभावी ढंग से काम कर सकता है कि सत्र समाप्त हो गया है और डेटा की एक और परत को प्रबंधित किए बिना एक ताज़ा करने की आवश्यकता है। पासवर्ड बदलने के बाद भी JWT को सत्र सत्यापन के रूप में उपयोग करने में सक्षम होना आदि कुछ मामलों में उपयोगी हो सकता है ताकि डेटा को व्यावसायिक तर्क परत पर पारित किया जा सके और यह तय किया जा सके कि अनुरोध को कैसे स्वीकार किया जाए।
आप मुझे बताते रहते हैं कि कुकीज़ सुरक्षित हैं जिन्हें मैं ब्राउज़र आदि में कार्यान्वयन के लिए मानता हूं - एक ब्राउज़र के बाहर मैं यह देखने में विफल रहता हूं कि वे स्वाभाविक रूप से अधिक सुरक्षित क्यों हैं - शायद आप विस्तृत कर सकते हैं?
एसपीए/हाइब्रिड ऐप्स में कुकीज़ पर निर्भरता जरूरी नहीं कि केवल शुरुआती स्थिति हो - ब्राउज़र द्वारा कुकी हैंडलिंग पर निर्भर होने से आप देशी के करीब नहीं आते हैं बल्कि UIWebView या जो कुछ भी पर निर्भरता का परिचय देते हैं और मुझे विश्वास नहीं है कि यह हमेशा रहेगा मेरी अपेक्षा के अनुरूप व्यवहार करें।
किसी ऐप के निष्पादन जीवन के लिए टोकन को आवश्यक रूप से जारी रखे बिना स्मृति में रखा जा सकता है - यह वास्तव में कुकीज़ की अखंडता पर निर्भर होने जैसा नहीं है - कम से कम स्टोरेज अनुमतियों पर आईओएस में अधिक बारीक नियंत्रण है जो ब्राउज़र से परे मौजूद है और यह मुझे ब्राउज़र भंडारण दृष्टिकोण से बाध्य होने की तुलना में अधिक उपयुक्त मानता है।
कुकीज़ वास्तव में वैकल्पिक हैं - ऐसा कोई कानून नहीं है जो बताता हो कि आपको केवल कुकीज़ का उपयोग करना चाहिए।
सर्वर से सत्र को अलग करना कुछ मामलों में एक बुरी बात हो सकती है लेकिन हमेशा नहीं - जेडब्ल्यूटी के उपयोग सहित आधुनिक दृष्टिकोण नई चिंताओं को पेश करते हैं बल्कि नई लचीलापन भी पेश करते हैं और इस लचीलेपन में कम से कम खराब दृष्टिकोण शामिल नहीं होते हैं।

मेरी स्थिति को संक्षेप में प्रस्तुत करने के लिए:
एक सत्र सत्र समाधान के हिस्से के रूप में जेडब्ल्यूटी का उपयोग हमेशा सत्र कुकीज़ द्वारा नहीं किया जाता है
JWT सत्र के लिए उपयुक्त है यदि आप लाभों के बारे में जानते हैं और एक कारण है कि सरलीकृत अमान्यकरण की आवश्यकता नहीं है।
कुकीज़ एकमात्र समाधान नहीं हैं।
स्टेटलेस सत्र के लिए बड़े पैमाने पर एकमात्र उपयोग मामला नहीं है - डोमेन/सेवाओं में प्रमाणित करने के लिए जेडब्ल्यूटी हेडर का उपयोग करना सत्र कुकीज़ के विकल्प के रूप में उनका उपयोग करने का एक वैध कारण है।

मैं आपसे मेरे उपयोग के मामलों पर विचार करने के लिए कहता हूं और आप कुकीज़ का उपयोग करके उनसे कैसे संपर्क करेंगे।

ज़रूर।

JWT का उपयोग करने का अर्थ है कि जब भी आप क्लाइंट से सर्वर से संपर्क करते हैं, तो आपको हर बार कुकीज़ को रीफ्रेश करने की आवश्यकता नहीं होती है।

सत्र कुकीज़, जेडब्ल्यूटी युक्त कुकीज़, _और_ जेडब्ल्यूटी टोकन के लिए यह वही है - यदि वे समाप्त होने वाले हैं तो आपको केवल उन्हें स्पष्ट रूप से 'रीफ्रेश' करने की आवश्यकता है। यहां कोई अंतर नहीं है।

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

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

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

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

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

JWT दृष्टिकोण खुद को अधिक परिष्कृत OAUTH दृष्टिकोणों के लिए उधार देता है।

OAuth एकल-उपयोग टोकन का उपयोग करता है। यह सत्रों के लिए प्रतिस्थापन नहीं है। फिर से, मेरी पिछली पोस्ट का संपादन देखें।

JWT REST अनुरोध क्रेडेंशियल पोस्ट किए बिना या सेवा तक पहुँचने से पहले कुकी के लिए अनुरोध की आवश्यकता के बिना किया जा सकता है जो REST/SPA कार्यान्वयन को सरल बना सकता है।

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

जब सुरक्षा की बात आती है तो बियरर हेडर या कुकी हेडर का उपयोग नाटकीय रूप से भिन्न नहीं होता है (डोमेन प्रतिबंधों को छोड़कर जो वैध रूप से अवांछनीय हो सकते हैं।

यहां कोई तर्क नहीं देख रहा है।

जहां लंबे समय तक अनुपस्थिति सामान्य/अपेक्षित है जैसे कि मोबाइल एप्लिकेशन के साथ, कुकीज JWT दृष्टिकोण से कम वांछनीय हो सकती हैं। क्रेडेंशियल की स्वयं जांच के लिए एक स्पष्ट रास्ता होने से सर्वर के साथ जांच किए बिना व्यवहार को सुविधाजनक बनाया जा सकता है।

यह एक गैर-लाभ है - जब तक आप किसी सर्वर के साथ संचार करने का इरादा नहीं रखते हैं, तब तक आपको टोकन की आवश्यकता नहीं है, इसलिए आप केवल अनुरोध करने का प्रयास कर सकते हैं और ऐसा होने पर 403 से निपट सकते हैं। सर्वर से किसी ऐसी चीज़ के लिए पूछने से बचने की कोशिश करना जिसमें स्वाभाविक रूप से सर्वर से बात करना शामिल है (अर्थात्, एक प्रमाणित अनुरोध करना) का कोई मतलब नहीं है।

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

एसपीए/हाइब्रिड ऐप्स में कुकीज़ पर निर्भरता जरूरी नहीं कि केवल शुरुआती स्थिति हो - ब्राउज़र द्वारा कुकी हैंडलिंग पर निर्भर होने से आप देशी के करीब नहीं आते हैं बल्कि UIWebView या जो कुछ भी पर निर्भरता का परिचय देते हैं और मुझे विश्वास नहीं है कि यह हमेशा रहेगा मेरी अपेक्षा के अनुरूप व्यवहार करें।

यह नहीं है। कोई भी उचित HTTP पुस्तकालय - ब्राउज़र या नहीं - कुकीज़ का समर्थन करेगा। कुकीज़ _किसी भी तरह से_ ब्राउज़र के लिए विशिष्ट नहीं हैं, वे किसी भी अन्य की तरह एक HTTP सुविधा हैं।

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

मैंने अभी भी ऐसे 'लचीलेपन' का कोई ठोस उदाहरण नहीं देखा है।

सत्र समाधान के भाग के रूप में JWT का उपयोग हमेशा सत्र कुकीज़ द्वारा नहीं किया जाता है

यह बहुत अस्पष्ट बयान है। आप सत्र कुकीज़ को _entire_ समाधान के रूप में उपयोग करने के लिए समाधान के _part_ के रूप में JWT का उपयोग करने की तुलना कर रहे हैं। ये विपरीत नहीं हैं - कई जटिल आर्किटेक्चर के लिए सत्र कुकीज़ और एकल-उपयोग वाले JWT टोकन दोनों के संयोजन की आवश्यकता होगी, उदाहरण के लिए SSO सिस्टम या वितरित आर्किटेक्चर के लिए।

JWT सत्र के लिए उपयुक्त है यदि आप लाभों के बारे में जानते हैं और एक कारण है कि सरलीकृत अमान्यकरण की आवश्यकता नहीं है।

नहीं, जब आप सत्र कुकीज़ के साथ आवश्यकताओं को पूरा नहीं कर सकते हैं तो JWT टोकन एक _अंतिम उपाय_ हैं।

कुकीज़ एकमात्र समाधान नहीं हैं।

तकनीकी रूप से सही।

स्टेटलेस सत्र के लिए बड़े पैमाने पर एकमात्र उपयोग मामला नहीं है।

यह _is_ एकमात्र यूज़केस है जिसके बारे में मुझे जानकारी है, और मैंने इस पूरे थ्रेड में उल्लिखित किसी अन्य मान्य व्यक्ति को नहीं देखा है। ध्यान रखें कि मैं विशेष रूप से स्टेटलेस _sessions_ के बारे में बात कर रहा हूं, स्टेटलेस टोकन _in सामान्य_ के बारे में नहीं।

मैं आपसे यह पूछता हूं - मैं एक ऐसे एप्लिकेशन को कैसे तैनात करूं जो 3 अलग-अलग सेवाओं (शायद विभिन्न कंटेनर बुनियादी ढांचे आदि पर) का उपयोग करता है और उन्हें सत्र कुकीज़ पर निर्भर ऐप में एकीकृत करता है? अगर मैं एक सामान्य सेवा स्थापित करता हूं और इसे किसी अन्य सेवा से अलग करना चाहता हूं तो साझा प्रॉक्सी कुकी सत्र हैंडलर चलाने का सबसे अच्छा तरीका है? क्या यह बढ़त का मामला है?
मेरे सत्र को ट्रैक करने के लिए लंबे समय से चल रहे JWT का उपयोग करने की तुलना में कुकीज़ मुझे अधिक सुरक्षा, लचीलापन, मानकों का अनुपालन कैसे प्रदान करती हैं। यह मानते हुए कि मैं मांग पर सत्र को समाप्त करने में सक्षम होने के बारे में नहीं चाहता या परवाह नहीं करता (हालांकि यह वास्तव में कुकीज़ का एक अंतर्निहित लाभ नहीं है बल्कि अनुरोधों को संभालने में है), कि मैं प्रत्येक पोस्ट के साथ बियरर हेडर का उपयोग कर रहा हूं और जवाब दे रहा हूं एक सत्र प्राप्त करने के लिए एक प्रांप्ट प्रॉम्प्ट/पोस्ट के साथ विफलता जेडब्ल्यूटी सभी शीर्षकों में शामिल होने के लिए - मैं बेवकूफ हो सकता हूं लेकिन मुझे नहीं लगता कि यह कैसे कम सुरक्षित है? कुकी विवरण हाइब्रिड ऐप में उतने ही उपलब्ध हैं जितने कि टोकन हैं, हालांकि दृढ़ता पर कम नियंत्रण है ... मुझे लगता है कि मुझे नहीं पता कि यह इतना बुरा दृष्टिकोण क्यों है। निश्चित रूप से आपको जेडब्ल्यूटी प्राप्त करने के लिए प्रमाण-पत्र प्रदान करने की आवश्यकता है लेकिन आप इसे एक बार करते हैं - प्रत्येक सेवा पर नहीं।

मैं आपसे यह पूछता हूं - मैं एक ऐसे एप्लिकेशन को कैसे तैनात करूं जो 3 अलग-अलग सेवाओं (शायद विभिन्न कंटेनर बुनियादी ढांचे आदि पर) का उपयोग करता है और उन्हें सत्र कुकीज़ पर निर्भर ऐप में एकीकृत करता है?

निर्भर करता है कि 3 सेवाएं क्या करती हैं। क्या आप विस्तार कर सकते हैं?

अगर मैं एक सामान्य सेवा स्थापित करता हूं और इसे किसी अन्य सेवा से अलग करना चाहता हूं तो साझा प्रॉक्सी कुकी सत्र हैंडलर चलाने का सबसे अच्छा तरीका है? क्या यह बढ़त का मामला है?

आपके पास ऑथेंटिकेशन सर्विस इश्यू एक सिंगल-यूज़ जेडब्ल्यूटी टोकन होगा जो सफल प्रमाणीकरण को इंगित करता है, वैकल्पिक रूप से आपके आर्किटेक्चर के आधार पर उपयोगकर्ता के लिए 'प्रोफाइल जानकारी' सहित। फिर, आवेदन के आधार पर:

1. यदि एक नियमित वेबसाइट: प्रमाणन सेवा एप्लिकेशन सर्वर पर एक प्रमाणीकरण पृष्ठ पर पुनर्निर्देशित करती है, उदा। JWT टोकन को क्वेरी पैरामीटर के रूप में पास करना। एप्लिकेशन सर्वर टोकन को मान्य करता है, और उपयोगकर्ता को एक सत्र कुकी देता है।
2. यदि कोई एसपीए: प्रमाणन सेवा अपनी (JSON?) प्रतिक्रिया में उत्पन्न टोकन लौटाती है। फ्रंटएंड एप्लिकेशन एप्लिकेशन सर्वर के प्रमाणीकरण एंडपॉइंट के लिए एक HTTP अनुरोध करता है, जिसमें एक पैरामीटर के रूप में टोकन शामिल है, और एप्लिकेशन सर्वर द्वारा सत्यापन के बाद, बदले में एक सत्र कुकी प्राप्त करता है।
3. यदि एक स्टैंडअलोन एप्लिकेशन (डेस्कटॉप या मोबाइल): एक एसपीए के लिए पसंद है, लेकिन एक ब्राउज़र में फ्रंटएंड एप्लिकेशन के बजाय एक HTTP लाइब्रेरी का उपयोग करना जो कुकीज़ का समर्थन करता है।

दोनों ही मामलों में, JWT टोकन केवल 5 मिनट (घड़ी के तिरछे खाते के लिए) के लिए मान्य होगा, और एक बार उपयोग किया जाएगा - इसे एप्लिकेशन सर्वर पर एक सत्र के लिए एक्सचेंज करने के लिए। यदि आप टोकन में प्रोफ़ाइल जानकारी शामिल करते हैं, तो प्रमाणीकरण सेवा एप्लिकेशन से पूरी तरह से अलग हो जाती है।

संपादित करें: स्टैंडअलोन एप्लिकेशन केस जोड़ा गया।

आइए मान लें कि हम एसपीए/हाइब्रिड मोबाइल ऐप विकास परिदृश्य में हैं। यह भी मान लें कि हम सत्र के लिए केवल JWT का उपयोग कर रहे हैं - प्रमाणीकरण और वाहक टोकन के साथ OUATH नहीं - बस लॉगिन करें और वाहक टोकन प्राप्त करें।
आइए कल्पना करें कि हमारे पास प्रत्येक सत्र में सभी 3 सेवाओं के लिए हर 5-15 सेकंड में अनुरोध करने के साथ एक वास्तविक समय का आवेदन है। कई उपयोगकर्ता त्वरित स्थिति की जांच के लिए या जीआईएस डेटा या कुछ पोस्ट करने के लिए लॉग इन करते हैं, इसलिए औसत उपयोग का समय 1 मिनट से कम है, लेकिन ऐप शुरू करना चाहते हैं - इसे बंद करें - बिना क्रेडेंशियल आदि के 3 दिन बाद पुनरारंभ करें। (विवरण जोड़ना जो यहां काफी हद तक अप्रासंगिक है लेकिन चीजें जो मुझे कुकीज़ से दूर कर देंगी)

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

आइए मान लें कि उन सभी को उचित विश्वास की आवश्यकता है कि उपयोगकर्ता वही है जो वे कहते हैं कि वे हैं।
मेरा समाधान क्रेडेंशियल पोस्ट के जवाब में एक जेडब्ल्यूटी टोकन उत्पन्न करना होगा जो प्रमाणीकरण के लिए HTTP शीर्षलेख के भीतर सभी सेवाओं में उपयोग किया जाता है - सभी सेवाओं में साझा जेडब्ल्यूटी रहस्य के साथ सत्यापन किया जा रहा है।
प्रमाणीकरण सेवा टोकन उत्पन्न करती है और इसे लॉगिन पर वापस कर देती है। टोकन विभिन्न डोमेन पर अन्य सभी सेवाओं के शीर्षलेख अनुरोधों में शामिल है। यदि कुकीज़ का उपयोग कर रहे हैं तो हमें प्रत्येक डोमेन के लिए नई कुकीज़ स्थापित करने की आवश्यकता है। जब मैं आत्मविश्वास से JWT पर निर्भर हो सकता हूं, तो मैं प्राप्त प्रत्येक http के लिए कुकी को मान्य करने या प्राप्त करने के लिए नए अनुरोध करने वाली सेवाओं को क्यों चाहता हूं? अगर मेरे पास 5 सेवाएं हैं तो मुझे अब 5 अलग-अलग सत्र कुकीज़ का प्रबंधन करने और इन सभी के बीच समन्वय सुनिश्चित करने की आवश्यकता है। कई मामलों में यह सही दृष्टिकोण हो सकता है लेकिन कई में यह मुझे किसी ऐसी चीज के लिए अत्यधिक जटिल लगता है जो त्वरित और सरल है और गंभीर सुरक्षा छेद को उजागर नहीं करता है जिसे मैं स्पष्ट रूप से देख सकता हूं।
JWT समय सीमा को सीमित क्यों करें? कुकीज़ पारंपरिक रूप से अल्पकालिक होती हैं क्योंकि वे नियमित सर्वर संपर्क मानती हैं - क्या होगा यदि मैं जल्दी से समाप्त नहीं होना चाहता, लेकिन पुराने सत्र लंबे समय तक चलने से खुश हूं क्योंकि मैं तय करता हूं कि पुन: प्रमाणीकरण का व्यापार बंद एक बड़ा जोखिम है।

अगर मैं आपकी स्थिति में सही ढंग से समझता हूं तो मुझे 3 के बजाय हर अवधि के आसपास 9 अनुरोध बाउंस हो गए हैं। स्थापित सत्रों की पुष्टि करने के लिए मेरे पास एक ऑथ सर्वर है। मेरे पास अधिक कोड और अधिक चलने वाले हिस्से हैं। मुझे प्रत्येक अवधि में सत्रों को समाप्त करने में सक्षम होने का लाभ मिलता है, लेकिन क्या होगा यदि इसकी आवश्यकता नहीं है। क्या होगा यदि उपयोगकर्ता को समाप्त किए जाने के बाद 48 घंटों के लिए पोस्ट किए गए डेटा को प्राप्त करने की मुझे परवाह नहीं है और नए अनुरोधों के लिए ऑथ सर्वर का उपयोग करने के बाद भी मैं वह फ़िल्टर कर सकता हूं जिसकी मुझे आवश्यकता नहीं है?

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

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

अगर मैं आपके प्रस्तावित आर्किटेक्चर के साथ संरेखित करता हूं तो मुझे वास्तव में कई कुकीज़ में टाइमआउट से जूझना होगा। उदाहरण के तौर पर यदि क्लाइंट लॉग इन करता है और एक अधिकृत सत्र कुकी प्राप्त करता है जो 1 घंटे में समाप्त हो जाती है
और फिर 40 मिनट बाद वे इस सत्र कुकी मूल्य को हमारी पहली सेवा में पोस्ट करते हैं, जो तब स्थानीय डोमेन कुकी जारी करने से पहले प्रमाणीकरण सर्वर से पूछताछ करता है, क्या हम आंतरिक मूल प्रमाणीकरण कुकी समाप्ति को हैक करते हैं या क्या हम सेवा कुकी पर 20 मिनट का टाइमआउट सेट करते हैं और जब यह समाप्त हो जाता है तो प्रमाणीकरण कुकी का रीफ्रेश ट्रिगर करें। जब तक मुझे एक स्पष्ट समाधान नहीं मिल रहा है, यह आसानी से स्पेगेटी के एक बड़े ढेर में बदल सकता है जिसे एक एकल जेडब्ल्यूटी का उपयोग करके पूरी तरह से टाला जा सकता है, जिसे किसी भी सेवा के माध्यम से रीफ्रेश किया जा सकता है (यह समझना कि यह संभवतः टोकन को कैसे बढ़ाता है) life ) या प्रमाणीकरण सर्वर के माध्यम से ताज़ा करने की आवश्यकता है।

मैं पुराने डेटा के दृष्टिकोण पर चर्चा कर सकता था लेकिन इस उपयोग के मामले में समस्या का दायरा पुराने प्रमाण-पत्रों (ऑथ सर्वर के परिप्रेक्ष्य से) को अमान्य करने पर भरोसा नहीं करता है, इसलिए यह प्रासंगिक नहीं होगा।

यह मेरी समझ है कि हम आपके दावे पर चर्चा कर रहे हैं कि एक प्रमाणित सत्र प्रबंधन दृष्टिकोण के रूप में जेडब्ल्यूटी का उपयोग स्वाभाविक रूप से निम्न और गलत है बनाम सत्र कुकीज़ के उपयोग के लिए एक हाइब्रिड मोबाइल एप्लिकेशन के भीतर क्रॉस डोमेन सेवाओं के लिए एक प्रमाणित सत्र प्रबंधन दृष्टिकोण के रूप में चलाने के लिए। साख की पुन: आपूर्ति के बिना उपकरण रुक-रुक कर।

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

सेवाएं लगभग कोई मायने नहीं रखतीं - सुनिश्चित नहीं हैं कि आप किस बारे में बात कर रहे हैं?

स्टेटफुल और स्टेटलेस सेवाओं के बीच अंतर है।

हम कहते हैं [...]

यह वर्णन कर रहा है कि आप समस्या का समाधान कैसे करेंगे, न कि समस्या क्या है _is_। यह उपयोगी नहीं है जब मुझसे यह समझाने के लिए कहा जाए कि इसे सत्रों के साथ कैसे प्राप्त किया जाए, क्योंकि यह पहले से ही मानता है कि आप सत्रों का उपयोग नहीं कर रहे हैं। इसके बजाय समस्या का वर्णन करें।

जब मैं आत्मविश्वास से JWT पर निर्भर हो सकता हूँ?

आप नहीं कर सकते।

अगर मेरे पास 5 सेवाएं हैं तो मुझे अब 5 अलग-अलग सत्र कुकीज़ का प्रबंधन करने और इन सभी के बीच समन्वय सुनिश्चित करने की आवश्यकता है।

संभावना नहीं है। स्टेटफुल बनाम स्टेटलेस सेवाओं के बारे में मेरी टिप्पणी देखें।

कई मामलों में यह सही दृष्टिकोण हो सकता है लेकिन कई में यह मुझे किसी ऐसी चीज के लिए अत्यधिक जटिल लगता है जो त्वरित और सरल है और गंभीर सुरक्षा छेद को उजागर नहीं करता है जिसे मैं स्पष्ट रूप से देख सकता हूं।

प्रमाणीकरण और सत्र प्रबंधन, विशेष रूप से वितरित आर्किटेक्चर में, _is_ जटिल। एक कारण है कि इंजीनियरों ने अतीत में जहां भी संभव हो, वितरित आर्किटेक्चर से परहेज किया है। इस पर "बस JWT का उपयोग करें" ग्लॉस और डेटा की गतिहीनता और सत्र अमान्यता को पूरी तरह से अनदेखा करके, यह वास्तव में जितना आसान है, उससे अधिक आसान होने का दिखावा करता है।

सुरक्षा छेद हैं, और मैंने उन्हें समझाने के कई प्रयास किए हैं - कि आप उन्हें स्पष्ट रूप से नहीं देख सकते हैं, ऐसा कुछ नहीं है जिसके बारे में मैं कुछ भी कर सकता हूं, यदि आप उन हिस्सों के बारे में विशिष्ट प्रश्न नहीं पूछते हैं जो आपके लिए अस्पष्ट हैं .

JWT समय सीमा को सीमित क्यों करें?

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

कुकीज़ पारंपरिक रूप से अल्पकालिक होती हैं क्योंकि वे नियमित सर्वर संपर्क मानती हैं - क्या होगा यदि मैं जल्दी से समाप्त नहीं होना चाहता, लेकिन पुराने सत्र लंबे समय तक चलने से खुश हूं क्योंकि मैं तय करता हूं कि पुन: प्रमाणीकरण का व्यापार बंद एक बड़ा जोखिम है।

सत्र को रीफ्रेश करने में कोई जोखिम नहीं है।

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

वे एक मजबूत प्रमाणीकरण प्रणाली का उतना ही महत्वपूर्ण हिस्सा हैं जितना कि अन्य सभी बिंदुओं का उल्लेख किया गया है। उनकी उपेक्षा करना कोई विकल्प नहीं है। और फिर, यह "कुकीज़" के बारे में _not_ है, यह सत्रों के बारे में है।

सत्रों के लिए, नहीं, वही मुद्दे _not_ लागू होते हैं; एक केंद्रीकृत/स्टेटफुल सत्र स्टोर का मतलब है कि डेटा बिल्कुल भी पुराना नहीं होता है और प्रोफ़ाइल जानकारी किसी भी बिंदु पर पुनर्प्राप्त की जा सकती है, और घड़ी का तिरछा किसी भी सीमित-वैधता टोकन के लिए एक मुद्दा है जो विभिन्न प्रणालियों के बीच आदान-प्रदान किया जाता है।

ऐसा लगता है कि हम JWT के प्रति आपकी आपत्ति को संक्षेप में प्रस्तुत कर सकते हैं क्योंकि सत्र प्रबंधन दृष्टिकोण आपके लिए सत्र की परिभाषा के प्रति लगाव कम कर सकता है जिसके लिए प्रति अनुरोध निरसन की आवश्यकता होती है (और कुछ अन्य विशेषताएं जो परंपरागत रूप से यह सुनिश्चित करने का हिस्सा हैं कि उपयोगकर्ता अधिकृत है) एक्सेस करने के लिए) और उन्हें रिफ्रेश करने से जुड़े खतरे (यदि उन्हें इंटरसेप्ट किया गया है)। वितरित प्रसंस्करण नया मानदंड है - कई सेवाएं बहुत आम हैं - अगर हमें बहु-सेवा वास्तुकला के लिए इस तरह के दृष्टिकोण का उपयोग करना है तो हमें परिणामों को पूरी तरह से समझने की जरूरत है। वितरित डेटाबेस लंबे समय से मौजूद हैं। डीएनएस जैसे वितरित डेटा स्टोर शुरू से ही मौजूद हैं। कभी-कभी वास्तुकला की सादगी मौजूदा प्रमुख मानक को अपनी डिजाइन सीमाओं से परे निचोड़ने की कोशिश करने से अधिक लाभ प्रदान करती है। यदि हम अपने सेवा अनुरोध सत्रों में लेन-देन संबंधी ACID मुद्दों के बारे में जानते हैं, तो कोई कारण नहीं है कि हमें सेवाओं को प्रमाणित करने के लिए JWT सत्र प्रबंधन दृष्टिकोण को अपनाना नहीं चाहिए ताकि हम बिना किसी बाधा के पूरी तरह से संभावनाओं का दोहन कर सकें, यदि हम जोर देते हैं तो यह एक जटिल बुनियादी ढांचा बन जाता है। कठिन बाधाओं पर और बेहतर समाधान के रूप में शू-हॉर्न सत्र कुकीज़ का प्रयास करें।
@ joepie91 - जहां उपयुक्त हो आप प्राथमिक लेख के लिए कुकी सत्र प्रमाणीकरण का अच्छी तरह से उपयोग कर सकते हैं और जेडब्ल्यूटी को रीफ्रेश करने के लिए इसकी आवश्यकता होती है। फिर से - क्रॉस डोमेन सत्र सेवा पहुंच के लिए जेडब्ल्यूटी का उपयोग समाधान के हिस्से के रूप में किया जा सकता है और कुकी सत्र का उपयोग उचित होने पर भी किया जा सकता है। मुद्दा यह है कि जेडब्ल्यूटी सत्र प्रबंधन के हिस्से के रूप में - यहां तक ​​​​कि सेवाओं के सबसेट तक पहुंचने के लिए - क्या मैं एक बुरे दृष्टिकोण पर विश्वास नहीं करता जिसकी कोई भूमिका नहीं है।
https सत्र कुकीज़ भी जोखिमों के साथ आती हैं - यह आश्चर्य की बात है कि कितनी साइटों में ssl फ़्लैग अनसेट है और SSL संचार करते समय कुकी को प्लेनटेक्स्ट के रूप में पास कर देता है। क्या यह कुकी सत्र को खतरनाक बनाता है?
मुझे लगता है कि सबसे बड़ा जोखिम यह है कि कोडर टोकन को गलत सर्वर पर भेजने की अनुमति देता है और टोकन प्रभावी रूप से किसी तृतीय पक्ष को इन माध्यमिक उपयोगकर्ता संसाधनों तक पहुंचने की अनुमति देता है। इसे कहीं बड़े लाल अक्षरों में चिह्नित किया जाना चाहिए और यह सुनिश्चित करने के लिए डेवलपर पर एक मजबूत जिम्मेदारी डालता है कि ऐसा न हो। डेवलपर को यह सुनिश्चित करने के लिए उचित कदम उठाने चाहिए कि आवश्यक सुरक्षा उपाय किए गए हैं और इस तरह के एक रेपो को इनमें से कुछ दृष्टिकोणों की व्याख्या करनी चाहिए और उन्हें उदाहरणों में शामिल करना चाहिए। मेरे विचार से गैर-महत्वपूर्ण सेवाओं के लिए क्रॉस डोमेन समय सीमित सेवा प्रमाणीकरण के लचीलेपन के लिए भुगतान करने के लिए यह एक स्वीकार्य मूल्य है।
एक जटिल समाधान को तैयार करने में इसके अंत में सत्र कुकीज़ शामिल होने की संभावना है और जहां उपयुक्त हो, एक बार बंद टोकन आदि को शामिल करने के लिए इसे बढ़ाया जा सकता है। मुद्दा यह है कि यह सामान संभव है और जहां ऐसे स्थान हैं जहां यह गलत हो सकता है और जोखिमों को उजागर कर सकता है, यह कई मामलों में समृद्ध और दुबला अनुप्रयोग बनाने का अवसर प्रदान करता है और इस कारण से मुझे विश्वास नहीं है कि इस रेपो को सुझाव के अनुसार बिन किया जाना चाहिए इश्यू लॉगर द्वारा।
जेडब्ल्यूटी को सत्र स्ट्रिंग के रूप में उपयोग करके दोनों दुनिया के सर्वश्रेष्ठ प्राप्त करने का प्रयास करने का झुकाव मुद्दों को पेश करता है - सबसे अधिक संभावित रूप से विरोधाभासी टाइमआउट/टीटीएल अवधि। यह उन्हीं डोमेन एक्सेस प्रतिबंधों को भी लागू करता है जिनसे हम पहली बार में बचने की कोशिश कर रहे थे ताकि मूल उदाहरण में लोगों को यह पूछने के लिए प्रेरित किया जा सके कि पहली जगह में जेडब्ल्यूटी का उपयोग क्यों करें?

निर्भरता के रूप में JS का उपयोग बहुत मामूली है - हाइब्रिड मोबाइल SPA के संदर्भ में यह संभावना नहीं है कि आपको JS मुक्त क्लाइंट को समायोजित करने की आवश्यकता है। यह सुझाव देते हुए कि यह एक मुद्दा है, जबकि इसी तरह यह दावा करते हुए कि रेडिस सत्र भंडारण के लिए एक कुशल विकल्प प्रदान करता है, थोड़ा विरोधाभासी लगता है।
JWT में समाप्ति इस मायने में बेकार नहीं है कि यह एक सत्र टाइमआउट प्रदान करता है जिसे या तो ताज़ा करके नियंत्रित किया जाना चाहिए (ठीक उसी तरह जैसे कुकी सत्र ताज़ा होते हैं) या फिर से प्रमाणीकरण की आवश्यकता होती है। जेडब्ल्यूटी पर हस्ताक्षर होने से यह सुनिश्चित होता है कि इसके साथ छेड़छाड़ नहीं की गई है और इस प्रकार लगातार स्टोरेज सर्वर-साइड के खिलाफ सत्यापन के लिए पूर्ण आवश्यकता को समाप्त कर दिया गया है, हालांकि यह वांछनीय होने पर किया जा सकता है और कुकी सत्रों के समान परिणाम प्राप्त करता है, बिना ज्यादा राय वाले कार्यान्वयन के और यदि उपयुक्त हो तो क्रॉस डोमेन का उपयोग करने की क्षमता। एक हाइब्रिड मोबाइल ऐप में, स्थानीय स्टोरेज में कुकीज़ या JWT का भंडारण फिर से अधिक नियंत्रण देता है। ब्राउज़र कार्यान्वयन की सुरक्षा पर स्थानीय भंडारण के उपयोग पर आपत्ति विक्रेता में विश्वास और इन क्रेडेंशियल्स को संभालने की स्वीकृति का विषय है।
लचीलापन कई मोबाइल हाइब्रिड एसपीए डेवलपर्स के लिए उपयोगी है, लेकिन यह समझने की आवश्यकता है कि सीमाएं क्या हैं।
जेडब्ल्यूटी को केवल हस्ताक्षर कुंजी को बदलकर अमान्य किया जा सकता है और फिर से यह लचीलापन देता है - आप सेवाओं में एक सामान्य साझा निजी हस्ताक्षर कुंजी का उपयोग कर सकते हैं या प्रति उपयोगकर्ता सत्र यादृच्छिक उत्पन्न कर सकते हैं और सत्र कुकीज़ के अस्वीकार लाभों का एहसास कर सकते हैं।
लगभग सभी आधुनिक जेएस ढांचे जेडब्ल्यूटी का समर्थन करते हैं और एक प्रमुख मंच ढूंढना मुश्किल होगा जो नहीं करता है - कुछ को वास्तव में शायद नहीं करना चाहिए (वर्डप्रेस जेडब्ल्यूटी प्लगइन .. हम्म .. देखा नहीं गया लेकिन मुझे परेशान करता है)।
JWT के उपयोग में OAUTH में पृष्ठभूमि और कुकी सत्रों का उपयोग करने के ट्रेडऑफ़ और लाभ शामिल होने चाहिए। मेरे लिए कई सेवाओं का उपयोग करने वाले औसत मोबाइल हाइब्रिड डेवलपर्स के लिए वास्तविक कार्य लाभ हैं लेकिन ऐसे जाल हैं जिनमें गिरना आसान है। पूरी तरह से स्पष्ट करने के लिए हमें कई उदाहरणों की आवश्यकता हो सकती है।

प्राधिकरण के लिए टोकन के रूप में एक जेडब्ल्यूटी का उपयोग करने के लिए मेरा _मूल तर्क यह है कि एक जेडब्ल्यूटी की पुष्टि सीपीयू-बाउंड है (_मेरा "पुराना" लैपटॉप प्रति सेकंड 180k जेडब्ल्यूटी सत्यापित कर सकता है_) इसके विपरीत यदि हम एक साधारण टोकन का उपयोग करना चाहते हैं और इसे देखना है मेमोरी (या एक डेटाबेस) में ऑपरेशन I/O-बाउंड (_या बदतर नेटवर्क-बाउंड_) होगा जो _काफी धीमा_ होगा।
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

हमारी सत्र प्रबंधन प्रणाली _first_ जाँच करती है कि JWT यह सत्यापित करके मान्य है कि यह हमारी कुंजी का उपयोग करके _हस्ताक्षरित_ था - और एक संदेश को _early_ अगर यह नहीं था - और _then_ जांचता है कि क्या सत्र अभी तक अमान्य नहीं हुआ है (उदाहरण के लिए उपयोगकर्ता द्वारा लॉग आउट करके) .

मुझे पता है कि जेडब्ल्यूटी को प्राधिकरण हेडर में टोकन के रूप में उपयोग करने के लिए _designed_ नहीं किया गया हो सकता है, लेकिन मुझे नहीं लगता कि मैं पूरी तरह से समझता हूं कि यह एक "बुरा विचार" क्यों है, जो अन्य सत्र-प्रबंधन प्रणालियों की तुलना में _faster_ है ...

नोट: मैं अब भी सहमत हूं कि "नो कुकीज" एंगल इस रीडमी/ट्यूटोरियल को शुरू करने का सही तरीका नहीं है। मैं