403 निषिद्ध बनाम 401 अनधिकृत HTTP प्रतिक्रियाएँ


2782

मौजूद वेब पेज के लिए, लेकिन जिसके लिए किसी उपयोगकर्ता के पास पर्याप्त विशेषाधिकार नहीं हैं (वे लॉग इन नहीं हैं या उचित उपयोगकर्ता समूह से संबंधित नहीं हैं), सेवा करने के लिए उचित HTTP प्रतिक्रिया क्या है?

401 Unauthorized?
403 Forbidden?
कुछ और?

मैंने अब तक प्रत्येक पर जो पढ़ा है, वह दोनों के बीच अंतर पर बहुत स्पष्ट नहीं है। प्रत्येक प्रतिक्रिया के लिए कौन से उपयोग के मामले उपयुक्त हैं?


357
401 a अनधिकृत ’401 होना चाहिए Un अनअथेंटेड’, समस्या हल!
क्रिस्टोफ रूसो

47
मुझे याद नहीं है कि इस सवाल के लिए मुझे और मेरे सहयोगियों को कितनी बार स्टैकओवरफ्लो में वापस आना पड़ा है। हो सकता है कि HTTP मानकों 401 और 403 के लिए नाम या वर्णन को संशोधित करने पर विचार करना चाहिए
neurite

वास्तव में, मुझे इस त्रुटि का एक अलग संस्करण मिल रहा है। जैसे "os_authType 'कोई भी था और एक अवैध कुकी भेजी गई थी"। तो यह पता लगाने में असमर्थ है कि कैसे हल किया जाए। बहुत समय गुज़रा, कारण मिले लेकिन समाधान नहीं मिला।
संदीप आनंद

@Qwerty नहीं, नया RFC7231 RFC2616 का पालन करता है। 403 का अब एक अलग अर्थ है।
मछली पालन

1
@ फ़िशबोन आपने यह भी ध्यान नहीं दिया कि स्टेटस कोड 401 को उस RFC से हटा दिया गया है: D
Barkermn01

जवाबों:


4110

डैनियल इरविन की एक स्पष्ट व्याख्या :

प्रमाणीकरण त्रुटियों के लिए HTTP स्थिति कोड 401 अनधिकृत के साथ एक समस्या है । और यह सिर्फ यह है: यह प्रमाणीकरण के लिए है, प्राधिकरण नहीं। 401 की प्रतिक्रिया प्राप्त करना सर्वर आपको बता रहा है, "आप प्रमाणित नहीं हैं- या तो बिल्कुल भी प्रमाणित नहीं है या गलत तरीके से प्रमाणित है - लेकिन कृपया फिर से विचार करें और पुनः प्रयास करें।" आपकी सहायता करने के लिए, इसमें हमेशा एक WWW-Authenticate हेडर शामिल होगा जो वर्णन करता है कि कैसे प्रमाणित किया जाए।

यह एक प्रतिक्रिया है जो आमतौर पर आपके वेब सर्वर द्वारा लौटाई जाती है, न कि आपके वेब एप्लिकेशन द्वारा।

यह भी बहुत अस्थायी है; सर्वर आपको फिर से प्रयास करने के लिए कह रहा है।

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

403 प्रतिसाद प्राप्त करना सर्वर आपको बता रहा है, “मुझे क्षमा करें। मुझे पता है कि आप कौन हैं - मेरा मानना ​​है कि आप जो कहते हैं, आप हैं - लेकिन आपको इस संसाधन तक पहुंचने की अनुमति नहीं है। हो सकता है कि अगर आप सिस्टम एडमिनिस्ट्रेटर से अच्छी तरह पूछें, तो आपको अनुमति मिल जाएगी। लेकिन जब तक आपकी भविष्यवाणी नहीं बदल जाती कृपया मुझे परेशान न करें।

सारांश में, एक 401 अनधिकृत प्रतिक्रिया का उपयोग लापता या खराब प्रमाणीकरण के लिए किया जाना चाहिए, और 403 निषिद्ध प्रतिक्रिया का उपयोग बाद में किया जाना चाहिए, जब उपयोगकर्ता प्रमाणित होता है लेकिन दिए गए संसाधन पर अनुरोधित ऑपरेशन करने के लिए अधिकृत नहीं है।

Http स्थिति कोड का उपयोग कैसे किया जाना चाहिए इसका एक और अच्छा सचित्र प्रारूप

यहां छवि विवरण दर्ज करें


43
डिफ़ॉल्ट IIS 403 संदेश "यह एक सामान्य 403 त्रुटि है और इसका अर्थ है कि प्रमाणित उपयोगकर्ता पृष्ठ देखने के लिए अधिकृत नहीं है", जो सहमत प्रतीत होगा।
बेन चैलेंजर

332
@JPReddy आपका उत्तर सही है। हालाँकि, मैं उम्मीद करूंगा कि 401 को "अनअथेंटेड" और 403 को "अनधिकृत" नाम दिया जाएगा। यह बहुत भ्रामक है कि 401, जिसे प्रमाणीकरण के साथ करना है, पाठ "अनधिकृत" के साथ प्रारूप है। जब तक कि मैं अंग्रेजी में अच्छा नहीं हूं (जो काफी संभावना है)।
p.matsinopoulos

64
@ZaidMasud, RFC के अनुसार यह व्याख्या सही नहीं है। कुंबाय का जवाब सही निकला। 401 का अर्थ है "आप सही प्राधिकरण को याद कर रहे हैं"। इसका अर्थ है "यदि आप चाहते हैं कि आप स्वयं को प्रमाणित करने का प्रयास करें"। तो एक ग्राहक जो अपने आप को सही ढंग से प्रमाणित नहीं करता है और एक उचित रूप से प्रमाणित ग्राहक को लापता होने पर प्राधिकरण को 401 मिलेगा। 403 का अर्थ है "मैं इस बात का जवाब नहीं दूंगा कि आप कौन हैं"। 403 के मामले में RFC ने स्पष्ट रूप से कहा था कि "प्राधिकरण मदद नहीं करेगा"
डेविड आर।

84
401 प्रमाणीकरण त्रुटि है, 403 प्राधिकरण त्रुटि है। इतना ही आसान।
शाहरियार इमानोव

