Jwt-auth: अपडेट किया गया टोकन फ्लो UX

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

मुझे चिंता है कि यह परिवर्तन इस प्लगइन की कार्यक्षमता को अधिकांश गैर-तकनीकी उपयोगकर्ताओं के लिए दुर्गम बना देता है, जो अपने उपयोगकर्ता नाम और पासवर्ड का उपयोग करके लॉग इन करने में सक्षम होने की उम्मीद करते हैं।

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

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

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

एक सुरक्षित मॉडल रखने के लिए जो पहुंच और प्रमाणीकरण को अलग करने का समर्थन करता है, आपके पास ऐसी रेलिंग होनी चाहिए जो लंबे समय तक चलने वाले टोकन को एक्सेस का अनंत बिंदु बनने से रोकती हैं। रीफ्रेश टोकन के अतिरिक्त एक दुर्भावनापूर्ण उपयोगकर्ता user:pass संयोजन के साथ एक एक्सेस और रीफ्रेश टोकन बना सकता है जिसे हम टोकन को अमान्य करने के लिए कुंजी-जोड़ी, या कुछ समकक्ष नहीं होने पर कभी भी अमान्य नहीं कर सकते हैं।

सुरक्षा के लिए भुगतान करने के लिए उपयोगकर्ता को वर्डप्रेस में लॉगिन करने और की-जोड़ी बनाने के लिए उनके प्रोफाइल पर जाने के लिए कहना एक छोटी सी कीमत है। साथ ही, निर्देश बहुत सरल हैं।

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

कृपया इस ऐप का वर्णन करें जिसका आप जिक्र करते रहते हैं, यह आपके लिए सभी प्रमाणीकरण और लॉगिन को क्यों संभालेगा? यह सुरक्षित नहीं है। आप इस ऐप को अपनी वेबसाइट पर कुछ भी करने के लिए आवश्यक सभी एक्सेस और प्रमाणीकरण दे रहे होंगे। आपको इस बात पर विचार करना चाहिए कि हो सकता है कि ऐप्स आर्किटेक्चर गलत हो और यह सामान्य प्रवाह आपके द्वारा वर्णित सटीक चीज़ को रोकने के लिए है।

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

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

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

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

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

यह कोई अतिरिक्त सुरक्षा प्रदान नहीं करता है
यदि एक हमलावर के रूप में मेरे पास पहले से ही आपका उपयोगकर्ता नाम और पासवर्ड है, तो मैं आपके जैसा कुछ नहीं कर सकता (यह मानते हुए कि कोई 2FA नहीं है)।

मैं स्पष्ट रूप से असहमत हूं। यह दृष्टिकोण आपके आरईएसटी संसाधनों तक पहुंचने के लिए अतिरिक्त सुरक्षा प्रदान करता है और यदि यह स्पष्ट नहीं है तो हमें इसे स्पष्ट करने के लिए और दस्तावेज़ीकरण की आवश्यकता है। आप तर्क दे रहे हैं कि अगर किसी के पास आपकी साख पहले से है तो आप खराब हैं, लेकिन आप यह भी सुझाव दे रहे हैं कि हम उनका उपयोग आरईएसटी एपीआई तक पहुंच प्रदान करने के लिए करते हैं। अगर इस तरह आप आरईएसटी तक पहुंचना चाहते हैं तो बेसिक ऑथ का उपयोग करें। क्योंकि अगर हम टोकन बनाने के लिए user:pass का उपयोग करते हैं तो हम ठीक यही लागू करेंगे।

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

यह वह जगह है जहां हम एक ऑथ फ्लो बनाना चाहते हैं जो किसी ऐप को कॉलबैक के उपयोग के माध्यम से की-पेयर देने की अनुमति देता है। मेरा मानना ​​है कि ऐसा कुछ एप्लिकेशन पासवर्ड प्लगइन में पहले ही लागू किया जा चुका है।

मैं ऐप्स के लिए एक ऑथ फ्लो बनाने के लिए 100% खुला हूं कि जब आप इसमें जाते हैं तो आपको वर्डप्रेस में लॉगिन करने के लिए कहा जाता है, 2फैक्टर जैसे किसी भी अतिरिक्त के साथ, जो आपके लिए एक कुंजी-जोड़ी उत्पन्न करेगा और फिर किसी प्रकार का कॉलबैक का उपयोग करेगा ऐप को की-पेयर दें। फिर ऐप डेवलपर्स को बहुत सारे खराब समाधान बनाने की ज़रूरत नहीं है और ऐप उनके user:pass स्टोर नहीं करता है।

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

