2012-02-09 10 views
22

एक प्रमाणीकरण सेवा उपयोगकर्ता खातों को अक्षम करने की अनुमति देती है (सॉफ्ट-डिलीट का एक प्रकार)।HTTP 401 अनधिकृत या 403 "अक्षम" उपयोगकर्ता के लिए निषिद्ध है?

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

त्वरित संदर्भ के लिए, HTTP/1.1 spec (जोर मेरा) से प्रासंगिक उद्धरण:

401 अनधिकृत

अनुरोध उपयोगकर्ता प्रमाणीकरण की आवश्यकता है। प्रतिक्रिया में डब्ल्यूडब्ल्यूडब्लू-प्रमाणीकरण हेडर फ़ील्ड (सेक्शन 14.47) शामिल होना चाहिए जिसमें अनुरोधित संसाधन पर लागू चुनौती शामिल है। क्लाइंट अनुरोध को उपयुक्त प्राधिकरण शीर्षलेख फ़ील्ड (सेक्शन 14.8) के साथ दोहरा सकता है। तो अनुरोध पहले ही प्राधिकरण प्रमाणिकता शामिल, तो 401 प्रतिक्रिया इंगित करता है कि प्राधिकरण उन साख के लिए मना कर दिया गया है। 401 प्रतिक्रिया पूर्व प्रतिक्रिया के रूप में एक ही चुनौती है, और उपयोगकर्ता एजेंट पहले से ही कम से कम एक बार प्रमाणीकरण का प्रयास किया गया है, तो उपयोगकर्ता इकाई है कि प्रतिक्रिया में दिया गया था प्रस्तुत किया जाना चाहिए, क्योंकि ऐसा करना इकाई हो सकता है प्रासंगिक नैदानिक ​​जानकारी शामिल करें। HTTP एक्सेस प्रमाणीकरण "HTTP प्रमाणीकरण: मूल और डाइजेस्ट एक्सेस प्रमाणीकरण" में वर्णित है [43]।

403 निषिद्ध

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

+0

इसी तरह का प्रश्न यहां (यह कुछ हद तक मदद कर सकता है): http://stackoverflow.com/questions/8389253/correct-http-status-code-for-resource-which-requires- प्राधिकरण/ –

उत्तर

30

पर an emailRoy T. Fielding द्वारा लिखित आधार पर, वहाँ जाहिरा तौर पर है वर्तमान HTTP कल्पना में a bug वापसी चाहते हैं।

तरह से कल्पना इरादा है पढ़ने के लिए इस प्रकार है (ईमेल से उद्धरण का उपयोग) है:

401 "अनधिकृत":

यदि आप ऐसा नहीं कर सकते हैं क्योंकि आप

403 प्रमाणीकृत नहीं किया है "अनधिकृत":

उपयोगकर्ता एजेंट मान्य साख भेजा लेकिन एक विकलांग उपयोगकर्ता के मामले में तो पहुँच

, नहीं है, 403 सही जवाब है (और 404 भी एक विकल्प है)।

1

तकनीकी रूप से दोनों सही हैं, यह वास्तव में नीचे आता है कि आप कितना प्रकट करना चाहते हैं।

एक 401 लौटने पर कॉलर को यह कहते हुए कहते हैं कि खाता मान्य नहीं है, जो सही है, लेकिन यदि आपके एपीआई को फिर से उसी क्रेडेंशियल्स वाले उपयोगकर्ता को पंजीकृत करने के लिए बुलाया जा रहा है तो कॉल भी असफल हो जाएगा। जो कॉलर के लिए ज्यादा उपयोग नहीं हो सकता है।

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

9

मुझे इस मामले में वापस आने के लिए दो अलग-अलग उत्तर मिल गए हैं।

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

सुरक्षा विकल्प - 404 नहीं मिला। सूचना रिसाव से बचने के लिए, कई सेवाएं किसी भी विफलता के लिए 404 वापस आ जाएंगी। गितूब तुरंत मेरे दिमाग में आता है।

General API Information से

, GitHub के डेवलपर डॉक्स में:

अनधिकृत अनुरोधों 404 वापस आ जाएगी निजी जानकारी रिसाव की किसी भी प्रकार को रोकने के लिए।

कुछ ऐसा जो मैं सार्वजनिक सेवा के रूप में तैनात कर रहा था, मैं शायद 404 का उपयोग करके अपने क्रेडेंशियल प्रयासों के बारे में हमलावर संकेत देने से बचने के लिए जाऊंगा। यदि यह केवल-आंतरिक खपत के लिए किया गया था, या परीक्षण में, मैं शायद 401

+0

+1, खासकर बनाने के लिए 404 के मामले में, लेकिन मुझे लगता है कि HTTP spec W3 चर्चा और बग के आधार पर टूटा हुआ है। – Dolph

संबंधित मुद्दे