30
आपने अपने ब्लॉग पोस्ट से कॉपी करते समय "वैसे भी उस पर मेरा नज़रिया :)" छोड़ दिया है और दुर्भाग्य से उनका दृष्टिकोण गलत है। जैसा कि अन्य लोगों ने कहा है कि 403 का मतलब है कि आप संसाधन की पहुँच नहीं बना सकते हैं, भले ही आप इसके रूप में प्रमाणित हों। मैं आमतौर पर इस स्थिति कोड का उपयोग उन संसाधनों के लिए करता हूं जो कि मेरे वेबरोट में आईपी एड्रेस रेंज या फाइलों द्वारा लॉक किए जाते हैं जिन्हें मैं सीधे एक्सेस नहीं देना चाहता (यानी एक स्क्रिप्ट को उनकी सेवा करनी चाहिए)।
काइल

402

देखें RFC2616 :

अनधिकृत 401:

यदि अनुरोध में पहले से ही प्राधिकरण क्रेडेंशियल शामिल हैं, तो 401 प्रतिक्रिया इंगित करती है कि प्रमाणीकरण उन क्रेडेंशियल्स के लिए मना कर दिया गया है।

403 निषिद्ध:

सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है।

अपडेट करें

आपके उपयोग के मामले से, ऐसा प्रतीत होता है कि उपयोगकर्ता प्रमाणित नहीं है। मैं 401 वापस करूंगा।


संपादित करें: RFC2616 अप्रचलित है, RFC7231 और RFC7235 देखें ।


21
धन्यवाद, यह मेरे लिए यह स्पष्ट करने में मदद की। मैं दोनों का उपयोग कर रहा हूं - अनधिकृत उपयोगकर्ताओं के लिए 401, अपर्याप्त अनुमति वाले प्रमाणित उपयोगकर्ताओं के लिए 403।
वर्चुओसीमीडिया जूल

52
मैं निराश नहीं हुआ, लेकिन मुझे यह जवाब काफी भ्रामक लगता है। 403 निषिद्ध सामग्री का अधिक उचित रूप से उपयोग किया जाता है जिसे कभी भी नहीं परोसा जाएगा (जैसे asp.net में .config फाइलें)। इसके या तो 404. imho, किसी चीज के लिए 403 वापस करना उचित नहीं होगा जिसे एक्सेस किया जा सकता है लेकिन आपके पास सही क्रेडेंशियल्स नहीं हैं। मेरा समाधान क्रेडेंशियल्स को बदलने के तरीके के साथ एक एक्सेस अस्वीकृत संदेश देना होगा। वह या एक 401.
मेल

27
"प्रतिक्रिया के लिए अनुरोध किए गए संसाधन पर लागू एक डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर फ़ील्ड (अनुभाग 14.47) एक चुनौती से युक्त होता है।" ऐसा लगता है कि यदि आप HTTP- शैली प्रमाणीकरण का उपयोग नहीं करना चाहते हैं, तो 401 प्रतिक्रिया कोड उपयुक्त नहीं है।
ब्रिलिएंड

8
मैं यहाँ पर Billiand वापस आऊँगा। बयान है "यदि अनुरोध में पहले से ही प्राधिकरण क्रेडेंशियल शामिल हैं"। इसका मतलब है कि अगर यह एक अनुरोध से प्रतिक्रिया है जो क्रेडेंशियल प्रदान करता है (उदाहरण के लिए एक RFC2617 प्रमाणीकरण प्रयास से प्रतिक्रिया)। यह अनिवार्य रूप से सर्वर को यह कहने की अनुमति देता है, "खराब खाता / पासवर्ड जोड़ी, फिर से प्रयास करें"। प्रस्तुत प्रश्न में, उपयोगकर्ता संभवतः प्रमाणित है लेकिन अधिकृत नहीं है। 401 उन परिस्थितियों के लिए उपयुक्त प्रतिक्रिया नहीं है।
ldrut

6
Brilliand सही है, 401 केवल HTTP प्रमाणीकरण के लिए उपयुक्त है।
जुमपी

296

कुछ अन्य उत्तर गायब हैं, यह समझना चाहिए कि RFC 2616 के संदर्भ में प्रमाणीकरण और प्राधिकरण केवल RFC 2617 के HTTP प्रमाणीकरण प्रोटोकॉल को संदर्भित करता है। RFC2617 के बाहर की योजनाओं द्वारा प्रमाणीकरण HTTP स्थिति कोड में समर्थित नहीं है और नहीं माना जाता है। यह तय करते समय कि 401 या 403 का उपयोग करना है या नहीं।

संक्षिप्त और संक्षिप्त

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

मतलब अगर आपके पास अपना स्वयं का रोल-इन लॉगिन प्रक्रिया है और कभी HTTP प्रमाणीकरण का उपयोग नहीं करते हैं, तो 403 हमेशा उचित प्रतिक्रिया होती है और 401 का उपयोग कभी नहीं किया जाना चाहिए।

विस्तृत और गहराई में

RFC2616 से

10.4.2 401 अनधिकृत

अनुरोध को उपयोगकर्ता प्रमाणीकरण की आवश्यकता है। अनुरोधित संसाधन पर लागू चुनौती के साथ प्रतिक्रिया के लिए डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर फ़ील्ड (सेक्शन 14.47) शामिल होना चाहिए। क्लाइंट MAY एक उपयुक्त प्राधिकरण शीर्ष लेख क्षेत्र (खंड 14.8) के साथ अनुरोध को दोहराता है।

तथा

10.4.4 403 निषिद्ध सर्वर अनुरोध को समझ गया लेकिन इसे पूरा करने से इनकार कर रहा है। प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए।

ध्यान रखने वाली पहली बात यह है कि इस दस्तावेज़ के संदर्भ में "प्रमाणीकरण" और "प्राधिकरण" विशेष रूप से RFC 2617 से HTTP प्रमाणीकरण प्रोटोकॉल का संदर्भ देते हैं। वे आपके द्वारा बनाए जा सकने वाले किसी भी रोल-अपने प्रमाणीकरण प्रोटोकॉल का संदर्भ नहीं देते हैं लॉगिन पेज आदि का उपयोग करते हुए, मैं RFC2617 के अलावा अन्य तरीकों से प्रमाणीकरण और प्राधिकरण का उल्लेख करने के लिए "लॉगिन" का उपयोग करूंगा