सही है, आप कई अलग-अलग तरीकों का इस्तेमाल कर सकते हैं।

यूजरमेटा में वर्डप्रेस की session_tokens प्रविष्टि से प्रेरणा लेते हुए - JWT-विशिष्ट निरस्तीकरण कुंजियों का एक संग्रहीत सेट समान कार्यक्षमता की अनुमति देगा, और यह "लॉग आउट एवरीवेयर एल्स" कार्यक्षमता को लागू करने के लिए तुच्छ बना देगा - बस उस प्रविष्टि को तालिका से हटा दें।

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

2FA के बारे में क्या?
मैं सोच रहा हूं कि क्या एक हुक की अनुमति देना संभव हो सकता है जो 2FA प्लगइन्स क्लाइंट को बताने के लिए उपयोग कर सकता है "कृपया फिर से प्रयास करें, 2FA टोकन प्रदान करें" यदि कोई आवश्यक था, लेकिन प्रदान नहीं किया गया था। इसके अतिरिक्त, 2FA प्लगइन को यह सत्यापित करने की अनुमति देने के लिए एक और हुक (या शायद वही एक?) का उपयोग किया जा सकता है कि प्रदान किया गया कोड सही है? JWT सिस्टम इस बारे में कोई अनुमान नहीं लगाएगा कि 2FA कैसे लागू किया जाता है - जिसे किसी अन्य प्लगइन पर छोड़ दिया जाएगा - हम इस तरह की चीज को संभव बनाने के लिए केवल हुक प्रदान करेंगे।

यह IMO जटिलता की एक अनावश्यक परत जोड़ देगा जिसमें बहुत सारे समर्थन अनुरोध बनाने की क्षमता है।

इसे अब तक पढ़ने के लिए धन्यवाद - उपरोक्त सभी IMHO है, लेकिन मुझे आशा है कि हम उपयोगकर्ताओं के लिए इस प्रक्रिया को थोड़ा सरल कर सकते हैं ताकि यह सभी के लिए वास्तव में अच्छी तरह से काम कर सके।

मुझे यकीन है कि मैंने कम से कम कुछ याद किया है, इसलिए मुझे इस पर लोगों की कोई प्रतिक्रिया सुनकर खुशी हो रही है!

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

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

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

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

हालांकि मैं निर्णय में सुरक्षा पहलू को समझता हूं, और इससे सहमत हूं। लेकिन हमें एक ऐसा तरीका खोजने की जरूरत है जो दोनों के लिए काम कर सके।

ऐसा लगता है कि आपने यहां जो कहा है @valendesigns एक संभावित समाधान हो सकता है:

मैं ऐप्स के लिए एक ऑथ फ्लो बनाने के लिए 100% खुला हूं कि जब आप इसमें जाते हैं तो आपको वर्डप्रेस में लॉगिन करने के लिए कहा जाता है, 2फैक्टर जैसे किसी भी अतिरिक्त के साथ, जो आपके लिए एक कुंजी-जोड़ी उत्पन्न करेगा और फिर किसी प्रकार का कॉलबैक का उपयोग करेगा ऐप को की-पेयर दें। तब ऐप डेवलपर्स को बहुत सारे खराब समाधान बनाने की ज़रूरत नहीं है और ऐप उनके उपयोगकर्ता को स्टोर नहीं करता है

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

इस अन्य प्रवाह को रखते हुए जहां हमें विदेशी ऐप को अपना पासवर्ड देने की आवश्यकता नहीं होगी। इसके बजाय, उन्हें वर्डप्रेस पर लॉग इन करने और की-पेयर जेनरेट करने के लिए कहें।

मुझे इस भाग के बारे में अधिक जानकारी चाहिए:

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

ऐसा प्रतीत होता है कि यदि मैं ब्राउज़र और ऐप के माध्यम से site.com में लॉग इन हूं, अगर मैं ब्राउज़र में "लॉग आउट एवरीवेयर एल्स" पर क्लिक करता हूं, तो मैं भी ऐप में लॉगआउट हो जाऊंगा, नहीं ?! मैं उन ऐप्स को देख सकता हूं जहां यह अनुमान होगा। उम्मीद है कि आप हर जगह लॉग आउट हो जाएंगे।

