403 ممنوع مقابل 401 ردود المتشعب غير المصرح بها

https://stackoverflow.com/questions/3297048

18-09-2020
|

سؤال

لصفحة ويب موجود, ولكن الذي لم يكن لدى المستخدم امتيازات كافية (لم يتم تسجيل دخولهم أو لا تنتمي إلى مجموعة المستخدمين المناسبة), ما هو استجابة هتب المناسبة لخدمة?

401 Unauthorized?
403 Forbidden?
شيء آخر?

ما قرأته في كل منهما حتى الآن ليس واضحا جدا بشأن الفرق بين الاثنين.ما هي حالات الاستخدام المناسبة لكل استجابة?

المحلول

شرح واضح من دانييل ايرفين :

هناك مشكلة في 401 غير المصرح به ، رمز حالة HTTP لأخطاء المصادقة. وهذا فقط: إنه للمصادقة، وليس إذن. تلقي استجابة 401 هو الخادم يقول لك، "أنت لست كذلك مصادقة - إما غير مصادقة على الإطلاق أو المصادقة بشكل غير صحيح - ولكن يرجى إعادة النظر والمحاولة مرة أخرى. " لمساعدتك، وسوف تشمل دائما مصادقة WWW رأس وصف كيف للمصادقة.

هذا هو استجابة عموما يتم إرجاعها بواسطة خادم الويب الخاص بك، وليس الويب الخاص بك تطبيق.

هو أيضا شيء مؤقت للغاية؛ الخادم يطلب منك أن تجرب مرة أخرى.

لذلك، للحصول على استجابة 403 محظورة . انها دائم، هو مرتبط بمنطق طلبي، وهو ملموسة أكثر استجابة من 401.

تلقي استجابة 403 هو الخادم يقول لك، "أنا آسف. أنا أعرف من أنت - أعتقد من تقوله أنت - لكنك لم يكن لديك إذن للوصول إلى هذا المورد. ربما إذا كنت تسأل النظام المسؤول بشكل جيد، ستحصل على إذن. ولكن من فضلك لا تهتم لي مرة أخرى حتى تتغير مأزقك. "

باختصار، ينبغي استخدام استجابة 401 غير المصرح به أو يجب استخدام مصادقة سيئة، ورد 403 ممنوع بعد ذلك، عندما يتم مصادقة المستخدم ولكن غير مصرح له أداء العملية المطلوبة على المورد المحدد.

آخر تنسيق Pictorial Nice كيف يجب أن تكون رموز حالة HTTP تستخدم.

نصائح أخرى

شاهد RFC2616 :

401 غير مصرح به:

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

403 ممنوع:

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

تحديث

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

تحرير: RFC2616 هو عفا عليها الزمن، انظر rfc7231 و rfc7235 .

شيء ما هي الإجابات الأخرى مفقودة هي أنه يجب فهمه أن المصادقة والترخيص في سياق RFC 2616 يشير فقط إلى بروتوكول مصادقة HTTP 2617. لم يتم دعم المصادقة من قبل المخططات خارج RFC2617 في رموز حالة HTTP و لا تعتبر عند اتخاذ قرار بشأن استخدام 401 أو 403.

موجز ومتدرج

يشير

غير مصرح به إلى أن العميل ليس مصادقة RFC2617 ويبدأ الخادم عملية المصادقة. يشير ممنوع إما إلى أن العميل مصادقة RFC2617 وليس لديه إذن أو أن الخادم لا يدعم RFC2617 للمورد المطلوب.

بمعنى ما إذا كان لديك عملية تسجيل دخول خاصة بك، ولا تستخدم مصادقة HTTP الخاصة بك، فسيكون 403 دائما الاستجابة المناسبة و 401 لا ينبغي أبدا استخدامها.

مفصل ومتعمق

من RFC2616

10.4.2 401 غير مصرح به

