http-headers robots txt - 403 ممنوع مقابل 401 استجابات HTTP غير مصرح بها





7 Answers

انظر RFC2616 :

401 غير مصرح به:

إذا كان الطلب يتضمن بالفعل بيانات اعتماد التخويل ، فإن استجابة 401 تشير إلى أنه تم رفض الترخيص لبيانات الاعتماد هذه.

403 ممنوع:

يفهم الخادم الطلب ، ولكنه يرفض تنفيذه.

تحديث

من حالة استخدامك ، يبدو أن المستخدم لم تتم المصادقة عليه. سأعود 401.

تحرير: RFC2616 مهمل ، راجع RFC7231 و RFC7235 .

disallow search

بالنسبة لصفحة الويب الموجودة ، ولكن للمستخدم الذي لا يمتلك امتيازات كافية ، (لم يتم تسجيل دخوله أو لا ينتمي إلى مجموعة المستخدمين المناسبة) ، ما هو استجابة HTTP المناسبة للعرض؟ 401؟ 403؟ شيء آخر؟ ما قرأته في كل واحدة حتى الآن ليس واضحًا تمامًا عن الفرق بين الاثنين. ما حالات الاستخدام المناسبة لكل رد؟




وفقًا لـ RFC 2616 (HTTP / 1.1) ، يتم إرسال 403 عندما:

يفهم الخادم الطلب ، ولكنه يرفض تنفيذه. لن يساعد التفويض وينبغي عدم تكرار الطلب. إذا لم تكن طريقة الطلب هي HEAD ورغب الخادم في الكشف عن سبب عدم تلبية الطلب ، فيجب أن يصف سبب الرفض في الكيان. إذا كان الخادم لا يرغب في إتاحة هذه المعلومات للعميل ، فيمكن استخدام رمز الحالة 404 (غير موجود) بدلاً من ذلك

وبعبارة أخرى ، إذا كان العميل يمكنه الوصول إلى المورد عن طريق المصادقة ، فيجب إرسال 401.




في حالة المصادقة على أنه مستخدم آخر سيسمح بالوصول إلى المورد المطلوب ، فيجب عندئذٍ إرجاع 401 غير مصرح به. 403 يُحظر استخدام المحرمات في الغالب عندما يكون الوصول إلى المورد محظورًا على الجميع أو يقتصر على شبكة معينة أو يسمح به فقط عبر طبقة المقابس الآمنة (SSL) ، بغض النظر عن عدم ارتباطها بالمصادقة.

من RFC 7235 (بروتوكول نقل النص التشعبي (HTTP / 1.1): المصادقة):

3.1. 401 غير مصرح به

يشير رمز الحالة 401 (غير مصرح به) إلى أنه لم يتم تطبيق الطلب لأنه يفتقر إلى بيانات اعتماد المصادقة الصالحة للمورد الهدف. يجب على خادم المصدر إرسال حقل رأس WWW-Authenticate (القسم 4.4) يحتوي على تحد واحد على الأقل ينطبق على المورد المستهدف. إذا تضمن الطلب بيانات اعتماد المصادقة ، فإن استجابة 401 تشير إلى أنه تم رفض الترخيص لبيانات الاعتماد هذه . قد يقوم العميل بتكرار الطلب مع حقل رأس مصادقة جديد أو مستبدل (القسم 4.1). إذا كانت استجابة 401 تحتوي على نفس التحدي مثل الاستجابة السابقة ، وسبق أن حاول وكيل المستخدم المصادقة مرة واحدة على الأقل ، فيجب على وكيل المستخدم تقديم التمثيل المرفق للمستخدم ، لأنه عادةً ما يحتوي على معلومات تشخيصية ذات صلة.

وهذا من RFC 2616:

10.4.4 403 ممنوع

يفهم الخادم الطلب ، ولكنه يرفض تنفيذه.
لن يساعد التفويض وينبغي عدم تكرار الطلب.
إذا لم تكن طريقة الطلب هي HEAD ورغب الخادم في القيام بها
لماذا لم يتم استيفاء الطلب ، يجب أن تصف سبب الرفض في الكيان. إذا كان الخادم لا يرغب في إتاحة هذه المعلومات للعميل ، رمز الحالة 404
(غير موجود) يمكن استخدامها بدلا من ذلك.

تحرير: RFC 7231 (بروتوكول نقل النص التشعبي (HTTP / 1.1): دلالات المحتوى والمحتوى) يغير معنى 403:

6.5.3. 403 ممنوع

يشير رمز الحالة 403 (محظور) إلى أن الخادم يفهم الطلب ولكنه يرفض اعتماده. يمكن لوحدة الخدمة التي ترغب في الكشف عن سبب حظر الطلب أن تصف هذا السبب في حمولة الاستجابة (إن وجدت).