खाता हटाए जाने पर भी ऐसा ही होना चाहिए।

मुझे इस बात से सहमत होना होगा कि की-जोड़ी UX के बारे में जो कहा गया था, वह बहुत उपयोगकर्ता के अनुकूल नहीं है।

यह एक देशी मोबाइल ऐप बनाना बहुत कठिन बनाता है जो इस प्रामाणिक पद्धति का उपयोग कर सकता है।

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

स्वीकृत (सजा का इरादा), JWT OAuth1a की तुलना में बहुत आसान है;)

चूंकि उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड का उपयोग करके पहली बार वर्डप्रेस (उम्मीद है कि https के माध्यम से) में लॉग इन करना पड़ता है, इसलिए मैं वास्तव में नहीं देखता कि उपयोगकर्ता नाम/पासवर्ड जोड़ी को एक्सेस टोकन प्राप्त करने में सक्षम होने की सुरक्षा समस्या क्या है ? यह सब दिन के अंत में एक ही 'तार' पर भेजा जा रहा है? निश्चित रूप से?

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

उन्हें दर्ज करने के लिए मोबाइल ऐप प्राप्त करने का कोई समझदार तरीका नहीं है।

मैंने अपने मूल ऐप्स को एक्सेस के साथ लागू करने के लिए OAuth1a, OAuth2 और अब दो JWT प्लगइन्स की कोशिश की है और वे सभी 'आउट-ऑफ-द-बॉक्स' विफल हो जाते हैं, बिना कुछ हैकिंग के कोशिश करने और चीजों को उपयोगकर्ता के लिए काम करने के लिए। यह सामान आसान होना चाहिए, निश्चित रूप से?

तृतीय-पक्ष JWT प्लगइन (10,000+ इंस्टॉल के साथ) उपयोगकर्ता/पास का समर्थन करता है, और मेरे द्वारा बनाए जा रहे मूल मोबाइल एप्लिकेशन के लिए अच्छी तरह से काम करता है। लेकिन यह प्लगइन के माध्यम से ताज़ा टोकन की कमी पर विफल हो जाता है, जिससे उपयोगकर्ता को फिर से 'लॉग इन' करने के लिए मजबूर होना पड़ता है। (इसे wp-config के मैन्युअल संपादन की भी आवश्यकता है)

यह 'जल्द-से-आधिकारिक' (मुझे आशा है!) प्लगइन मोबाइल-उपयोगकर्ता-मित्रता की कमी पर विफल हो जाता है और प्रतीत होता है कि इसके लिए वास्तविक रूप से किस प्रकार के एप्लिकेशन विकसित किए जा सकते हैं। और यह बहुत ही अदूरदर्शी लगता है।

wp.org साइटों पर पोस्ट करने के लिए मूल मोबाइल ऐप्स की कमी का एक कारण है। और यह है।

कृपया, कृपया, क्या हम इस पर कुछ आंदोलन कर सकते हैं? (मैं आरईएसटी एपीआई की शुरुआत के बाद से उपयोगकर्ताओं को प्रमाणीकृत करने के लिए 'उचित' तरीके की प्रतीक्षा कर रहा हूं, अब मैं मूल ऐप पर काम कर रहा हूं)

:)

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

उपयोगकर्ता लॉगिन> टोकन प्रवाह के साथ यह समस्या गंभीरता से इतने सारे ऐप के विकास को रोक रही है जो JWT का उपयोग कर सकते हैं।

महीने और महीने चलते रहते हैं और इसे संबोधित नहीं किया जा रहा है।

जैसा कि मैंने ऊपर कहा है, तथ्य यह है कि उपयोगकर्ता उपयोगकर्ता नाम/पासवर्ड जोड़ी का उपयोग वास्तव में व्यवस्थापक में लॉग इन करने के लिए करते हैं, टोकन प्राप्त करने के लिए उपयोगकर्ता नाम/पासवर्ड जोड़े का उपयोग न करने के लिए कोई तर्क कुछ हद तक अमान्य लगता है? निश्चित रूप से?

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

यदि आप इसमें शामिल होना चाहते हैं, तो बेझिझक #core-restapi ऑन स्लैक पर जाएं ।