तो असली अंतर यह नहीं है कि समस्या क्या है या भले ही कोई समाधान हो। अंतर यह है कि सर्वर ग्राहक से आगे क्या करने की उम्मीद करता है।

401 इंगित करता है कि संसाधन प्रदान नहीं किया जा सकता है, लेकिन सर्वर अनुरोध कर रहा है कि क्लाइंट HTTP प्रमाणीकरण के माध्यम से लॉग इन करे और प्रक्रिया शुरू करने के लिए उत्तर हेडर भेजे। संभवतः ऐसे प्राधिकरण हैं जो संसाधन तक पहुंच की अनुमति देंगे, संभवतः वहां नहीं हैं, लेकिन चलो इसे आज़माएं और देखें कि क्या होता है।

403 इंगित करता है कि संसाधन प्रदान नहीं किया जा सकता है और वर्तमान उपयोगकर्ता के लिए, RFC2617 के माध्यम से इसे हल करने का कोई तरीका नहीं है और कोशिश करने का कोई मतलब नहीं है। ऐसा इसलिए हो सकता है क्योंकि यह ज्ञात है कि प्रमाणीकरण का कोई स्तर पर्याप्त नहीं है (उदाहरण के लिए एक आईपी ब्लैकलिस्ट के कारण), लेकिन यह इसलिए हो सकता है क्योंकि उपयोगकर्ता पहले से ही प्रमाणित है और उसके पास अधिकार नहीं है। RFC2617 मॉडल एक-उपयोगकर्ता, एक-क्रेडेंशियल है इसलिए ऐसा मामला जहां उपयोगकर्ता के पास क्रेडेंशियल्स का दूसरा सेट हो सकता है जिसे अधिकृत किया जा सकता है। यह न तो सुझाव देता है और न ही यह बताता है कि कुछ प्रकार के लॉगिन पृष्ठ या अन्य गैर- RFC2617 प्रमाणीकरण प्रोटोकॉल मदद कर सकते हैं या नहीं - जो RFC2616 मानकों और परिभाषा के बाहर है।


संपादित करें: RFC2616 अप्रचलित है, RFC7231 और RFC7235 देखें ।


7
ऐसे में हमें क्या करना चाहिए जब उपयोगकर्ता एक पृष्ठ का अनुरोध करता है जिसे गैर-http प्रमाणीकरण की आवश्यकता होती है? स्थिति कोड 403 भेजें?
marcovtwout

2
यह वह उत्तर है जिसने भेद पर मेरे सवालों का जवाब दिया।
पैट्रिक

9
यह महत्वपूर्ण है: "यदि आपके पास अपनी स्वयं की रोल-इन लॉगिन प्रक्रिया है और कभी HTTP प्रमाणीकरण का उपयोग नहीं करते हैं, तो 403 हमेशा उचित प्रतिक्रिया होती है और 401 का उपयोग कभी नहीं किया जाना चाहिए।"
ggg

1
@marcovtwout अपने लॉगिन पृष्ठ पर एक 302 भेजें, या एक 403 जिसमें जानकारी है कि लॉग इन कैसे करें?
एलेक्स

4
RFC7235 "रोल-योर-ओन" या वैकल्पिक वैकल्पिक चुनौतियों के लिए प्रदान नहीं करता है? मेरे ऐप का लॉगिन प्रवाह WWW-Authenticateहेडर के रूप में अपनी चुनौती क्यों नहीं पेश कर सकता है ? यहां तक ​​कि अगर कोई ब्राउज़र इसका समर्थन नहीं करता है, तो मेरा रिएक्ट ऐप कर सकता है ...
jchook

127
  + -----------------------
  | परिणाम क्या है? (यदि निजी है तो इसे अक्सर जाँच के बाद देखें)
  + -----------------------
    | |
 नहीं | v यस
    v + -----------------------
   404 | लॉग-इन है? (प्रमाणित, उर्फ ​​सत्र या JWT कुकी है)
   या + -----------------------
   401 | |
   403 NO | | हाँ
   3xx वी.वी.
              401 + -----------------------
       (404 कोई खुलासा नहीं) | परिणाम प्राप्त कर सकते हैं? (अनुमति, अधिकृत, ...)
              या + -----------------------
             रीडायरेक्ट | |
             लॉगिन करने के लिए NO | | हाँ
                               | |
                               vv
                               403 ठीक 200, पुनर्निर्देशित, ...
                      (या 404: कोई खुलासा नहीं)
                      (या 404: संसाधन मौजूद नहीं है अगर निजी)
                      (या 3xx: पुनर्निर्देशन)

इस क्रम में चेक आमतौर पर किए जाते हैं:

  • 404 यदि संसाधन सार्वजनिक है और मौजूद नहीं है या 3xx पुनर्निर्देशन है
  • अन्यथा:
  • 401 अगर लॉग-इन या सत्र समाप्त नहीं हुआ है
  • 403 यदि उपयोगकर्ता के पास संसाधन तक पहुँचने की अनुमति नहीं है (फ़ाइल, json, ...)
  • 404 यदि संसाधन मौजूद नहीं है या कुछ भी प्रकट करने के लिए तैयार नहीं है, या 3xx पुनर्निर्देशन है

UNAUTHORIZED : स्थिति कोड (401) यह दर्शाता है कि अनुरोध को प्रमाणीकरण की आवश्यकता है , आमतौर पर इसका मतलब है कि उपयोगकर्ता को लॉग-इन (सत्र) करने की आवश्यकता है। उपयोगकर्ता / एजेंट सर्वर द्वारा अज्ञात। अन्य क्रेडेंशियल्स के साथ दोहरा सकते हैं। नोट: यह भ्रामक है क्योंकि इसे 'अनधिकृत' के बजाय 'अनअथेंटेड' नाम दिया जाना चाहिए था। सत्र समाप्त होने पर लॉगिन के बाद भी ऐसा हो सकता है। विशेष मामला: संसाधन की उपस्थिति या गैर-उपस्थिति का खुलासा करने से बचने के लिए 404 के बजाय इस्तेमाल किया जा सकता है (क्रेडिट @gingerCodeNinja)

