Lorawan-stack: नया खाता ऐप पेश करें (शपथ ऐप को बदलने के लिए)

संदर्भ https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

कंसोल और ओथ प्रदाता के बीच संपूर्ण लॉगिन/लॉगआउट भ्रम समस्या के संबंध में, मेरी योजना यहां है:

• हम खाता ऐप (टीटीएस लोगो के बजाय) के लिए एक अलग Account लोगो का उपयोग करते हैं और उसी हेडर घटक का उपयोग करते हैं जिसका उपयोग हम कंसोल के लिए भी करते हैं (cc @pierreph)
• कंसोल और अकाउंट ऐप के लिए दो अलग-अलग लॉगिन स्क्रीन होने के बजाय, हमें अनुभव को एक साथ जोड़ना चाहिए, जिसका अर्थ है
  
  
  
  • हम कंसोल लॉगिन स्क्रीन को हटा देंगे /console/login
  
  
  • कंसोल स्वचालित रूप से खाता ऐप लॉगिन पृष्ठ पर रीडायरेक्ट करेगा /account/login , जब उसके पास कोई (वैध) पहुंच टोकन नहीं है
  
  
  • जैसे हम पहले से ही कंसोल लॉगिन बटन के साथ करते हैं, हम सफल लॉगिन के बाद उपयोगकर्ता को कंसोल पर वापस भेजने के लिए एक रीडायरेक्ट क्वेरी परम का उपयोग करेंगे
  
  
  • कंसोल UI से लॉग आउट करने के परिणामस्वरूप संग्रहीत एक्सेस टोकन को हटा दिया जाएगा, साथ ही खाता ऐप से लॉग आउट भी किया जाएगा। इस तरह, कंसोल में वापस लॉग इन करने के लिए उपयोगकर्ताओं को हमेशा अपने क्रेडेंशियल्स को फिर से दर्ज करना होगा।
    
    
    
    
    
    • ऐसा करने में सक्षम होने के लिए, हमें क्रॉस-ओरिजिनल अनुरोधों से लॉगआउट को ट्रिगर करने का एक तरीका चाहिए (चूंकि कंसोल और खाता ऐप एक ही मूल पर होने की गारंटी नहीं है)
    
    
    
    • v2 में, हम एक साधारण /users/logout मार्ग का उपयोग कर रहे हैं जो एक लॉगआउट को ट्रिगर करेगा जिसे कहीं से भी संदर्भित किया जा सकता है
    
    
    
    • अच्छा होगा कि सीएसआरएफ को सुरक्षित रखते हुए उसी चीज को प्राप्त करने के तरीकों पर गौर किया जाए
    
    
    
  
  
  • नया प्रवाह काफी हद तक v2 कंसोल के प्रवाह जैसा होगा; हम मूल रूप से UX को बेहतर बनाने के लिए कंसोल क्लाइंट और ऑथराइज़ेशन सर्वर के पृथक्करण का त्याग करेंगे, जो ठीक है क्योंकि कंसोल एक विशेष केस क्लाइंट की तरह है
  
  
  • यदि हम भविष्य में विभिन्न लॉगिन प्रक्रियाओं की अनुमति देते हैं तो हमें इस प्रवाह को संशोधित करने की आवश्यकता हो सकती है
  
  

अगर मुझे इस योजना के बारे में कोई शिकायत नहीं मिलती है तो मैं इसे लागू करना शुरू कर दूंगा।

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

क्रॉस-ओरिजिनल लॉगआउट के लिए आपको क्या चाहिए? क्या यह एक साधारण दो-चरणीय दृष्टिकोण नहीं होगा; कंसोल स्टोर किए गए एक्सेस टोकन को हटाने के लिए "पेज" लॉगआउट करें, फिर जेनेरिक लॉगआउट पेज पर रीडायरेक्ट करें जहां अकाउंट ऐप लॉग आउट होता है? या आप इसे पुनर्निर्देशन के बिना चाहते हैं लेकिन लॉगआउट एंडपॉइंट पर पोस्ट करें?