يتطلب الطلب مصادقة المستخدم. يجب أن تتضمن الاستجابة حقل رأس مصادقة WWW (القسم 14.47) الذي يحتوي على تحدي ينطبق على المورد المطلوب. قد يكرر العميل الطلب مع حقل رأس تفويض مناسب (القسم 14.8).

10.4.4 403 ممنوع يفهم الخادم الطلب ولكنه يرفض تحقيقه. لن يساعد التخويل ويجب عدم تكرار الطلب.

أول شيء يجب وضعه في الاعتبار هو أن "المصادقة" و "إذن" في سياق هذه الوثيقة تشير خصيصا إلى بروتوكولات مصادقة HTTP من RFC 2617. إنهم لا يشيرون إلى أي بروتوكولات مصادقة خاصة بك قد تكون قد تم إنشاؤها باستخدام صفحات تسجيل الدخول، وما إلى ذلك، وسأستخدم "تسجيل الدخول" للإشارة إلى المصادقة والترخيص حسب الطرق غير RFC2617

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

يشير

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

يشير

403 إلى أنه لا يمكن توفير المورد وهناك، بالنسبة للمستخدم الحالي، بأي حال من الأحوال لحل هذا من خلال RFC2617 ولا نقطة في المحاولة. قد يكون هذا لأنه من المعروف أنه لا يوجد مستوى من المصادقة كافية (على سبيل المثال بسبب قائمة IP Black)، ولكن قد يكون الأمر لأن المستخدم مصادق بالفعل وليس لديه سلطة. Model RFC2617 هو مستخدم واحد، وبيانات اعتماد واحدة لذلك قد يتم تجاهل الحالة التي قد يكون فيها المستخدم مجموعة ثانية من بيانات الاعتماد التي يمكن أذنها. لا يقترح ولا يعني أن نوعا من صفحة تسجيل الدخول أو غيره من بروتوكول مصادقة RFC2617 قد لا يساعد أو لا يساعد - هذا خارج معايير RFC2616 وتعريفه.

تحرير: RFC2616 هو عفا عليها الزمن، انظر rfc7231 و rfc7235 .

  +-----------------------
  | RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
  +-----------------------
    |       |
 NO |       v YES
    v      +-----------------------
   404     | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
   or      +-----------------------
   401        |              |
   403     NO |              | YES
   3xx        v              v
              401            +-----------------------
       (404 no reveal)       | CAN ACCESS RESOURCE ? (permission, authorized, ...)
              or             +-----------------------
             redirect          |            |
             to login       NO |            | YES
                               |            |
                               v            v
                               403          OK 200, redirect, ...
                      (or 404: no reveal)
                      (or 404: resource does not exist if private)
                      (or 3xx: redirection)

عادة ما يتم إجراء الفحوصات بهذا الترتيب:

404 إذا كان المورد عامًا وغير موجود أو إعادة توجيه 3xx
خلاف ذلك:
401 إذا لم يتم تسجيل الدخول أو انتهت صلاحية الجلسة
403 إذا لم يكن لدى المستخدم إذن للوصول إلى المورد (ملف، json، ...)
404 إذا كان المورد غير موجود أو غير مستعد للكشف عن أي شيء، أو إعادة توجيه 3xx

غير مصرح:رمز الحالة (401) يشير إلى أن الطلب يتطلب المصادقة, ، وهذا يعني عادةً أن المستخدم يحتاج إلى تسجيل الدخول (الجلسة).المستخدم/الوكيل غير معروف من قبل الخادم.يمكن تكرارها مع بيانات اعتماد أخرى.ملحوظة:وهذا أمر مربك لأنه كان ينبغي تسمية هذا بـ "غير مصادق عليه" بدلاً من "غير مصرح به".يمكن أن يحدث هذا أيضًا بعد تسجيل الدخول إذا انتهت صلاحية الجلسة.حالة خاصة:يمكن استخدامه بدلاً من 404 لتجنب الكشف عن وجود أو عدم وجود المورد (اعتمادات @gingerCodeNinja)