FORBIDDEN : स्थिति कोड (403) यह दर्शाता है कि सर्वर अनुरोध को समझ गया है लेकिन इसे पूरा करने से इनकार कर दिया है। उपयोगकर्ता / एजेंट सर्वर द्वारा जाना जाता है, लेकिन अपर्याप्त प्रमाणिकता है । बार-बार अनुरोध करने से काम नहीं चलेगा, जब तक कि क्रेडेंशियल्स नहीं बदल जाते हैं, जो थोड़े समय के अंतराल में बहुत कम है। विशेष मामला: संसाधन की उपस्थिति या गैर-उपस्थिति का खुलासा करने से बचने के लिए 404 के बजाय इस्तेमाल किया जा सकता है (क्रेडिट @gingerCodeNinja)

नहीं ध्यान दें : स्थिति कोड (404) यह दर्शाता है कि अनुरोधित संसाधन उपलब्ध नहीं है। उपयोगकर्ता / एजेंट ज्ञात है, लेकिन सर्वर संसाधन के बारे में कुछ भी प्रकट नहीं करेगा, जैसे कि यह मौजूद नहीं है। दोहराने से काम नहीं चलेगा। यह 404 का एक विशेष उपयोग है (उदाहरण के लिए जीथब ऐसा करता है)।

जैसा कि @ChrisH द्वारा बताया गया है कि पुनर्निर्देशन 3xx (301, 302, 303, 307 या बिल्कुल नहीं पुनर्निर्देशित करने और 401 का उपयोग करने) के लिए कुछ विकल्प हैं :


उदाहरण के लिए मैंने लॉग इन किया है और मैं एक पृष्ठ तक पहुंच सकता हूं लेकिन यह मेरे लिए सक्षम अनुमति नहीं देता है। कौन सा स्टेटस कोड वापस आएगा?
बार्टेलोमा

@bookmarker Loggin को ऑथेंटिकेशन कहा जाता है, जो पहला कदम है। तो अगर आपके पास लॉग इन करने के बाद अनुमति नहीं है, तो आपको 403 निषिद्ध मिल जाएगा (अपर्याप्त क्रेडेंशियल्स का मतलब है कि आपके पास पर्याप्त अनुमति नहीं है)।
क्रिस्टोफ रूसो

3
स्पष्ट, और सरल व्याख्या। बस मैं यह चाहता हूं।
एस्टेवेज

यदि उपयोगकर्ता लॉग इन या लॉग इन नहीं है, लेकिन उसके पास अनुमति नहीं है, और सामग्री स्थान पर मौजूद नहीं है, तो कभी-कभी आप शायद 404 के बजाय 401/403 पर लौटना चाहते हैं, ताकि आप यह उजागर न करें कि क्या है या isn अगर उपयोगकर्ता प्रमाणित नहीं है और लॉग इन नहीं है, तो वहाँ मौजूद है। बस कुछ जानने से कुछ की ओर संकेत मिल सकता है या एनडीए को तोड़ सकते हैं। तो कभी-कभी इस आरेख के 404 भाग को लॉग इन / प्रमाणित के तहत स्थानांतरित किया जाना चाहिए।
जिंजरकोडिनजा

1
@MattKocaj ध्यान दें कि no revealमामले को कभी-कभी सूक्ष्म समय के अंतर के माध्यम से पता लगाया जा सकता है और इसे सुरक्षा सुविधा के रूप में नहीं देखा जाना चाहिए, यह सिर्फ हमलावरों को धीमा कर सकता है या गोपनीयता के साथ थोड़ी मदद कर सकता है।
क्रिस्टोफ रूसो

113

के अनुसार RFC 2616 (HTTP / 1.1) 403 भेजा जाता है जब:

सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है। प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए। यदि अनुरोध विधि HEAD नहीं थी और सर्वर यह सार्वजनिक करना चाहता है कि अनुरोध क्यों पूरा नहीं हुआ है, तो यह इकाई में इनकार के कारण का वर्णन करेगा। यदि सर्वर क्लाइंट को यह जानकारी उपलब्ध नहीं कराना चाहता है, तो इसके बजाय स्थिति कोड 404 (नहीं मिला) का उपयोग किया जा सकता है

दूसरे शब्दों में, यदि ग्राहक प्रमाणीकरण द्वारा संसाधन तक पहुँच प्राप्त कर सकता है, तो 401 को भेजा जाना चाहिए।


5
और अगर यह स्पष्ट नहीं है कि वे पहुंच सकते हैं या नहीं? यह कहें कि मेरे 3 उपयोगकर्ता स्तर हैं - सार्वजनिक, सदस्य और प्रीमियम सदस्य। मान लें कि पृष्ठ केवल प्रीमियम सदस्यों के लिए है। एक सार्वजनिक उपयोगकर्ता मूल रूप से अप्रमाणित है और हो सकता है या तो सदस्य या प्रीमियम सदस्य में हो जब वे लॉग इन करें। उपयोगकर्ता सदस्य स्तर के लिए, एक 403 उचित प्रतीत होता है। प्रीमियम सदस्यों के लिए, 401. हालाँकि, आप जनता की सेवा क्या करते हैं?
पुण्योसोमीडिया

27
imho, यह सबसे सटीक उत्तर है। यह आवेदन पर निर्भर करता है, लेकिन आम तौर पर, अगर एक प्रमाणित उपयोगकर्ता के पास संसाधन पर पर्याप्त अधिकार नहीं है, तो आप क्रेडेंशियल बदलने या 401 भेजने का एक तरीका प्रदान करना चाह सकते हैं। मुझे लगता है कि 403 उस सामग्री के लिए सबसे उपयुक्त है जो कभी नहीं परोसी जाती है। Asp.net में इसका अर्थ web.config files * .resx फाइलें आदि होगा क्योंकि कोई भी उपयोगकर्ता जो लॉग इन नहीं करता है, इन फ़ाइलों को कभी भी सेवा नहीं दी जाएगी, इसलिए फिर से कोशिश करने का कोई मतलब नहीं है।
मेल

6
+1, लेकिन एक अनिश्चित +1। तार्किक निष्कर्ष यह है कि 403 को कभी नहीं लौटाया जाना चाहिए क्योंकि या तो 401 या 404 एक सख्ती से बेहतर प्रतिक्रिया होगी।
कर्टनडॉग