लॉगआउट के लिए, हम OpenID Connect लॉगआउट से कुछ प्रेरणा प्राप्त कर सकते हैं। अच्छा सारांश यहाँ पाया जा सकता है: https://medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

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

क्रॉस-ओरिजिनल लॉगआउट के लिए आपको क्या चाहिए? क्या यह एक साधारण दो-चरणीय दृष्टिकोण नहीं होगा; कंसोल स्टोर किए गए एक्सेस टोकन को हटाने के लिए "पेज" लॉगआउट करें, फिर जेनेरिक लॉगआउट पेज पर रीडायरेक्ट करें जहां अकाउंट ऐप लॉग आउट होता है? या आप इसे पुनर्निर्देशन के बिना चाहते हैं लेकिन लॉगआउट एंडपॉइंट पर पोस्ट करें?

दो-चरणीय दृष्टिकोण ठीक है। मेरी चिंता यह थी कि खाता ऐप का लॉगआउट सीएसआरएफ अक्षम होना चाहिए, जिसका अर्थ है कि लॉगआउट लिंक वाला कोई भी व्यक्ति किसी को अपने खाते से लॉग आउट करने का लालच दे सकता है। यह वर्तमान में v2 स्टैक के साथ भी संभव है ( यहां क्लिक करने से आप लॉग आउट हो जाएंगे )।
मुझे लगता है कि अभी के लिए यह स्वीकार्य है लेकिन बिल्कुल सर्वोत्तम अभ्यास नहीं है।

मैंने नए खाता ऐप के लिए अब काफी काम किया है:

• रीफैक्टर किए गए घटक और कंटेनर जिनका उपयोग कंसोल और खाता ऐप द्वारा किया जा सकता है
• लागू किए गए नए डिजाइन (जवाबदेही सहित)
• प्रोफ़ाइल चित्र सहित कार्यान्वित प्रोफ़ाइल सेटिंग्स
• कार्यान्वित प्राधिकरण प्रबंधन (देखें और निरस्त करें)
• कार्यान्वित सत्र प्रबंधन (देखें और निरस्त करें)
• साझा सीएसएस मॉड्यूल निर्भरता का उपयोग करते समय रिक्त रेंडरर्स के परिणामस्वरूप किसी समस्या का समाधान करना

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

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

मैंने पहले ही @htdvisser से कहा था कि इसका पूरा प्रत्यायोजित प्रमाणीकरण/प्राधिकरण पहलू मेरे लिए कुछ हद तक भारी है और मैं इस तरह के सुरक्षा-संवेदनशील मामले के लिए जिम्मेदार होने के लिए पर्याप्त जानकार महसूस नहीं करता हूं।

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

इसलिए, मुझे खाता ऐप के साथ आगे बढ़ने के लिए कुछ मदद और इनपुट की आवश्यकता होगी। हम इसका समन्वय कैसे कर सकते हैं?

स्रोत के आधार पर, "आधिकारिक" और विश्वसनीय ग्राहकों के लिए भी पासवर्ड अनुदान प्रकार को हतोत्साहित किया जाता है

हां, पासवर्ड अनुदान का उपयोग नहीं किया जाना चाहिए, यहां विनिर्देश और तर्क देखें: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section -3.4

वर्तमान में #2148 . द्वारा अवरोधित किया गया है

तो कुछ समय के लिए इसमें शामिल होने के बाद, मुझे लगता है कि मुझे कुछ इनपुट चाहिए।

खाता ऐप का मूल विचार वर्तमान ओथ ऐप को बदलना और प्रोफ़ाइल और सत्र प्रबंधन (ओपी देखें) के लिए कार्यक्षमता का विस्तार करना था। इसके साथ मुद्दा यह है कि इस तरह की कार्यक्षमता को लागू करने के लिए, ऐप को एक्सेस टोकन की आवश्यकता होगी, अनिवार्य रूप से इसका अर्थ है कि खाता ऐप एक OAuth प्रदाता और क्लाइंट दोनों होगा।