مُحرَّم:رمز الحالة (403) يشير إلى أن الخادم قد فهم الطلب ولكنه رفض تنفيذه.المستخدم/الوكيل معروف بواسطة الخادم ولكن لديه أوراق اعتماد غير كافية.لن ينجح الطلب المتكرر، إلا إذا تم تغيير بيانات الاعتماد، وهو أمر مستبعد جدًا خلال فترة زمنية قصيرة.حالة خاصة:يمكن استخدامه بدلاً من 404 لتجنب الكشف عن وجود أو عدم وجود المورد (اعتمادات @gingerCodeNinja)

غير معثور عليه:رمز الحالة (404) يشير إلى عدم توفر المورد المطلوب.المستخدم/الوكيل معروف ولكن الخادم لن يكشف أي شيء عن المورد، وسيفعل كما لو أنه غير موجود.التكرار لن ينجح.هذا استخدام خاص لـ 404 (يفعله جيثب على سبيل المثال).

كما ذكر @ChrisH، هناك بعض الخيارات لـ إعادة التوجيه 3xx (301، 302، 303، 307 أو عدم إعادة التوجيه على الإطلاق واستخدام 401):

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

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

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

بافتراض مصادقة HTTP (مصادقة WWW و تفويض الرؤوس) قيد الاستخدام, ، إذا كانت المصادقة كمستخدم آخر ستمنح الوصول إلى المورد المطلوب، فيجب إرجاع 401 Unauthorized.

يتم استخدام 403 Forbidden عندما يكون الوصول إلى المورد محظورًا على الجميع أو مقيدًا بشبكة معينة أو مسموحًا به فقط عبر SSL، أيًا كان طالما أنه لا يتعلق بمصادقة HTTP.

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

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

3.1.401 غير مصرح به

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

لقد تغيرت دلالات 403 (و 404) بمرور الوقت.هذا من عام 1999 (RFC 2616):

10.4.4 403 ممنوع

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

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

6.5.3.403 ممنوع

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

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

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

وبالتالي، فإن الرقم 403 (أو 404) قد يعني الآن أي شيء.قد يساعد تقديم بيانات اعتماد جديدة...أو ربما لا.

أعتقد أن سبب تغيير هذا هو أن RFC 2616 يفترض أنه سيتم استخدام مصادقة HTTP عندما تقوم تطبيقات الويب الحالية ببناء أنظمة مصادقة مخصصة باستخدام النماذج وملفات تعريف الارتباط على سبيل المثال.

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

هذا سؤال أقدم، ولكن خيار واحد لم ينشأ أبدا عن إرجاع 404. من منظور أمني، تعاني أعلى إجابة صوتية من إمكانات عدم حصانة تسرب المعلومات .قل، على سبيل المثال، أن صفحة الويب الآمنة المعنية المعنية هي صفحة مسؤول النظام، أو ربما أكثر شيوعا، هو سجل في نظام لا يحتوي المستخدم على الوصول إليه.من الناحية المثالية، لن ترغب في معرفة مستخدم ضار حتى أن هناك صفحة / سجل هناك، ناهيك عن عدم إمكانية الوصول إليها.عندما أقوم ببناء شيء من هذا القبيل، سأحاول تسجيل الطلبات غير الأصلية / غير المصرح بها في سجل داخلي، ولكن إرجاع 404.

لدى owasp بعض مزيد من المعلومات حول كيف يمكن للمهاجم استخدام هذا النوعمن المعلومات كجزء من الهجوم.

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

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

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

لقد أكد قليلا على ما أعتقد أنه أكثر وضوحا.

6.5.3. 403 ممنوع

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

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

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

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

ليرة تركية؛ د

401:الرفض الذي له علاقة بالمصادقة
403:رفض لا علاقة له بالمصادقة

أمثلة عملية

