Oauthlib: حالات HTTP غير صالحة عند الاستجابة للخطأ

تشير المواصفات إلى أنه يمكن استخدام 401 مع أخطاء العميل غير الصالحة ويجب استخدامه عند إجراء المصادقة عبر حقل رأس التفويض. على الرغم من أن oauthlib لا يقوم حاليًا بأي شيء يشير إلى أنه يجب تضمين حقل رأس "WWW-Authenticate" في الاستجابة كما تتطلب المواصفات. أعتقد أن الاحتفاظ بالرقم 401 لهذا الخطأ أمر جيد ولكن يجب علينا إضافة اقتراح رأس إلى الاستثناء.

فيما يتعلق بالمواصفات الأخرى ، لا تنص المواصفات صراحةً على أنه يمكن استخدام 401 ، وبالتالي ينبغي علينا التفكير في التغيير إلى 400. ومع ذلك ، يبدو أكثر ملاءمة مع 401 في كل من المنح غير الصالحة وأخطاء العميل غير المصرح بها بشكل خاص.

asteinlein ، lepture ، masci الأفكار؟

@ ib-lundgren مرحبًا - تعثرت للتو في هذه المشكلة بالذات وأريد أن تتناغم معها. من قراءة المواصفات والبحث حول الإجابات الأخرى ، يعد IMO a 400 هو الاستجابة الصحيحة.

أولاً ، المواصفات:

يستجيب خادم التفويض بـ HTTP 400 (طلب غير صالح)
رمز الحالة (ما لم يتم تحديد خلاف ذلك) ويتضمن ما يلي
المعلمات مع الاستجابة:

ليس هناك ما يلزم في 400 متطلبات ، ولكن ليس هناك أيضًا.

ثانيًا ، والسبب في أنني تعثرت في هذا كان من خلال خطأ من نوع ما في الشمس JDK على عميلي (انظر هنا: http://stackoverflow.com/a/7524681/1137254)

بشكل أساسي ، سيغلق مكدس HTTP الخاص بعميلي الاتصال مبكرًا لـ 401 ، لكن مكدس OAuth أعلاه (google-http-oauth-client) سيحاول متابعة قراءة النتائج وتحليلها. أعتقد أن هذا تمت كتابته في OpenJDK وفقًا للتعريف والتوقعات حول 401 (تحديث: يتعلق الأمر في الواقع بوضع "البث"). IMO OpenJDK خاطئ أيضًا وأعتقد أنني قد واجهت هذه المشكلة نفسها إذا كنت سأحصل على 401 "غير صالح" أثناء طلبات نقطة النهاية / الرمز المميز.

إضافة تصويت آخر لـ 400 هو رمز الخطأ الصحيح هنا. اعتدنا على استخدام مزود django-oauth2 لمصادقة oauth2 من تطبيقات الأجهزة المحمولة ، وأعاد 400 في هذه الحالة. عند التبديل إلى مجموعة أدوات django-oauth-toolkit (التي تستخدم oauthlib) للترقية إلى إصدارات أحدث من Django ، كان علينا اختراق عرض طلب الرمز المميز لإرجاع 400 بدلاً من ذلك للحفاظ على عمل تطبيقات الجوال بشكل صحيح.

إليك أحد مؤلفي المواصفات التي تنص على وجه التحديد على أن 400 هي الاستجابة المقصودة لبيانات اعتماد المصادقة غير الصالحة عند طلب رمز مميز ، والسبب في ذلك: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .لغة البرمجة

وإليك مثال آخر لمشروع يواجه مشكلة في التعامل مع oauthlib باستخدام 401 في هذه الظروف.

+1 مقابل 400

صوت لـ 400

أنا أقوم بإحياء هذا الموضوع القديم وأبدأ العلاقات العامة بالتغييرات المقترحة أعلاه.

قبل إحراز تقدم في هذا الأمر ، أود أن ألخص المناقشة التي حدثت في الماضي.

• قررت مجموعة العمل OAuth2.0 RFC6749 اعتماد 400 لحالة HTTP للخطأ بدلاً من 401 ، لأنها تتطلب WWW-Authenticate ليتم تعيينها ، ولا يكون ذلك ممكنًا دائمًا في جميع استجابات الأخطاء.
• اقترح asteinlein العلاقات العامة على https://github.com/oauthlib/oauthlib/pull/247 لتغيير أخطاء oauthlib من 400 إلى 401 ، لأن بعض العملاء يبدو أنهم يتوقعون 401 لمكالمات API المتعلقة بالتخويل. في حين أنه كان يجب أن يكون صحيحًا ، إلا أننا لا نعرف العملاء الذين تم كسرهم.
• العديد من الأخطاء المنبثقة في مكتبات الأطراف الثالثة https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https: // github .com / oauthjs / angular-oauth2 / قضايا / 36 . تم إغلاق جميع القضايا الآن.
• الإجماع العام لمؤشر الترابط الحالي ، وكذلك RFC6749 # 5.2 ، هو أن كل 401 في oauthlib يجب أن يكون 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 .
• إرجاع Salesforce 400 salesforce-forum .
• تقوم Azur بإرجاع 401 مع WWW-Authenticate azur-docs .
• تقوم AWS بإرجاع 400 aws-cognito-docs . لقد كسروا " MUST " الخاص بـ RFC ليكون 401 عند استخدام مصادقة HTTP.

الخلاصة

يتعين علينا التوافق مع RFC ، ولكن حتى لا نكسر أي تطبيقات ، يجب ألا ندرج هذه التغييرات في الإصدار 2.xx ، ولكن ننتظر حتى 3.xx

من فضلك ، لا تتردد في الرنين.

لا أستطيع تذكر السبب / العميل (العملاء) الذي جعلني أدفع PR # 247 ، لكني أرى وفهم أسباب التراجع عن ذلك. شكرًا على البحث الرائع JonathanHuot ، والقيام بهذا في 3.x يبدو أنه أفضل طريقة.

ثابت في # 561 / oauthlib> = 3.0.0

وفقًا لـ RFC الذي ذكر أعلاه ، يجب على العميل غير الصالح أيضًا إرجاع الحالة 400 ولكن في الحزمة لا يزال 401

مرحبًا esfandiaryfard ، هل يمكنك الإشارة إلى النص الدقيق لـ RFC؟ شكرا!