12
@ मुझे लगता है कि एक फ़ाइल जिसे क्लाइंट द्वारा एक्सेस नहीं किया जाना चाहिए, 404 होना चाहिए। यह एक ऐसी फाइल है जो सिस्टम में आंतरिक है; बाहर भी पता नहीं होना चाहिए कि यह मौजूद है। 403 लौटाकर आप ग्राहक को यह बता सकते हैं कि यह मौजूद है, हैकर्स को वह जानकारी दूर देने की कोई आवश्यकता नहीं है। 403 के लिए युक्ति कहती है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).
जुआन मेंडेस

3
जबकि मुझे ऐसा लगता है कि यह संभवतः पुराने RFC 2616 की सटीक व्याख्या है, ध्यान दें कि RFC 7231 एक 403 के शब्दार्थ को अलग तरीके से परिभाषित करता है , और वास्तव में स्पष्ट रूप से कहता है कि "ग्राहक MAY नए या अलग क्रेडेंशियल के साथ अनुरोध को दोहराता है।" इसलिए जबकि यह जवाब 2010 में सटीक था, आज पूरी तरह से गलत है, क्योंकि हमारे पैरों के नीचे स्थिति कोड का अर्थ फिर से लिखा गया है। (अनायास, RFC 2616 परिशिष्ट से परिवर्तन परिवर्तन को स्वीकार नहीं करता है!)
मार्क अमेरी

46

HTTP प्रमाणीकरण ( डब्लूडब्लूडब्लू-ऑथेंटिकेट एंड ऑथोराइज़ेशन हेडर्स) मानकर उपयोग में है , यदि कोई अन्य उपयोगकर्ता प्रमाणित संसाधन के लिए पहुँच प्रदान करेगा, तो 401 अनधिकृत लौटाया जाना चाहिए।

403 निषिद्ध का उपयोग तब किया जाता है जब संसाधन तक पहुंच सभी के लिए वर्जित हो या किसी दिए गए नेटवर्क तक सीमित हो या केवल SSL पर अनुमति दी जाए, जब तक कि यह HTTP प्रमाणीकरण से संबंधित नहीं है।

यदि HTTP प्रमाणीकरण उपयोग में नहीं है और सेवा कुकी आधारित प्रमाणीकरण योजना है जैसा कि आजकल मानक है, तो 403 या 404 वापस किया जाना चाहिए।

401 के संबंध में, यह RFC 7235 (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): ऑथेंटिकेशन) से है:

3.1। अनधिकृत 401

401 (अनधिकृत) स्थिति कोड इंगित करता है कि अनुरोध लागू नहीं किया गया है क्योंकि इसमें लक्ष्य संसाधन के लिए मान्य प्रमाणीकरण क्रेडेंशियल्स का अभाव है। मूल सर्वर एक डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर फ़ील्ड (धारा 4.4) भेजना चाहिए जिसमें कम से कम एक चुनौती होती है जो लक्ष्य संसाधन पर लागू होती है। यदि अनुरोध में प्रमाणीकरण क्रेडेंशियल शामिल हैं, तो 401 प्रतिक्रिया इंगित करती है कि प्रमाणीकरण उन क्रेडेंशियल्स के लिए मना कर दिया गया है। क्लाइंट MAY एक नए या प्रतिस्थापित प्राधिकरण हेडर फ़ील्ड (धारा 4.1) के साथ अनुरोध को दोहराता है। यदि 401 प्रतिक्रिया में पूर्व प्रतिक्रिया के समान चुनौती है, और उपयोगकर्ता एजेंट ने पहले से ही कम से कम एक बार प्रमाणीकरण का प्रयास किया है, तो उपयोगकर्ता एजेंट SHOULD उपयोगकर्ता को संलग्न प्रतिनिधित्व प्रस्तुत करता है, क्योंकि इसमें आमतौर पर प्रासंगिक नैदानिक ​​जानकारी होती है।

403 (और 404) शब्दार्थ समय के साथ बदल गए हैं। यह 1999 (RFC 2616) से है:

10.4.4 403 निषिद्ध

सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है।
प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए।
यदि अनुरोध विधि HEAD नहीं थी और सर्वर यह
सार्वजनिक करना चाहता है कि अनुरोध क्यों पूरा नहीं हुआ है, तो यह इकाई में इनकार के कारण का वर्णन करेगा। यदि सर्वर क्लाइंट को यह जानकारी उपलब्ध नहीं कराना चाहता है, तो
इसके बजाय स्थिति कोड 404 (नहीं मिला) का उपयोग किया जा सकता है।

2014 में RFC 7231 (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): शब्दार्थ और सामग्री) ने 403 का अर्थ बदल दिया:

6.5.3। 403 निषिद्ध

403 (निषिद्ध) स्थिति कोड इंगित करता है कि सर्वर अनुरोध को समझ गया है लेकिन इसे अधिकृत करने से इनकार करता है। एक सर्वर जो सार्वजनिक करना चाहता है कि अनुरोध क्यों मना किया गया है, प्रतिक्रिया पेलोड (यदि कोई हो) में उस कारण का वर्णन कर सकता है।

यदि प्रमाणीकरण क्रेडेंशियल्स अनुरोध में प्रदान किए गए थे, तो
सर्वर उन्हें एक्सेस देने के लिए अपर्याप्त मानता है। ग्राहक
स्वयं उसी
क्रेडेंशियल्स के साथ अनुरोध को दोहराता नहीं है । क्लाइंट MAY नए या अलग क्रेडेंशियल्स के साथ अनुरोध को दोहराता है। हालाँकि,
क्रेडेंशियल्स से असंबंधित कारणों के लिए एक अनुरोध मना किया जा सकता है ।

एक मूल सर्वर जो
निषिद्ध लक्ष्य संसाधन MAY के वर्तमान अस्तित्व को "छिपाना" चाहता है, इसके बजाय एक स्थिति कोड के साथ प्रतिक्रिया करता है
404 (नहीं मिला) ।

इस प्रकार, 403 (या 404) अब किसी भी चीज़ के बारे में हो सकता है। नई साख प्रदान करने में मदद मिल सकती है ... या यह नहीं हो सकता है।

मेरा मानना ​​है कि यह कारण बदल गया है कि RFC 2616 माना जाता है कि HTTP प्रमाणीकरण का उपयोग तब किया जाएगा जब आज के वेब ऐप उदाहरणों और कुकीज़ के लिए कस्टम प्रमाणीकरण योजनाओं का उपयोग करते हैं।