मेरा विचार एक नया OAuth क्लाइंट ( account ) और फ्रंटएंड-वार पेश करना था, ताकि वर्तमान OAuth ऐप के साथ कार्यक्षमता को मिश्रित किया जा सके। उपयोगकर्ता के लिए, ऐसा प्रतीत होगा जैसे OAuth प्रदाता (लॉगिन, रजिस्टर, मान्य खाता, आदि) और खाता ऐप क्लाइंट (प्रोफ़ाइल सेटिंग्स, सत्र प्रबंधन, प्राधिकरण प्रबंधन) दोनों एक ही एप्लिकेशन हैं, जबकि पृष्ठभूमि में, वहाँ OAuth प्रदाता और क्लाइंट के बीच एक तकनीकी अलगाव है। बैकएंड पर, खाता क्लाइंट oauth पैकेज का हिस्सा बन जाएगा। फ्रंटएंड-वार हम एक ही प्रवेश बिंदु ( account.js ) का उपयोग करके दोनों चीजों को एक ही ऐप के रूप में भी मान सकते हैं।
इसी तरह, रूटिंग इस सम्मिश्रण को दर्शाएगा, जैसे:

• शपथ लॉगिन के लिए /account/login [OAuth प्रदाता परत]
• उपयोगकर्ता पंजीकरण के लिए /account/register [OAuth प्रदाता परत]
• उपयोगकर्ता पंजीकरण के लिए /account/forgot-password [OAuth प्रदाता परत]
• क्लाइंट लॉगिन (प्राधिकरण) के लिए /account/client/login/ttn-stack [OAuth क्लाइंट लेयर]
• /account/client/oauth/callback प्रमाणीकरण कोड का आदान-प्रदान करने के लिए [OAuth क्लाइंट परत]
• शपथ ग्राहक का /account अवलोकन पृष्ठ [OAuth क्लाइंट परत]

वैकल्पिक रूप से, हम OAuth प्रदाता ( /oauth माध्यम से pkg/oauth ) को छोड़कर, दोनों चिंताओं को अलग रख सकते हैं और खाता ऐप ( /account माध्यम से pkg/account माध्यम से इलाज कर सकते हैं। ) पूरी तरह से अलग चीज़ के रूप में, जैसे हम कंसोल के साथ करते हैं। OAuth प्रदाता तब केवल प्रमाणीकरण मामलों के लिए ज़िम्मेदार होगा, जिसमें प्राधिकरण और उपयोगकर्ता खाता पंजीकरण शामिल है, लेकिन उसका स्वयं का प्रमाणित दृश्य नहीं होगा जैसा कि वर्तमान में है। इसके बजाय, लॉगिन के बाद, यह डिफ़ॉल्ट रूप से खाता ऐप पर पुनर्निर्देशित होगा, जो तब स्वचालित रूप से एक टोकन प्राप्त करेगा।

मुझे लगता है कि पहला समाधान कुछ भ्रम से बच सकता है जो वर्तमान में हम प्रमाणीकरण और खाता प्रबंधन के इर्द-गिर्द घूम रहे हैं, लेकिन मैं यह नहीं देख सकता कि क्या यह अन्य जटिलताओं को पेश कर सकता है। दूसरा समाधान क्लीनर लगता है, लेकिन सवाल यह है कि अलगाव को कैसे संप्रेषित/ब्रांड किया जाए। जैसे दोनों को अभी भी "खाता ऐप" के रूप में सूचित किया जाना चाहिए? या यह The Things Stack Single Sign On और The Things Stack Account Application ?

कृपया मुझे अपनी राय बताएं।

हम्म, एक कदम पीछे हटते हुए, खाता ऐप को OAuth क्लाइंट बनाने का क्या उद्देश्य है? हम वहां OAuth के माध्यम से क्या कार्यक्षमता चाहते हैं?