لو أباتشي يتطلب المصادقة (عبر .htaccess) ، وضربت Cancel, ، وسوف يستجيب مع 401 Authorization Required

لو nginx يجد ملفا، ولكن ليس لديه حقوق الوصول (مستخدم/مجموعة) لقراءته/الوصول إليه، وسوف يستجيب به 403 Forbidden

RFC (2616 القسم 10)

401 غير مصرح به (10.4.2)

المعنى 1: بحاجة إلى المصادقة

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

المعنى 2: المصادقة غير كافية

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

403 ممنوع (10.4.4)

معنى: لا علاقة لها بالمصادقة

...لن يساعد التفويض ...

المزيد من التفاصيل:

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

(إذا كان الخادم يريد الاحتفاظ بهذه المعلومات من العميل)

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

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

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

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

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

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

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

باللغة الإنجليزية:

401

قد يسمح لك بالوصول ولكن لسبب ما في هذا الطلب كنت رفض.مثل كلمة مرور سيئة؟حاول مرة أخرى، مع الطلب الصحيح سوف تحصل على استجابة النجاح بدلا من ذلك.

403

أنت لست، على الإطلاق، المسموح بها.اسمك ليس في القائمة، فلن من أي وقت مضى، ابتعد، لا ترسل طلب إعادة المحاولة، وسيتم رفضه، دائما.اذهب بعيدا.

هذه هي المعاني:

401 : المستخدم غير محدد (بشكل صحيح) مصادقة، المورد / الصفحة تتطلب المصادقة

403 : مصادقة المستخدم، ولكن دوره أو أذوناته لا يسمح بالوصول إلى الموارد المطلوبة، على سبيل المثال، المستخدم ليس مسؤولا وصفحة مطلوبة مخصصة للمسؤولين

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

401:تحتاج هتب المصادقة الأساسية لرؤية هذا.

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

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

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

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

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

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

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

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

المورد يتطلب المصادقة ولكن لا أوراق اعتماد كان محدد.

401:يجب على العميل تحديد بيانات الاعتماد.

بيانات الاعتماد المحددة موجودة في تنسيق غير صالح.

400:هذا ليس 401 ولا 403، حيث أن أخطاء بناء الجملة يجب أن تُرجع دائمًا 400.

تشير بيانات الاعتماد المحددة أ مستخدم أيّ غير موجود.

401:يجب على العميل تحديد بيانات اعتماد صالحة.

المحدد أوراق اعتماد نكون غير صالح ولكن حدد مستخدمًا صالحًا (أو لا تحدد مستخدمًا إذا لم يكن المستخدم المحدد مطلوبًا).

401:مرة أخرى، يجب على العميل تحديد بيانات اعتماد صالحة.

المحدد أوراق اعتماد يملك منتهي الصلاحية.

401:وهذا يشبه عمليًا وجود بيانات اعتماد غير صالحة بشكل عام، لذلك يجب على العميل تحديد بيانات اعتماد صالحة.

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

403:لن يؤدي تحديد بيانات اعتماد صالحة إلى منح الوصول إلى المورد، حيث أن بيانات الاعتماد الحالية صالحة بالفعل ولكنها لا تملك إذنًا.

على وجه الخصوص الموارد يكون لا يمكن الوصول إليه بغض النظر عن أوراق الاعتماد.

403:وهذا بغض النظر عن بيانات الاعتماد، لذا فإن تحديد بيانات اعتماد صالحة لا يمكن أن يساعد.

بيانات الاعتماد المحددة صالحة تمامًا ولكنها خاصة عميل يكون محظور من استخدامها.

403:إذا تم حظر العميل، فإن تحديد بيانات الاعتماد الجديدة لن يؤدي إلى أي شيء.

Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):

401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'

401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'

403 Forbidden

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.

There seems to be a question on the roll-your-own-login issue (application).

In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:

"I heard you, it's here, but try this instead (you are not allowed to see it)"

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow