Oauthlib: त्रुटि प्रतिक्रिया पर अमान्य HTTP स्थितियाँ

कल्पना का उल्लेख है कि 401 का उपयोग अमान्य क्लाइंट त्रुटियों के साथ किया जा सकता है और इसका उपयोग तब किया जाना चाहिए जब प्रमाणीकरण शीर्षलेख फ़ील्ड के माध्यम से प्रमाणीकरण किया गया हो। हालांकि oauthlib वर्तमान में यह सुझाव देने के लिए कुछ भी नहीं करता है कि 'WWW-Authenticate' हेडर फ़ील्ड को प्रतिक्रिया में शामिल किया जाना चाहिए क्योंकि कल्पना की आवश्यकता होती है। मुझे लगता है कि इस त्रुटि के लिए 401 रखना ठीक है लेकिन हमें अपवाद में एक शीर्षलेख सुझाव जोड़ना चाहिए।

दूसरे के बारे में कल्पना स्पष्ट रूप से नहीं कहती है कि 401 का उपयोग किया जा सकता है और इस प्रकार हमें शायद 400 में बदलने पर विचार करना चाहिए। हालांकि यह अमान्य अनुदान और विशेष रूप से अनधिकृत क्लाइंट त्रुटियों दोनों में 401 के साथ अधिक उपयुक्त प्रतीत होता है।

@asteinlein , @lepture , @masci विचार?

@ ib-lundgren हाय - बस इसी मुद्दे पर ठोकर खाई और इसमें झंकार करना चाहूंगा। कल्पना को पढ़ने और अन्य उत्तरों को देखने से, IMO 400 सही प्रतिक्रिया है।

सबसे पहले, विशिष्टता:

प्राधिकरण सर्वर एक HTTP 400 (खराब अनुरोध) के साथ प्रतिक्रिया करता है
स्थिति कोड (जब तक अन्यथा निर्दिष्ट न हो) और इसमें निम्नलिखित शामिल हैं
प्रतिक्रिया के साथ पैरामीटर:

400 आवश्यकताओं में कोई MUST नहीं है, लेकिन कोई MAY भी नहीं है।