• प्रोफ़ाइल सेटिंग (नाम, ईमेल, प्रोफ़ाइल चित्र)
• सत्र प्रबंधन (समीक्षा करें, निरस्त करें)
• प्राधिकरण प्रबंधन (समीक्षा करें, निरस्त करें)
• (भविष्य में संभावित रूप से अन्य TTES संबंधित मेटा सेटिंग्स)

उन सभी को एक एक्सेस टोकन की आवश्यकता होती है क्योंकि संबंधित आरपीसी को अधिकृत करने का यही एकमात्र तरीका है।

हमें OAuth प्रदाता को अलग करने की आवश्यकता है - जो बाहरी हो सकता है, उदाहरण के लिए "द थिंग्स नेटवर्क कम्युनिटी" - और उपयोगकर्ता प्रबंधन - जो कि थिंग्स स्टैक के साथ संग्रहीत उपयोगकर्ता इकाई के क्षेत्रों के प्रबंधन के बारे में है, जिसमें अंक @kschiffer शामिल हैं। ऊपर टिप्पणी में लिखा है।

हमारे /api/v3/* समापन बिंदु कुकी प्रमाणीकरण को स्वीकार नहीं करते, क्योंकि वे CORS-सक्षम हैं। वे केवल एपीआई कुंजी और एक्सेस टोकन के साथ काम करते हैं।

• प्रोफ़ाइल सेटिंग (नाम, ईमेल, प्रोफ़ाइल चित्र)
• सत्र प्रबंधन (समीक्षा करें, निरस्त करें)
• प्राधिकरण प्रबंधन (समीक्षा करें, निरस्त करें)
• (भविष्य में संभावित रूप से अन्य TTES संबंधित मेटा सेटिंग्स)

उन सभी को एक एक्सेस टोकन की आवश्यकता होती है क्योंकि संबंधित आरपीसी को अधिकृत करने का यही एकमात्र तरीका है।

हम कंसोल का ये हिस्सा भी बना सकते हैं लेकिन इसका मतलब यह होगा कि कंसोल कुछ हद तक चिंताओं को मिलाएगा। मैं ऐसी स्थितियां देख सकता था जहां अन्य सभी कंसोल कार्यात्मकताओं के ऊपरी हिस्से के बिना खाता प्रबंधन करना बेहतर होगा, लेकिन हो सकता है कि मैं इसे ओवरइंजीनियरिंग कर रहा हूं।

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

मुझे नहीं लगता कि कंसोल (सभी कंसोल, क्योंकि प्रत्येक क्लस्टर में एक कंसोल है) का उपयोगकर्ता पर पूर्ण अधिकार होना चाहिए। अधिकृत OAuth क्लाइंट, सत्र, प्राथमिक ईमेल पता, संपर्क जानकारी प्रबंधित करने के लिए कंसोल का उपयोग नहीं किया जाना चाहिए। एक समर्पित उपयोगकर्ता प्रबंधन ऐप (खाता ऐप) होना बहुत बेहतर है।

वाकई, अच्छी बात है। फिर यह प्रारंभिक प्रश्न पर वापस आता है।

मेरा लेना है:

मिश्रित दृष्टिकोण:

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

अलग दृष्टिकोण:

• स्वच्छ और अधिक पारंपरिक कार्यान्वयन
• विन्यास अधिक लचीला और स्पष्ट
• शपथ ऐप के बगल में एक नया ऐप पेश करता है, जिसे समझदार ब्रांडिंग और संचार की आवश्यकता होती है
• लंबे समय तक बनाता है (मामूली हो सकता है, परीक्षण नहीं किया गया है) और अधिक संपत्ति

मैं मिश्रित दृष्टिकोण की ओर झुकता हूं।

• प्रोफ़ाइल सेटिंग (नाम, ईमेल, प्रोफ़ाइल चित्र)
• सत्र प्रबंधन (समीक्षा करें, निरस्त करें)
• प्राधिकरण प्रबंधन (समीक्षा करें, निरस्त करें)
• (भविष्य में संभावित रूप से अन्य TTES संबंधित मेटा सेटिंग्स)

यह खाता ऐप है, है ना? OAuth नहीं?

• शपथ ऐप के बगल में एक नया ऐप पेश करता है, जिसे समझदार ब्रांडिंग और संचार की आवश्यकता होती है

तब भी OAuth ऐप क्या है?

क्या आप उपयोगकर्ता के लिए उन सुविधाओं को सूचीबद्ध कर सकते हैं जो OAuth क्लाइंट खाता ऐप में जोड़ता है, जिसे हम खाता ऐप में नहीं बना सकते, संभावित रूप से नए समापन बिंदुओं के माध्यम से?

यह खाता ऐप है, है ना? OAuth नहीं?

हाँ, यह खाता ऐप है। लेकिन योजना यह थी कि वर्तमान में हमारे पास OAuth ऐप के रूप में जो कुछ है वह खाता ऐप का हिस्सा बन जाए।

तब भी OAuth ऐप क्या है?

प्रमाणीकरण के लिए (OAuth प्रवाह के भाग के रूप में), उपयोगकर्ता पंजीकरण, क्लाइंट प्राधिकरण, पासवर्ड रीसेट। मूल रूप से सब कुछ जो उपयोगकर्ताओं के प्रमाणीकरण और ग्राहकों के प्राधिकरण के साथ करना है।

क्या आप उपयोगकर्ता के लिए उन सुविधाओं को सूचीबद्ध कर सकते हैं जो OAuth क्लाइंट खाता ऐप में जोड़ता है, जिसे हम खाता ऐप में नहीं बना सकते, संभावित रूप से नए समापन बिंदुओं के माध्यम से?

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

क्या OAuth ऐप एक स्टैंड-अलोन चीज़ है? क्या यह OAuth क्लाइंट के लिए रीडायरेक्ट फ़्लो लागू कर रहा है? या यह स्वयं एक OAuth क्लाइंट है?

मेरा जोर:

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

मैं यहाँ देखता हूँ;

• OAuth क्लाइंट
• वर्तमान OAuth ऐप
• OAuth प्रदाता
• खाता ऐप क्लाइंट
• OAuth प्रदाता
• ग्राहक
• बैकएंड
• खाता ग्राहक
• oauth पैकेज

मैं प्रस्ताव को समझने की कोशिश कर रहा हूं, लेकिन मैं पूरी तरह समझ नहीं पा रहा हूं कि अभी भी क्या है।

तो ऐसी कौन सी विशेषताएँ हैं जो हम चाहते हैं?

1. खाता बनाएं
2. पासवर्ड भूल गए
3. लॉग इन करें
4. पासवर्ड बदलें
5. प्रोफ़ाइल देखें और संपादित करें
6. सत्र प्रबंधित करें
7. OAuth सामान
   
   
   
   1. सहमति स्क्रीन (OAuth प्राधिकरण कोड प्रवाह)
   
   
   2. OAuth प्राधिकरण प्रबंधित करें
   
   

मुझे लगता है कि अगर हम सत्र प्रमाणीकरण के साथ जाते हैं, तो ओएथ को छूए बिना 1-6 लागू किया जा सकता है। यह संभव है, है ना?

हाँ क्षमा करें। हमारे यहां कई अनफिक्स शब्द हैं जो चीजों को समझाने में काफी मुश्किल बनाते हैं। कम से कम यह इस मुद्दे की जटिलता में एक अच्छी अंतर्दृष्टि देता है ।

तो चलिए यथास्थिति लेते हैं:

OAuth प्रदाता
वह इकाई जो OAuth 2.0 विनिर्देश के अनुसार प्राधिकरण (और हमारे मामले में भी प्रमाणीकरण) प्रदान करती है। हमारे मामले में यह pkg/oauth पैकेज है, जो बदले में उपयोगकर्ता जानकारी प्राप्त करने के लिए आवश्यक उपयोगकर्ता इंटरफ़ेस को लागू करने के लिए OAuth ऐप (नीचे देखें) का उपयोग करता है (लॉगिन, पंजीकरण, प्राधिकरण दृश्य, आदि प्रस्तुत करना)।

OAuth ऐप
यह फ्रंटएंड पर प्रतिक्रिया वेब एप्लिकेशन है। हमारे फ्रंटएंड कोड में अलग-अलग ऐप होते हैं (विभिन्न प्रवेश बिंदुओं के साथ oauth.js / console.js ) जो प्रतिक्रिया घटकों और उपयोगिताओं जैसे सामान्य भागों को साझा करते हैं

OAuth क्लाइंट
एक पंजीकृत क्लाइंट जो प्रमाणीकरण और प्राधिकरण के लिए OAuth का उपयोग करता है, जैसे कंसोल या CLI।

शपथ पैकेज
गो पैकेज जो OAuth प्रदाता को लागू करने के लिए जिम्मेदार है। वह pkg/oauth ।

तो आप देखिए, यहां तीन या चार अलग-अलग परतें चल रही हैं। समस्या यह है कि अगर हम इस समय प्राधिकरण करने के तरीके को बनाए रखते हैं, तो हमें कुछ ऐसा होना चाहिए जो एक ही समय में ऊपर उल्लिखित सभी भूमिकाएँ निभाए।

मुझे लगता है कि अगर हम सत्र प्रमाणीकरण के साथ जाते हैं, तो ओएथ को छूए बिना 1-6 लागू किया जा सकता है। यह संभव है, है ना?

हां। ओथ/एक्सेस टोकन के बिना 1-4 पहले से ही संभव हैं। 5 और 6 को वर्तमान में एक एक्सेस टोकन की आवश्यकता है। 7. ii अभी तक लागू नहीं किया गया है। यदि 5 और 6 एक्सेस टोकन के बिना संभव होंगे तो हमें वास्तव में ऐसा करने के लिए किसी अन्य शपथ ग्राहक की आवश्यकता नहीं होगी। फिर भी हमें इस बात पर विचार करने की आवश्यकता है कि भविष्य में हम जिस भी कार्यक्षमता को खाता ऐप में जोड़ना चाहते हैं, उसे प्राधिकरण के एकमात्र साधन के रूप में एक्सेस टोकन का उपयोग नहीं करना चाहिए।

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

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

ठीक है, अच्छा लगता है।
@htdvisser क्या आपको कोई आपत्ति है? और यदि नहीं, तो क्या आप मुझे प्राधिकरण के लिए संबंधित फाइलों/पैकेजों की ओर संकेत कर सकते हैं, क्योंकि मुझे लगता है कि आपके पास इस पर जल्द ही काम करने का समय नहीं होगा (?)

जैसा कि मैंने पहले टिप्पणी की थी, हमारे /api/v3/* समापन बिंदु कुकी प्रमाणीकरण को स्वीकार नहीं करते हैं, क्योंकि वे CORS-सक्षम हैं। यदि आप कुकी प्रमाणीकरण को स्वीकार करना शुरू करना चाहते हैं, तो आपको हमारे CORS हेडर पर एक अच्छी नज़र डालने की आवश्यकता होगी, क्योंकि हम वास्तव में नहीं चाहते कि कोई हमलावर इन समापन बिंदुओं पर कुकी-प्रमाणित क्रॉस-ओरिजिनल अनुरोध करे।

हमारा एपीआई सभी जीआरपीसी है, और प्रमाणीकरण Authorization हेडर के साथ किया जाता है, जिसे अनुरोध मेटाडेटा के रूप में जीआरपीसी में प्रचारित किया जाता है। सत्र प्रमाणीकरण का कार्यान्वयन इस तरह दिख सकता है:

• SessionToken प्रकार को pkg/auth/auth.go
• Session मॉडल में एक गुप्त भाग जोड़ें, जैसा कि हम एपीआई कुंजी और एक्सेस टोकन के साथ करते हैं।
• एक मिडलवेयर जोड़ें जो कुकी से सत्र आईडी और सत्र रहस्य निकालता है और इसे सत्र टोकन के रूप में Authorization शीर्षलेख में अग्रेषित करता है
• SessionToken को case के रूप में switch tokenType { में pkg/identityserver/entity_access.go

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

हां, वे एक ही मूल के होंगे।

@kschiffer कृपया हमें बताएं कि हम यहां प्रगति को कैसे अनवरोधित कर सकते हैं।

मैंने यहाँ एक सारांश लिखा है: https://github.com/TheThingsNetwork/lorawan-stack/pull/2850#issuecomment -657497193

ठीक है, चलिए उस बातचीत को यहाँ जारी रखते हैं।

@kschiffer इस पर थोड़ा काम करने के बाद:

• ओथ ऐप के फ्रंटएंड भाग में मूल रूप से केवल प्राधिकरण स्क्रीन होगी

हां

• मुझे लगता है कि केवल उसके लिए is.oauth.ui.* कॉन्फिग को बनाए रखना बहुत कष्टप्रद है
  [...]
• मैं सीसी को तोड़े बिना स्टैक कॉन्फ़िगरेशन को कैसे बदल सकता हूं, इसके सटीक प्रतिबंधों के बारे में थोड़ा अनिश्चित हूं
• मैं यहां एक व्यवहार्य समाधान खोजने के साथ भाग्य से थोड़ा बाहर हूं और वास्तव में कुछ इनपुट की आवश्यकता है

हम V3 में कॉन्फ़िगरेशन को तोड़ नहीं सकते हैं, लेकिन हम नए कॉन्फ़िगरेशन को पेश कर सकते हैं, पुराने कॉन्फ़िगरेशन को हटा सकते हैं, पुराने कॉन्फ़िगरेशन को फ़ॉलबैक के रूप में उपयोग कर सकते हैं, और पुराने कॉन्फ़िगरेशन को हटाने के लिए bump/major लेबल वाला TODO समस्या दर्ज कर सकते हैं।

तो मेरा सुझाव नया कॉन्फ़िगरेशन पेश करना होगा जो एक पूर्ण प्रतिस्थापन होगा और नया खाता ऐप सक्षम करेगा। पश्चगामी संगतता के लिए, इसे उपयोगकर्ता द्वारा इस नए कॉन्फ़िगरेशन को निर्दिष्ट किए बिना काम करना चाहिए, यानी is.oauth.ui.* माध्यम से समझदार डिफ़ॉल्ट मानों और पुराने कॉन्फ़िगरेशन पर भरोसा करना चाहिए।

@kschiffer यहाँ क्या स्थिति है?

वर्तमान में नए मचान पर अपना काम फिर से कर रहा हूं, जो यहां चल रहा है: #3453

इसके बाद प्रमाणित विचारों को पुन: आधार बनाना, ठीक करना और PRing करना और वर्तमान डिज़ाइनों को नई ब्रांडिंग में समायोजित करना है।

@kschiffer यहाँ क्या स्थिति है?

खाता ऐप 3.11 में पेश किया गया है। वर्तमान में अभी भी लापता हैं:

• खाता स्विचिंग #488
• सत्र प्रबंधन
• प्राधिकरण प्रबंधन (iirc इसमें API समापन बिंदु जोड़ना भी शामिल है)

ठीक है। ऐसा लगता है कि https://github.com/TheThingsNetwork/lorawan-stack/issues/488 पहले ही बंद है।

यह एक बड़ा मुद्दा हो गया है। क्या आप इसे बदलने के लिए उपरोक्त के लिए एक या दो नए मुद्दे दर्ज कर सकते हैं, ताकि इसे बंद किया जा सके?