2
यह दिलचस्प है। RFC 7231 और RFC 7235 के आधार पर, मुझे 401 और 403 के बीच स्पष्ट अंतर दिखाई नहीं देता है
ब्रायन

2
403 का अर्थ है "मैं आपको जानता हूं लेकिन आप इस संसाधन को नहीं देख सकते।" भ्रम की कोई वजह नहीं है।
माइकल ब्लैकबर्न

"यदि अनुरोध में प्रमाणीकरण क्रेडेंशियल्स शामिल हैं, तो 401 प्रतिक्रिया इंगित करती है कि उन क्रेडेंशियल्स के लिए प्राधिकरण से इनकार कर दिया गया है। ग्राहक एक नए या प्रतिस्थापित प्राधिकरण हेडर फ़ील्ड (धारा 4.1) के साथ अनुरोध को दोहराता है।" हालांकि, फिर "4.2। 'प्राधिकरण' हेडर फ़ील्ड एक उपयोगकर्ता एजेंट को मूल सर्वर के साथ खुद को प्रमाणित करने की अनुमति देता है"। RFC7235 में ऐसा लगता है कि वे "प्राधिकरण" शब्द का उपयोग करते हैं, जैसे यह "प्रमाणीकरण" था। उस स्थिति में, ऐसा लग सकता है कि एक प्रमाणित लेकिन अधिकृत उपयोगकर्ता को 401 नहीं मिलना चाहिए, बल्कि 403
आर्कुरी 82

28

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

ओडब्ल्यूएएसपी के पास इस बारे में कुछ और जानकारी है कि एक हमलावर इस प्रकार की जानकारी का उपयोग हमले के हिस्से के रूप में कैसे कर सकता है।


3
पिछले उत्तरों में 404 के उपयोग का उल्लेख किया गया है। आप फिर से सूचना पर हैं: सूचना रिसाव और यह किसी के लिए भी एक महत्वपूर्ण विचार होना चाहिए जो अपनी स्वयं की प्रमाणीकरण / प्राधिकरण योजना को रोल कर रहा है। OWASP का उल्लेख करने के लिए +1।
डेव वत्स

विडंबना यह है कि OWASP लिंक अब 404 पेज पर जाता है। मुझे ऐसा ही कुछ मिला (मुझे लगता है) Owasp.org/index.php/…
anned20

सिर के लिए धन्यवाद, मैंने इसे अपडेट किया!
पैट्रिक व्हाइट

एपीआई पर निर्भर करता है और एक्सेस कैसे दिया जाता है। लेकिन "लीक" एक समस्या नहीं है अगर यह उपयोगकर्ता नाम / पासवर्ड के लिए 401 लौटाता है तो यह निश्चित रूप से वेब फॉर्म के लिए समान है?
जेम्स

26
  • 401 अनधिकृत : मुझे नहीं पता कि आप कौन हैं। यह एक प्रमाणीकरण त्रुटि है।
  • 403 निषिद्ध : मुझे पता है कि आप कौन हैं, लेकिन आपके पास इस संसाधन तक पहुंचने की अनुमति नहीं है। यह एक प्राधिकरण त्रुटि है।

यह निश्चित नहीं है कि यह विशेष रूप से "हमेशा" मतलब प्रेषक अज्ञात था। बस उन्होंने जो भी अनुरोध किया था वह अधिकृत नहीं था।
जेम्स

22

यह सवाल कुछ समय पहले पूछा गया था, लेकिन लोगों की सोच आगे बढ़ती है।

इस मसौदे में धारा 6.5.3 (फील्डिंग और रेसके द्वारा लिखी गई) स्थिति कोड 403 को RFC 2616 में दर्ज किए गए दस्तावेज़ से थोड़ा अलग अर्थ देता है ।

यह दर्शाता है कि कई लोकप्रिय वेब-सर्वर और फ्रेमवर्क द्वारा नियोजित प्रमाणीकरण और प्राधिकरण योजनाओं में क्या होता है।

मैंने इस बात पर ज़ोर दिया है कि मुझे लगता है कि सबसे अधिक सामर्थ्य है।

6.5.3। 403 निषिद्ध

403 (निषिद्ध) स्थिति कोड इंगित करता है कि सर्वर अनुरोध को समझ गया है लेकिन इसे अधिकृत करने से इनकार करता है। एक सर्वर जो सार्वजनिक करना चाहता है कि अनुरोध क्यों मना किया गया है, प्रतिक्रिया पेलोड (यदि कोई हो) में उस कारण का वर्णन कर सकता है।

यदि प्रमाणीकरण क्रेडेंशियल्स अनुरोध में प्रदान किए गए थे, तो सर्वर उन्हें एक्सेस देने के लिए अपर्याप्त मानता है। ग्राहक एक ही प्रमाण पत्र के साथ अनुरोध को दोहराना नहीं चाहिए। क्लाइंट MAY नए या अलग क्रेडेंशियल्स के साथ अनुरोध को दोहराता है। हालाँकि, क्रेडेंशियल्स से असंबंधित कारणों के लिए एक अनुरोध मना किया जा सकता है।

एक मूल सर्वर जो निषिद्ध लक्ष्य संसाधन MAY के वर्तमान अस्तित्व को "छिपाना" चाहता है बजाय 404 (नॉट फाउंड) के एक स्टेटस कोड के साथ जवाब देता है।

आप जो भी सम्मेलन का उपयोग करते हैं, महत्वपूर्ण बात यह है कि आपकी साइट / एपीआई में एकरूपता प्रदान करना है।


2
मसौदे को मंजूरी दे दी गई और अब RFC 7231 है।
वेबजॉर्न लोजोसा

13

टी एल; डॉ

  • 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 (नहीं मिला) का उपयोग किया जा सकता है

    (यदि सर्वर क्लाइंट से यह जानकारी रखना चाहता है)


11

वे लॉग इन नहीं हैं या उचित उपयोगकर्ता समूह से संबंधित नहीं हैं

आपने दो अलग-अलग मामलों को कहा है; प्रत्येक मामले में एक अलग प्रतिक्रिया होनी चाहिए:

  1. यदि वे लॉग इन नहीं हैं तो आपको 401 अनधिकृत रूप से लौटाना चाहिए
  2. यदि वे लॉग इन हैं, लेकिन उचित उपयोगकर्ता समूह से संबंधित नहीं हैं, तो आपको 403 निषिद्ध वापस करना चाहिए

