लॉगिन फॉर्म के लिए सही HTTP स्थिति कोड?

Question

मैं एक ऐप के लिए प्रमाणीकरण लागू कर रहा हूं, और मैं "प्रमाणीकरण विधियों" के साथ एक प्लग करने योग्य सिस्टम का उपयोग कर रहा हूं। यह मुझे HTTP बेसिक के साथ ही एचटीएमएल आधारित प्रमाणीकरण दोनों को लागू करने की अनुमति देता है।

HTTP बेसिक/डायजेस्ट ऑथ के साथ सर्वर 401 Unauthorized प्रतिक्रिया शीर्षलेख भेजता है। हालांकि, HTTP/1.1 RFC के अनुसार:

प्रतिक्रिया एक WWW-प्रमाणित शीर्ष लेख क्षेत्र (खंड 14.47) एक चुनौती अनुरोध किया गया संसाधन के लिए लागू युक्त अवश्य शामिल करें।

चूंकि मुझे किसी भी "HTML" WWW- प्रमाणीकरण शीर्षलेख के बारे में पता नहीं है, तो एक HTML लॉगिन फ़ॉर्म के साथ 401 भेजना अनुचित लगता है। क्या इसका कोई विकल्प है? मैं अपने ऐप को एक शानदार तरीके से डिजाइन करना चाहता हूं।

एचटीएमएल-आधारित लॉगिन फॉर्म के लिए सही HTTP स्थिति कोड (और शीर्षलेख) क्या है? और लॉगिन विफल होने पर सही कोड क्या है?

नोट: मुझे डायजेस्ट प्रमाणीकरण में रूचि नहीं है।

Answer 1

एचटीएमएल के लिए मुझे लगता है कि आप एक 400

साथ जवाब देना चाहिए इस रूप में अच्छी तरह गैर- HTML अनुरोधों के लिए सच हो सकता है, के बाद से 401 जहाँ तक मैं इसे और अधिक सामग्री के लिए एक अनुरोध का जवाब करने के लिए डिज़ाइन को समझते हैं कि प्रमाणीकरण अनुरोध की प्रतिक्रिया न देने के लिए प्रमाणीकरण की आवश्यकता है।

एचटीएमएल हमेशा रीस्टफुल एपीआई के शुद्ध उपयोग की अनुमति नहीं देता है, इसलिए यहां और वहां इमोज़ कोनों को काटना ठीक है, लेकिन हो सकता है कि मैं इस विशेष मामले में एक बेहतर तरीका नहीं देख रहा हूं।

Answer 2

यह एक मुश्किल सवाल है, मुख्य रूप से क्योंकि लोगों द्वारा उपयोग किए जाने वाले सबसे अच्छी तरह से स्थापित HTTP क्लाइंट ब्राउज़र हैं। आरएफसी के अनुसार, WWW-Authenticate शीर्षलेख में कुछ भी शामिल हो सकता है। बेसिक और डाइजेस्ट प्रमाणीकरण आगे मानक चुनौती/प्रतिक्रिया तंत्र के केवल दो उदाहरण हैं। आप बस html-form id=foo जैसी चुनौती निर्दिष्ट कर सकते हैं और HTML फॉर्म के साथ 401 वापस कर सकते हैं। साथ ही, इस स्पेस से याद रखें कि कई चुनौतियों को उसी WWW-Authenticate शीर्षलेख में निर्दिष्ट किया जा सकता है, लेकिन मेरे पास अलग-अलग योजनाओं के साथ व्यापक रूप से कोई अनुभव परीक्षण ब्राउज़र नहीं है।

Answer 3

@ 2016/02/17 अपडेट किया गया

login form http स्थिति 200 OK होना चाहिए।

error http स्थिति बेहतर 401 Unauthorized का उपयोग करें। (नाम भ्रमित हो सकता है, 401 प्रमाणीकरण के बारे में है। RFC7235

3,1। 401 अनधिकृत

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

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

आप अगर कोई अनुमति ठीक है, आप की आवश्यकता हो सकती 403 Forbidden [RFC7231] को संभालने के लिए

HTTP 422 WebDAV के लिए प्रयोग किया जाता है, लेकिन अर्थ आवश्यकताओं के अनुरूप कर सकते हैं चाहते हैं। (ज्यादातर मामलों के लिए सुझाव नहीं दिया गया)

अधिक जानकारी के लिए, कृपया नीचे Cássio Mazzochi Molin की टिप्पणी देखें।

---

@ 2016/02/12 अपडेट किया गया(यह स्वीकार किए जाते हैं जवाब देने के लिए संदर्भ है।)

login form http स्थिति 200 होना चाहिए।

error http स्थिति बेहतर 400 का उपयोग करें।

HTTP 422 वेबडावी के लिए उपयोग किया जाता है, लेकिन इसका अर्थ ज़रूरतों को पूरा कर सकता है। HTTP 401 प्रमाणीकरण के लिए है। और प्रमाणीकरण के लिए उपयुक्त नहीं है।

---

मूल @ 2016-02-12

HTTP 422 अब से बेहतर 400/401 HTTP अन्य विकल्प 422 एक वैकल्पिक पसंद है।

क्योंकि इसका मतलब है कि सर्वर डेटा को समझता है लेकिन डेटा के हिस्से के लिए सही नहीं है। यानी यह क्लाइंट दिखा सकता है कि उपयोगकर्ता नाम/पासवर्ड गलत है।

11.2। 422 संसाधन अयोग्य इकाई

422 (संसाधन अयोग्य इकाई) स्थिति कोड का अर्थ सर्वर अनुरोध इकाई (इसलिए एक 415 (असमर्थित मीडिया प्रकार) स्थिति कोड अनुचित है) की सामग्री प्रकार समझता है, और अनुरोध के वाक्य रचना इकाई सही है (इस प्रकार एक 400 (खराब अनुरोध) स्थिति कोड अनुचित है) लेकिन निहित निर्देशों को संसाधित करने में असमर्थ था। उदाहरण के लिए, यह त्रुटि स्थिति तब हो सकती है जब कोई XML अनुरोध निकाय अच्छी तरह से गठित होता है (यानी, वाक्य रचनात्मक रूप से सही), लेकिन अर्थात् ग़लत, एक्सएमएल निर्देश।

RFC4918

Answer 4

इस एक के बारे में

क्या?

जब लॉगिन रूप है जो एक सार्वजनिक पृष्ठ है का अनुरोध, आप क्या चाहते हैं, तो यह 200 स्थिति कोड है:

GET /login -> 200 

जब एक पृष्ठ है कि एक http स्तर प्रमाणीकरण है कि आप नहीं था 'की जरूरत के लिए अनुरोध टी शुरू की (बुनियादी http, SSL प्रमाणपत्र, आदि), आवेदन ब्राउज़र में ही बताना होगा यह आप के लिए यह प्रमाणीकरण आरंभ करने की आवश्यकता है:

GET /secured -> 401 with WWW-Authenticate header 

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

प्रवेश करें:

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML login form, displaying errors 

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 302 (temporary redirection to /secured) 
GET /secured -> 200 

:

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML page saying "I know you are John, but you can't get this page" 

अच्छा साख और पर्याप्त अनुमति के साथ में प्रवेश करें: अच्छी साख नहीं बल्कि पर्याप्त अनुमति के साथ में

प्रवेश करें