إذا تم توفير بيانات اعتماد المصادقة في الطلب ، فإن
الخادم يعتبرها غير كافية لمنح الوصول. الزبون
يجب ألا يكرر الطلب تلقائيًا بنفس الطريقة
شهاداته. يمكن للعميل تكرار الطلب بأوراق اعتماد جديدة أو مختلفة. ومع ذلك ، قد يتم حظر الطلب لأسباب
غير متعلق ببيانات الاعتماد.

خادم أصل يرغب في "إخفاء" الوجود الحالي لـ
الموارد الهدف المحرمة قد تستجيب بدلا من ذلك مع رمز الحالة
404 غير موجود).

وهكذا ، قد يعني 403 الآن أي شيء. قد يساعد تقديم بيانات اعتماد جديدة ... أو ربما لا.




تم طرح هذا السؤال منذ بعض الوقت ، لكن تفكير الناس يتحرك.

يعطي القسم 6.5.3 في هذا المسودة (تأليف Fielding و Reschke) رمز الحالة 403 بمعنى مختلف قليلاً عن ذلك الموثق في RFC 2616 .

وهو يعكس ما يحدث في مخططات التوثيق والتخويل التي يستخدمها عدد من خوادم الويب وأطر العمل الشائعة.

لقد شدّدت على الشيء الذي أعتقد أنه الأكثر بروزًا.

6.5.3. 403 ممنوع

يشير رمز الحالة 403 (محظور) إلى أن الخادم يفهم الطلب ولكنه يرفض اعتماده. يمكن لوحدة الخدمة التي ترغب في الكشف عن سبب حظر الطلب أن تصف هذا السبب في حمولة الاستجابة (إن وجدت).

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

خادم أصل يرغب في "إخفاء" الوجود الحالي لمورد الهدف المحظور MAY بدلاً من ذلك يستجيب برمز الحالة 404 (غير موجود).

مهما كانت الاتفاقية التي تستخدمها ، فإن الشيء المهم هو توفير التوحيد عبر موقعك / API.




لم يتم تسجيل الدخول أو لا ينتمي إلى مجموعة المستخدم المناسبة

لقد ذكرت حالتين مختلفتين ؛ يجب أن يكون لكل حالة استجابة مختلفة:

  1. إذا لم يتم تسجيل الدخول على الإطلاق يجب عليك العودة 401 غير مصرح به
  2. إذا تم تسجيل دخولهم ولكنهم لا ينتمون إلى مجموعة المستخدمين المناسبة ، فيجب عليك إرجاع 403 محظور

ملاحظة حول RFC استنادًا إلى التعليقات المستلمة على هذه الإجابة:

إذا لم يقم المستخدم بتسجيل الدخول ، فسيكون غير مصادق عليه ، وهو ما يعادل HTTP وهو 401 ويسمى بشكل خاطئ Unauthorized في RFC. كما تنص المادة 10.4.2 على 401 غير مصرح بها :

"يتطلب الطلب مصادقة المستخدم."

إذا لم تكن مصادقًا ، فسيكون 401 هو الاستجابة الصحيحة. ومع ذلك ، إذا كنت غير مصرحًا به ، بالمعنى الصحيح لغويًا ، فسيكون 403 هو الاستجابة الصحيحة.




هذا أبسط في رأسي من أي مكان هنا ، لذلك:

401: أنت بحاجة إلى مصادقة HTTP الأساسية لترى ذلك.

403: لا يمكنك رؤية هذا ، ولن يساعد مصادقة HTTP الأساسية.

إذا كان المستخدم يحتاج فقط إلى تسجيل الدخول باستخدام نموذج تسجيل دخول HTML القياسي لموقعك ، فلن يكون 401 مناسبًا لأنه مخصص لـ HTTP basic auth.

لا أوصي باستخدام 403 لمنع الوصول إلى أشياء مثل /includes ، لأنه بقدر ما يتعلق الأمر بالويب ، لا توجد هذه الموارد على الإطلاق ويجب بالتالي 404.

هذا يترك 403 "تحتاج إلى تسجيل الدخول".

بمعنى آخر ، 403 تعني "هذا المورد يتطلب شكلاً من أنواع المصادقة غير المصادقة الأساسية لـ HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2




في حالة 401 مقابل 403 ، تمت الإجابة عليها عدة مرات. هذا هو في الأساس مناقشة "بيئة طلب HTTP" ، وليس مناقشة "التطبيق".

يبدو أن هناك مشكلة في مسألة تسجيل الدخول الخاصة بك (التطبيق).

في هذه الحالة ، ببساطة لا تكون عملية تسجيل الدخول كافية لإرسال 401 أو 403 ، إلا إذا كنت تستخدم HTTP Auth مقابل صفحة تسجيل الدخول (غير مرتبطة بإعداد HTTP Auth). يبدو أنك قد تبحث عن "201 Created" ، مع وجود شاشة تسجيل الدخول الخاصة بك (بدلاً من المورد المطلوب) للوصول إلى الملف على مستوى التطبيق. هذا يقول:

"سمعتك ، هنا ، لكن حاول هذا بدلاً من ذلك (لا يُسمح لك برؤيته)"




Related