इस उत्तर के लिए प्राप्त टिप्पणियों के आधार पर RFC पर ध्यान दें:

यदि उपयोगकर्ता लॉग इन नहीं है तो वे अन-ऑथेंटिकेटेड हैं, HTTP जिसके बराबर 401 है और भ्रामक रूप से RFC में अनधिकृत कहलाता है। 401 अनधिकृत के लिए 10.4.2 राज्यों के खंड के रूप में :

"अनुरोध को उपयोगकर्ता प्रमाणीकरण की आवश्यकता है ।"

यदि आप अनधिकृत हैं, तो 401 सही प्रतिक्रिया है। हालाँकि, यदि आप अनधिकृत हैं, शब्दार्थ सही अर्थ में, 403 सही प्रतिक्रिया है।


5
यह सही नहीं है। RFC और @ Cumbayah के उत्तर का संदर्भ लें ।
डेविड आर।

7
@DavideR। RFC एकांतर रूप से प्रमाणीकरण और प्राधिकरण का उपयोग करता है। मेरा मानना ​​है कि प्रमाणीकरण अर्थ के साथ पढ़ने पर यह अधिक समझ में आता है।
जैद मसूद

यह उत्तर उलटा है। अनधिकृत अन-प्रमाणित के समान नहीं है। @DavideR सही है। प्रमाणीकरण और प्राधिकरण विनिमेय नहीं हैं
BozoJoe

2
2616 को जलाना चाहिए। कई नए RFC बहुत स्पष्ट हैं कि "मैं आपको नहीं जानता" और "मैं आपको जानता हूं, लेकिन आप इसे एक्सेस नहीं कर सकते हैं" के बीच अंतर करने की आवश्यकता है। एक संसाधन के अस्तित्व को स्वीकार करने का कोई वैध कारण नहीं है जो कभी भी पूरा नहीं होगा (या http के माध्यम से पूरा नहीं होता है), जो कि 403-ट्रूथर्स सुझाव दे रहे हैं।
माइकल ब्लैकबर्न

6

ये अर्थ हैं:

401 : उपयोगकर्ता (सही ढंग से) प्रमाणित नहीं, संसाधन / पृष्ठ को प्रमाणीकरण की आवश्यकता होती है

403 : उपयोगकर्ता प्रमाणित है, लेकिन उसकी भूमिका या अनुमतियां अनुरोधित संसाधन तक पहुंचने की अनुमति नहीं देती हैं, उदाहरण के लिए उपयोगकर्ता व्यवस्थापक नहीं है और अनुरोधित पृष्ठ व्यवस्थापकों के लिए है


यह इस सवाल का एक बड़ा TLDR जवाब है।
कूशा

5

यह मेरे सिर में कहीं से भी अधिक सरल है, इसलिए:

401: इसे देखने के लिए आपको HTTP बेसिक कोर की जरूरत है।

403: आप इसे नहीं देख सकते हैं, और HTTP बेसिक कोर मदद नहीं करेगा।

यदि उपयोगकर्ता को आपको साइट के मानक HTML लॉगिन फ़ॉर्म का उपयोग करने के लिए लॉग इन करना है, तो 401 उपयुक्त नहीं होगा क्योंकि यह HTTP बेसिक नॉर्म्स के लिए विशिष्ट है।

मैं 403 जैसी चीजों का उपयोग करने से इनकार करने की सलाह नहीं देता /includes , क्योंकि जहां तक ​​वेब का संबंध है, उन संसाधनों का अस्तित्व ही नहीं है और इसलिए 404 होना चाहिए।

यह 403 को "आपको लॉग इन करने की आवश्यकता है" के रूप में छोड़ता है।

दूसरे शब्दों में, 403 का अर्थ है "इस संसाधन के लिए HTTP बेसिक नॉर्म्स के अलावा किसी अन्य प्रकार के किसी अन्य प्रकार की आवश्यकता है"।

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


5

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

उस तर्क के तहत कुछ मामले यहां दिए गए हैं जहां एक त्रुटि प्रमाणीकरण या प्राधिकरण से लौटा दी जाएगी, जिसमें महत्वपूर्ण वाक्यांश बोल्ड होंगे।

  • एक संसाधन प्रमाणीकरण की आवश्यकता है, लेकिन कोई साख थे निर्दिष्ट

401 : क्लाइंट को क्रेडेंशियल्स निर्दिष्ट करना चाहिए।

  • निर्दिष्ट क्रेडेंशियल अमान्य प्रारूप में हैं

400 : यह न तो 401 और न ही 403 है, क्योंकि सिंटैक्स त्रुटियों को हमेशा 400 वापस करना चाहिए।

  • निर्दिष्ट क्रेडेंशियल्स एक उपयोगकर्ता को संदर्भित करता है जो मौजूद नहीं है

401 : क्लाइंट को मान्य क्रेडेंशियल्स निर्दिष्ट करना चाहिए।

  • निर्दिष्ट क्रेडेंशियल्स हैं अमान्य लेकिन एक मान्य उपयोगकर्ता निर्दिष्ट (या अगर एक निर्दिष्ट उपयोगकर्ता की आवश्यकता नहीं है एक उपयोगकर्ता निर्दिष्ट नहीं करते हैं)।

401 : फिर से, ग्राहक को मान्य क्रेडेंशियल्स निर्दिष्ट करना चाहिए।

  • निर्दिष्ट क्रेडेंशियल्स की समय सीमा समाप्त हो गई है

401 : यह व्यावहारिक रूप से सामान्य रूप से अमान्य क्रेडेंशियल्स के समान है, इसलिए क्लाइंट को मान्य क्रेडेंशियल्स निर्दिष्ट करना चाहिए।

  • निर्दिष्ट क्रेडेंशियल पूरी तरह से मान्य हैं, लेकिन विशेष संसाधन को पर्याप्त नहीं करते हैं , हालांकि यह संभव है कि अधिक अनुमति वाले क्रेडेंशियल्स।

403 : मान्य क्रेडेंशियल निर्दिष्ट करना संसाधन तक पहुंच प्रदान नहीं करेगा, क्योंकि वर्तमान क्रेडेंशियल्स पहले से ही मान्य हैं, लेकिन केवल अनुमति नहीं है।

  • विशेष संसाधन है दुर्गम साख की परवाह किए बिना।

