यहां कई प्रश्न पूछे गए हैं, और ऐसा लगता है कि भले ही प्रश्न नोड और पासपोर्ट के संदर्भ में पूछे गए हों। लेकिन असली सवाल वर्कफ़्लो के बारे में अधिक हैं कि किसी विशेष तकनीक के साथ ऐसा कैसे किया जाए।
चलिए @Keith उदाहरण सेटअप का उपयोग करते हैं, अतिरिक्त सुरक्षा के लिए थोड़ा संशोधित किया गया है:
- वेब सर्वर
https://example.comएक एकल पेज जावास्क्रिप्ट क्लाइंट ऐप परोसता है
https://example.com/apiसमृद्ध ग्राहक सेवा में समृद्ध ग्राहक ऐप सर्वर समर्थन प्रदान करता है- सर्वर नोड और पासपोर्ट में लागू।
- सर्वर में एक "उपयोगकर्ता" तालिका के साथ एक डेटाबेस (किसी भी प्रकार) है।
- उपयोगकर्ता नाम / पासवर्ड और फेसबुक कनेक्ट को प्रमाणीकरण विकल्प के रूप में पेश किया जाता है
- रिच क्लाइंट अन्य अनुरोधों में बनाता है
https://example.com/api
- अन्य ग्राहक हो सकते हैं (उदाहरण के लिए फोन ऐप), जो वेब सेवा का उपयोग करते हैं,
https://example.com/apiलेकिन वेब सर्वर के बारे में नहीं जानते हैं https://example.com।
ध्यान दें कि मैं सुरक्षित HTTP का उपयोग कर रहा हूं। यह मेरी राय में किसी भी सेवा के लिए जरूरी है जो खुले में उपलब्ध है, क्योंकि पासवर्ड और प्राधिकरण टोकन जैसी संवेदनशील जानकारी क्लाइंट और सर्वर के बीच गुजर रही है।
उपयोगकर्ता नाम / पासवर्ड प्रमाणीकरण
आइए देखें कि पहले सादा पुराना प्रमाणीकरण कैसे काम करता है।
- उपयोगकर्ता से जोड़ता है
https://example.com
- सर्वर एक समृद्ध जावास्क्रिप्ट एप्लिकेशन परोसता है जो शुरुआती पेज को प्रस्तुत करता है। किसी पृष्ठ में कोई लॉगिन फ़ॉर्म है।
- उपयोगकर्ता द्वारा लॉग इन नहीं किए जाने के कारण इस एकल पृष्ठ एप्लिकेशन के कई अनुभाग डेटा से आबाद नहीं हुए हैं। इन सभी अनुभागों में एक "लॉगिन" ईवेंट पर एक ईवेंट श्रोता है। यह सब क्लाइंट साइड सामान है, सर्वर को इन घटनाओं का पता नहीं है।
- उपयोगकर्ता अपने लॉगिन और पासवर्ड दर्ज करता है और सबमिट बटन दबाता है, जो क्लाइंट साइड चर में उपयोगकर्ता नाम और पासवर्ड रिकॉर्ड करने के लिए एक जावास्क्रिप्ट हैंडलर को ट्रिगर करता है। फिर यह हैंडलर "लॉगिन" ईवेंट चलाता है। फिर से, यह सभी क्लाइंट साइड एक्शन है, क्रेडेंशियल अभी तक सर्वर पर नहीं भेजे गए थे ।
- "लॉगिन" ईवेंट के श्रोताओं को आमंत्रित किया जाता है। इनमें से प्रत्येक को अब
https://example.com/apiपेज पर रेंडर करने के लिए उपयोगकर्ता विशिष्ट डेटा प्राप्त करने के लिए RESTful API पर एक या अधिक अनुरोध भेजने की आवश्यकता है । वेब सेवा को भेजे जाने वाले हर एक अनुरोध में संभवतः HTTP बेसिक प्रमाणीकरण के रूप में उपयोगकर्ता नाम और पासवर्ड शामिल होंगे , क्योंकि RESTful की जाने वाली सेवा को ग्राहक के अनुरोध को अगले अनुरोध तक बनाए रखने की अनुमति नहीं है। चूंकि वेब सेवा सुरक्षित एचटीटीपी पर है, इसलिए पासवर्ड ट्रांज़िट के दौरान सुरक्षित रूप से एन्क्रिप्ट किया जाता है।
- वेब सेवा पर
https://example.com/apiप्रत्येक व्यक्ति को प्रमाणीकरण सूचना के साथ व्यक्तिगत अनुरोधों का एक समूह प्राप्त होता है। प्रत्येक अनुरोध में उपयोगकर्ता नाम और पासवर्ड उपयोगकर्ता डेटाबेस के खिलाफ जांचा जाता है और यदि सही पाया गया अनुरोधित फ़ंक्शन निष्पादित होता है और ग्राहक को JSON प्रारूप में डेटा लौटाया जाता है। यदि उपयोगकर्ता नाम और पासवर्ड त्रुटि से मेल नहीं खाते हैं तो क्लाइंट को 401 HTTP त्रुटि कोड के रूप में भेजा जाता है।
- हर अनुरोध के साथ उपयोगकर्ता नाम और पासवर्ड भेजने के लिए मजबूर करने के बजाय, आप अपनी Restful सेवा में "get_access_token" फ़ंक्शन कर सकते हैं जो उपयोगकर्ता नाम और पासवर्ड लेता है और एक टोकन के साथ प्रतिक्रिया करता है, जो कि किसी प्रकार का क्रिप्टोग्राफ़िक है। यह अद्वितीय है और इसकी समाप्ति है इससे जुड़ी तारीख ये टोकन प्रत्येक उपयोगकर्ता के साथ डेटाबेस में संग्रहीत किए जाते हैं। फिर क्लाइंट बाद के अनुरोधों में एक्सेस टोकन भेजता है। तब टोकन को उपयोगकर्ता नाम और पासवर्ड के बजाय डेटाबेस के खिलाफ मान्य किया जाएगा।
- नॉन ब्राउज़र क्लाइंट एप्लिकेशन जैसे कि फ़ोन ऐप ऊपर की तरह ही होते हैं, वे उपयोगकर्ता से उसकी साख दर्ज करने के लिए कहते हैं, फिर वेब सेवा के लिए हर अनुरोध के साथ उन्हें (या उनसे उत्पन्न एक्सेस टोकन) भेजें।
इस उदाहरण से महत्वपूर्ण महत्वपूर्ण बात यह है कि रेस्टफुल वेब सेवाओं को हर अनुरोध के साथ प्रमाणीकरण की आवश्यकता होती है ।
इस परिदृश्य में सुरक्षा की एक अतिरिक्त परत उपयोगकर्ता प्रमाणीकरण के अलावा क्लाइंट एप्लिकेशन प्राधिकरण को जोड़ देगी। उदाहरण के लिए, यदि आपके पास वेब क्लाइंट, iOS और एंड्रॉइड ऐप हैं, तो आप वेब सेवा का उपयोग करके सर्वर को यह जान सकते हैं कि दिए गए अनुरोध के तीन में से कौन सा क्लाइंट है, भले ही वह प्रमाणित उपयोगकर्ता हो। यह आपकी वेब सेवा को कुछ कार्यों को विशिष्ट ग्राहकों तक सीमित करने में सक्षम कर सकता है। इसके लिए आप एपीआई कुंजी और रहस्यों का उपयोग कर सकते हैं, उस पर कुछ विचारों के लिए यह उत्तर देखें ।
फेसबुक प्रमाणीकरण
ऊपर दिए गए वर्कफ़्लो फेसबुक कनेक्ट के लिए काम नहीं करते हैं क्योंकि फ़ेसबुक के माध्यम से लॉगिन में एक तीसरी पार्टी, फ़ेसबुक है। लॉगिन प्रक्रिया के लिए उपयोगकर्ता को फेसबुक की वेबसाइट पर पुनः निर्देशित करना होगा जहां हमारे नियंत्रण के बाहर क्रेडेंशियल्स दर्ज किए गए हैं।
तो आइए देखें कि चीजें कैसे बदलती हैं:
- उपयोगकर्ता से जोड़ता है
https://example.com
- सर्वर एक समृद्ध जावास्क्रिप्ट एप्लिकेशन परोसता है जो शुरुआती पेज को प्रस्तुत करता है। पृष्ठ में somehwere एक लॉगिन फ़ॉर्म है जिसमें "फेसबुक के साथ लॉगिन" बटन शामिल है।
- उपयोगकर्ता "फेसबुक के साथ लॉगिन" बटन पर क्लिक करता है, जो सिर्फ एक लिंक है जो (उदाहरण के लिए) रीडायरेक्ट करता है
https://example.com/auth/facebook।
https://example.com/auth/facebookमार्ग passport.js द्वारा नियंत्रित किया जाता है (देखें प्रलेखन )- सभी उपयोगकर्ता देखते हैं कि पृष्ठ बदल जाता है और अब वे एक फेसबुक होस्ट किए गए पृष्ठ में हैं जहां उन्हें हमारे वेब एप्लिकेशन को लॉगिन और अधिकृत करने की आवश्यकता है। यह पूरी तरह से हमारे नियंत्रण से बाहर है।
- उपयोगकर्ता फेसबुक में लॉग इन करता है और हमारे आवेदन को अनुमति देता है, इसलिए फेसबुक अब कॉलबैक URL पर वापस भेज देता है जिसे हमने पासपोर्ट.जेएस सेटअप में कॉन्फ़िगर किया था, जो प्रलेखन में उदाहरण के बाद है
https://example.com/auth/facebook/callback
https://example.com/auth/facebook/callbackमार्ग के लिए पासपोर्ट.जेएस हैंडलर उस कॉलबैक फ़ंक्शन का आह्वान करेगा जो फेसबुक का उपयोग टोकन प्राप्त करता है और उपयोगकर्ता के ईमेल पते सहित फेसबुक से कुछ उपयोगकर्ता जानकारी प्राप्त करता है।- ईमेल से हम अपने डेटाबेस में उपयोगकर्ता का पता लगा सकते हैं और इसके साथ फेसबुक एक्सेस टोकन स्टोर कर सकते हैं।
- आखिरी चीज जो आप फेसबुक कॉलबैक में करते हैं, वह रिच क्लाइंट एप्लिकेशन पर वापस भेजना है, लेकिन इस बार हमें उपयोगकर्ता नाम और टोकन को क्लाइंट को पास करना होगा ताकि यह उनका उपयोग कर सके। यह कई तरीकों से किया जा सकता है। उदाहरण के लिए, जावास्क्रिप्ट चर को सर्वर-साइड टेम्प्लेट इंजन के माध्यम से पृष्ठ पर जोड़ा जा सकता है, या किसी कुकी को इस जानकारी के साथ वापस किया जा सकता है। (यूआरएल में इस डेटा को पारित करने के साथ सुरक्षा मुद्दों को इंगित करने के लिए @RyanKimber के लिए धन्यवाद, जैसा कि मैंने शुरू में सुझाव दिया था)।
- तो अब हम सिंगल पेज ऐप को एक बार शुरू करते हैं, लेकिन क्लाइंट के पास यूज़रनेम और एक्सेस टोकन है।
- क्लाइंट एप्लिकेशन "लॉगिन" इवेंट को तुरंत ट्रिगर कर सकता है और एप्लिकेशन के विभिन्न हिस्सों को वेब सेवा से आवश्यक जानकारी का अनुरोध करने देता है।
- भेजे गए सभी अनुरोधों
https://example.com/apiमें प्रमाणीकरण के लिए फेसबुक एक्सेस टोकन, या REST API में "get_access_token" फ़ंक्शन के माध्यम से फेसबुक के टोकन से उत्पन्न एप्लिकेशन के स्वयं के टोकन शामिल हो सकते हैं।
- गैर-ब्राउज़र ऐप्स के लिए यहां कुछ अधिक कठिन है, क्योंकि OAuth को लॉग इन करने के लिए एक वेब ब्राउज़र की आवश्यकता होती है। फोन या डेस्कटॉप ऐप से लॉगिन करने के लिए आपको फेसबुक पर रीडायरेक्ट करने के लिए एक ब्राउज़र शुरू करना होगा, और इससे भी बदतर, आप। कुछ तंत्र के माध्यम से आवेदन के लिए फेसबुक एक्सेस टोकन वापस करने के लिए ब्राउज़र के लिए एक रास्ता चाहिए।
मुझे उम्मीद है कि यह अधिकांश सवालों के जवाब देगा। बेशक आप फेसबुक को ट्विटर, गूगल या किसी अन्य OAuth आधारित प्रमाणीकरण सेवा से बदल सकते हैं।
मुझे यह जानने में दिलचस्पी होगी कि क्या किसी के पास इससे निपटने का एक सरल तरीका है।
passport-facebook। आपके द्वारा वह कार्य करने के बाद, अगला चरण यह समझना शुरू करना है कि पासपोर्ट कैसे काम करता है, और यह कैसे क्रेडेंशियल्स को संग्रहीत करता है। इसे फिर से शुरू करने के लिए हुक करना (आपके द्वारा उल्लेखित एक के अद्यतन संस्करण के लिए यहां देखें ) अंतिम चरणों में से एक होगा (या आप एक्सप्रेस में रीस्ट इंटरफ़ेस को लागू कर सकते हैं)।