दूसरा, और जिस कारण से मैंने ठोकर खाई वह मेरे क्लाइंट पर सूर्य जेडीके में एक प्रकार की बग के माध्यम से था (यहां देखें: http://stackoverflow.com/a/7524681/1137254 )

अनिवार्य रूप से, मेरे क्लाइंट का HTTP स्टैक 401 के लिए कनेक्शन को जल्दी बंद कर देगा, लेकिन ऊपर OAuth स्टैक (google-http-oauth-client) परिणामों को पढ़ना और पार्स करना जारी रखने का प्रयास करेगा। मुझे लगता है कि यह 401 के आसपास परिभाषा और अपेक्षाओं के अनुसार ओपनजेडीके में लिखा गया था (अद्यतन: यह वास्तव में 'स्ट्रीमिंग' मोड के साथ करना है)। आईएमओ ओपनजेडीके भी गलत है और मुझे लगता है कि अगर मैं/टोकन एंडपॉइंट अनुरोधों के दौरान "अमान्य_क्लाइंट" 401 प्राप्त करना चाहता हूं तो मुझे यह वही समस्या होगी।

400 के लिए एक और वोट जोड़ना यहां सही त्रुटि कोड है। हम मोबाइल ऐप से oauth2 प्रमाणीकरण के लिए django-oauth2-provider का उपयोग करते थे, और इस मामले में यह 400 वापस आ गया। नए Django संस्करणों में अपग्रेड करने के लिए django-oauth-toolkit (जो oauthlib का उपयोग करता है) पर स्विच करते समय, हमें मोबाइल ऐप्स को सही ढंग से काम करने के लिए 400 को वापस करने के लिए टोकन अनुरोध दृश्य को हैक करना पड़ा।

यहाँ विशेष रूप से यह बताते हुए कि 400 एक टोकन का अनुरोध करते समय अमान्य प्रमाणीकरण क्रेडेंशियल के लिए इच्छित प्रतिक्रिया है, और क्यों: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

और यहां एक प्रोजेक्ट का एक और उदाहरण है जिसमें इन परिस्थितियों में 401 का उपयोग करके ओथलिब से मुकाबला करने में समस्या हो रही है।

400 . के लिए +1

400 . के लिए वोट करें

मैं इस पुराने धागे को पुनर्जीवित कर रहा हूं और ऊपर सुझाए गए परिवर्तनों के साथ एक पीआर शुरू कर रहा हूं।

इस पर आगे बढ़ने से पहले, मैं अतीत में हुई चर्चा को संक्षेप में बताना चाहूंगा।

• OAuth2.0 RFC6749 वर्किंग ग्रुप ने 401 के बजाय त्रुटि HTTP स्थिति के लिए 400 अपनाने का निर्णय लिया, क्योंकि इसे सेट करने के लिए WWW-Authenticate की आवश्यकता होती है, और यह सभी त्रुटि प्रतिक्रियाओं में हमेशा संभव नहीं होता है।
• @asteinlein ने oauthlib की त्रुटियों को 400 से 401 में बदलने के लिए https://github.com/oauthlib/oauthlib/pull/247 पर एक पीआर प्रस्तावित किया, क्योंकि _some क्लाइंट प्राधिकरण_ से संबंधित API कॉल के लिए 401 की अपेक्षा करते हैं। जबकि यह सच होना था, हम नहीं जानते कि कौन से ग्राहक टूट गए थे।
• तृतीय पक्ष पुस्तकालयों में कई बग पॉपअप https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https://github .com/oauthjs/angular-oauth2/issues/36 । मुद्दे अब सब बंद हैं।
• वर्तमान थ्रेड और RFC6749#5.2 की समग्र सहमति यह है कि oauthlib में सभी 401 400 होने चाहिए। हालांकि, हमारे पास दो मामले हैं 401 :

1. invalid_client , जहां यह होना चाहिए 401 यदि HTTP प्रमाणीकरण का उपयोग किया जाता है, अन्यथा यह 401 हो सकता है।
2. invalid_token , जहां इसे 401 होना चाहिए ।

किसी भी स्थिति में, यदि 401 का उपयोग किया जाता है, तो WWW-Authenticate अवश्य सेट किया जाना चाहिए ( RFC2616 )।

अन्य OAuth2.0 कार्यान्वयन

सबसे आम OAuth2.0 कार्यान्वयन का एक त्वरित अवलोकन समग्र आम सहमति के समान है:

• Google 400 so-question / so-question लौटाता है।
• सेल्सफोर्स 400 सेल्सफोर्स-फोरम लौटाता है।
• अज़ूर 401 के साथ WWW-Authenticate azur-docs लौटाता है।
• AWS 400 aws-cognito-docs लौटाता है। जब HTTP प्रमाणीकरण का उपयोग किया जाता है तो उन्होंने RFC के " MUST " को 401 तोड़ दिया।

भ्रम

हमें आरएफसी के साथ संरेखित करना होगा, हालांकि किसी भी कार्यान्वयन को तोड़ने के लिए, हमें इन परिवर्तनों को 2.xx संस्करण में शामिल नहीं करना चाहिए, लेकिन 3.xx तक प्रतीक्षा करें।

कृपया, बेझिझक इसमें शामिल हों।

मुझे उस कारण/ग्राहकों को याद नहीं है जिसने मुझे पीआर #247 धक्का दिया, लेकिन मैं इसे वापस करने के कारणों को देखता हूं और समझता हूं। @JonathanHuot के शानदार शोध के लिए धन्यवाद, और 3.x में ऐसा करना सबसे अच्छा तरीका लगता है।

#561 / oauthlib>= 3.0.0 . में फिक्स्ड

इस RFC के अनुसार, जिसका उल्लेख ऊपर किया गया है, अमान्य क्लाइंट को भी स्थिति 400 वापस करनी चाहिए, लेकिन पैकेज में अभी भी 401 है

हाय @esfandiaryfard , क्या आप RFC के सटीक पाठ को इंगित कर सकते हैं? धन्यवाद!