जेडब्ल्यूटी: जब उपयोगकर्ता एक नया टैब खोलता है तो जीईटी अनुरोधों को कैसे संभाला जाए?

Question

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

लेकिन जब उपयोगकर्ता प्रमाणीकृत होता है तो क्या होता है, फिर एक नया टैब खुलता है और ऐप/साइट के एक अलग प्रतिबंधित क्षेत्र (या यहां तक ​​कि उसी क्षेत्र) तक पहुंचने का प्रयास करता है? इस मामले में, नए टैब पर प्राधिकरण शीर्षलेख पर टोकन इंजेक्ट करने के लिए कोई इंटरसेप्टर नहीं है। मुझे लगता है कि सर्वर को GET अनुरोध प्राप्त होगा, प्राधिकरण शीर्षलेख पर जेडब्ल्यूटी टोकन की तलाश करें और अनुरोध को अस्वीकार कर इसे नहीं मिलेगा।

जब आप कुकीज़ का उपयोग कर रहे हों, तो उन्हें हमेशा ब्राउज़र द्वारा भेजा जाता है और आपको नए टैब और प्रमाणीकरण के बारे में चिंता करने की आवश्यकता नहीं होती है।

ब्राउज़र पर डोमेन के लिए वैश्विक स्तर पर प्रमाणीकरण शीर्षलेख स्थापित करने का कोई तरीका है जब उपयोगकर्ता पहले टैब में प्रमाणीकृत करता है? इस मामले के लिए सामान्य समाधान क्या हैं, यदि कोई हो?

Answer 1

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

इस OpenID Connect ने अंतर्निहित प्रवाह में उदाहरण के लिए होता है: http://openid.net/specs/openid-connect-implicit-1_0.html

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

Answer 2

मैंने नए निष्कर्षों के कारण इस प्रश्न में एक अपडेट जोड़ने का फैसला किया। मैं मूल जवाब नहीं बदलूंगा।

पहले, मूल जवाब पर मेरी टिप्पणी के अनुसार:

मैं कुकी का उपयोग करके जेडब्ल्यूटी धारण करने के लिए समाप्त हो गया है, लेकिन यह ग्राहक पहले प्रमाणीकरण के बाद github.com/js-cookie/js-cookie का उपयोग करके निर्धारित है। मेरे सर्वर कोड इस आदेश में अनुरोध में जेडब्ल्यूटी के लिए जांच करता है: हेडर, शरीर, कुकी। इसलिए जब भी उपयोगकर्ता एक नया टैब खोलता है, स्थानीय सेट कुकी का उपयोग किया जाता है। अन्य इन-पेज अनुरोध हेडर में जेडब्ल्यूटी को इंजेक्ट करते हैं। इस तरह, ऑपरेशन एपीआई उन्मुख है, पिछले मामले में में एक कुकी पर वापस आ रहा है।

हालांकि, मुझे ब्राउजर पर उत्पन्न कुकी की सुरक्षा के बारे में भी चिंता थी। ऐसा इसलिए है क्योंकि, चूंकि यह क्लाइंट जावास्क्रिप्ट द्वारा उत्पन्न होता है, इसलिए आप XSS के लिए इसे छोड़कर, केवल Http का उपयोग नहीं कर सकते हैं।

समाधान

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

http://sailsjs.com/documentation/reference/response-res/res-cookie

रेस।कुकी()

प्रतिक्रिया के साथ भेजने के लिए नाम (नाम) और मूल्य (मान) के साथ एक कुकी सेट करता है।

 res.cookie('x-access-token', token, { 
     expires: expire, 
     httpOnly: true 
     }); 
     return res.status(200).json({ 
     "x-access-token" : token 
     }); 

यह कुकी सत्र सर्वर पर सक्षम की आवश्यकता नहीं है, तो यह जेडब्ल्यूटी का उपयोग करने का "sessionless" लाभ पूरा करता है।

यदि ग्राहक एक ब्राउज़र है, तो यह केवल अनुरोधों पर टोकन को स्टोर और पुन: उपयोग करेगा, जिसमें एचटीपी केवल कुकी की सहायता से नए टैब शामिल हैं।

यदि यह एक और प्रकार का ग्राहक है, तो उसके पास प्रतिक्रिया निकाय पर जेडब्ल्यूटी टोकन है।