403 : यह क्रेडेंशियल्स की परवाह किए बिना है, इसलिए मान्य क्रेडेंशियल्स को निर्दिष्ट करने से मदद नहीं मिल सकती है।

  • निर्दिष्ट क्रेडेंशियल पूरी तरह से मान्य हैं, लेकिन विशेष क्लाइंट का उपयोग करने से अवरुद्ध है।

403 : यदि ग्राहक अवरुद्ध है, तो नए क्रेडेंशियल्स निर्दिष्ट करने से कुछ नहीं होगा।


3

अंग्रेजी में:

401

आपको संभावित रूप से एक्सेस की अनुमति है लेकिन इस अनुरोध पर किसी कारण से आपको मना कर दिया गया था। जैसे कि खराब पासवर्ड? पुन: प्रयास करें, सही अनुरोध के साथ आपको इसके बजाय सफलता की प्रतिक्रिया मिलेगी।

403

आप कभी भी, अनुमति नहीं हैं। आपका नाम सूची में नहीं है, आप कभी अंदर नहीं जाएंगे, चले जाएं, पुन: प्रयास करने का अनुरोध न भेजें, यह हमेशा इनकार कर दिया जाएगा। चले जाओ।


1

मामले पर नवीनतम RFC ( 7231 और 7235 ) को देखते हुए उपयोग-मामला काफी स्पष्ट है (इटैलिक जोड़ा गया):

  • 401 अनधिकृत के लिए है ("वैध प्रमाणीकरण का अभाव है"); यानी 'मुझे नहीं पता कि तुम कौन हो, या मुझे भरोसा नहीं है कि तुम वो हो जो तुम कहते हो।'

अनधिकृत 401

401 (अनधिकृत) स्थिति कोड इंगित करता है कि अनुरोध लागू नहीं किया गया है क्योंकि इसमें वैध प्रमाणीकरण का अभाव है लक्ष्य संसाधन के लिए क्रेडेंशियल्स । 401 रिस्पांस उत्पन्न करने वाले सर्वर को डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर फ़ील्ड (धारा 4.1) भेजना चाहिए, जिसमें लक्ष्य संसाधन पर कम से कम एक चुनौती होती है।

यदि अनुरोध में प्रमाणीकरण क्रेडेंशियल शामिल हैं, तो 401 प्रतिक्रिया इंगित करती है कि प्रमाणीकरण उन क्रेडेंशियल्स के लिए मना कर दिया गया है। उपयोगकर्ता एजेंट MAY एक नए या प्रतिस्थापित प्राधिकरण हेडर फ़ील्ड (धारा 4.2) के साथ अनुरोध को दोहराता है। यदि 401 प्रतिक्रिया में पूर्व प्रतिक्रिया के समान चुनौती है, और उपयोगकर्ता एजेंट ने पहले से ही कम से कम एक बार प्रमाणीकरण का प्रयास किया है, तो उपयोगकर्ता एजेंट SHOULD उपयोगकर्ता को संलग्न प्रतिनिधित्व प्रस्तुत करता है, क्योंकि इसमें आमतौर पर प्रासंगिक नैदानिक ​​जानकारी होती है।

  • 403 अनधिकृत के लिए है ("अधिकृत करने से इनकार करता है"); यानी 'मुझे पता है कि आप कौन हैं, लेकिन आपके पास इस संसाधन तक पहुंचने की अनुमति नहीं है।'

403 निषिद्ध

403 (निषिद्ध) स्थिति कोड इंगित करता है कि सर्वर अनुरोध को समझ गया है लेकिन अधिकृत करने से इनकार करता है इसे है। एक सर्वर जो सार्वजनिक करना चाहता है कि अनुरोध क्यों मना किया गया है, प्रतिक्रिया पेलोड (यदि कोई हो) में उस कारण का वर्णन कर सकता है।

यदि प्रमाणीकरण क्रेडेंशियल्स अनुरोध में प्रदान किए गए थे, तो सर्वर उन्हें एक्सेस देने के लिए अपर्याप्त मानता है। ग्राहक स्वयं उसी क्रेडेंशियल्स के साथ अनुरोध को दोहराता नहीं है। क्लाइंट MAY नए या अलग क्रेडेंशियल्स के साथ अनुरोध को दोहराता है। हालाँकि, क्रेडेंशियल्स से असंबंधित कारणों के लिए एक अनुरोध मना किया जा सकता है।

एक मूल सर्वर जो निषिद्ध लक्ष्य संसाधन MAY के वर्तमान अस्तित्व को "छिपाना" चाहता है बजाय 404 (नॉट फाउंड) के एक स्टेटस कोड के साथ जवाब देता है।


2
-1; ये मार्ग पहले से ही यहां अन्य उत्तरों में उद्धृत किए गए हैं, और आपका कुछ भी नया नहीं है। मेरा तर्क है कि यह स्पष्ट रूप से स्पष्ट नहीं है कि भेद क्या है; आप दो कोडों को "वैध प्रमाणीकरण की कमी" और "अधिकृत करने से इनकार" के रूप में सारांशित करते हैं, लेकिन मैं किसी भी स्थिति के बारे में कल्पना नहीं कर सकता, जिसमें से एक उन छोटे विवरणों पर लागू होगा जहां दूसरे को भी लागू करने के लिए व्याख्या नहीं की जा सकती है।
मार्क अमेरी

यहाँ कई उत्तर हैं जो कई RFC को कवर करते हैं और संपादित किए जाते हैं और पानी को मैला करते हैं। मैंने यह बताने के लिए एक लिंक शामिल किया कि क्या authenticatedहै और क्या authorizedहै और सभी पुराने RFC को छोड़ दिया है ताकि आवेदन स्पष्ट हो।
cjbarth

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

-6

401 बनाम 403 के मामले में, यह कई बार उत्तर दिया गया है। यह अनिवार्य रूप से एक 'HTTP अनुरोध पर्यावरण' बहस है, न कि 'एप्लिकेशन' बहस।

लगता है कि रोल-योर-ऑन-लॉगिन समस्या (एप्लिकेशन) पर एक प्रश्न है।

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

"मैंने आपको सुना, यह यहाँ है, लेकिन इसके बजाय यह कोशिश करें (आपको इसे देखने की अनुमति नहीं है)"


वास्तव में क्या बनाया जा रहा है?
ग्रांटीकैन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.