क्या मुझे html आधारित लॉगिन फॉर्म पर http 401 स्थिति कोड वापस करना चाहिए?


11

क्या मुझे html आधारित लॉगिन फॉर्म पर http 401 स्थिति कोड वापस करना चाहिए? पृष्ठ एक समर्पित लॉगिन फ़ॉर्म है, और इसमें कोई अन्य सार्थक सामग्री नहीं है, बस साइट फ्रेमवर्क है। हालाँकि, URL ऐसे पृष्ठ के लिए हो सकता है जिसमें सार्थक सामग्री हो, लेकिन लॉगिन की आवश्यकता हो। ध्यान दें कि यह सेटअप केवल स्थिति कोड 401 लौटाता है, और उपयोगकर्ता को मूल प्रमाणीकरण के लिए संकेत नहीं देता है।

मानकों को देखते हुए ऐसा लगता है कि 401 HTML आधारित लॉगिन रूपों के लिए एक अनुचित स्थिति कोड है। हालाँकि, ऐसा करने के किसी भी दुष्परिणाम का मैंने कभी अनुभव नहीं किया और न ही सुना।

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

आवश्यकता यहां बताई गई है:

http://tools.ietf.org/html/rfc2616#section-10.4.2

यहाँ विस्तृत:

http://tools.ietf.org/html/rfc2617#section-3.2.1

मुझे पता है कि ऐसे तरीके हैं जो मैं खोज इंजन के चारों ओर उन्हें अनुक्रमणिका, या नहीं, पृष्ठों को लॉगिन फ़ॉर्म की उपस्थिति के आधार पर समझाने में काम कर सकता हूं, लेकिन मैं http स्थिति कोड का उपयोग करना पसंद करूंगा, विशेष रूप से 401 क्योंकि यह परिभाषा जैसा लगता है अगर WWW- प्रमाणीकरण हेडर आवश्यकता के लिए सही मैच नहीं है।

क्या कोई कारण है कि मुझे इस मामले में 401 का उपयोग नहीं करना चाहिए? शब्दशः http स्तर पर प्राधिकृत नहीं होने के बीच कोई अंतर है बनाम आवेदन स्तर पर अधिकृत होने के नाते? जाहिर है कि आपके पास दोनों हो सकते हैं, लेकिन http स्तर पर प्रमाणीकरण नहीं है ताकि आवेदन स्तर पर इसे लागू न करने में आसानी हो?

जवाबों:


9

जैसा कि आप ध्यान दें, RFC 2616 के लिए आवश्यक है कि एक RFC 2617 WWW-Authenticate हेडर के साथ 401 रिस्पॉन्स हो । मुझे लगता है कि आप तकनीकी रूप से उस आवश्यकता का अनुपालन कर सकते हैं जैसे बोगस हेडर भेजकर:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

लेकिन मुझे कोई अंदाजा नहीं है कि अगर कोई 401 चुनौतियों का सामना करता है, जिसमें वे कोई चुनौती नहीं समझते हैं, तो ब्राउज़र क्या करेगा। मैं यह मानूंगा कि यदि उनमें से सभी उपयोगकर्ता के लिए अनुरोध निकाय प्रस्तुत नहीं करेंगे (जैसा कि RFC 2616 कहता है कि यदि प्रमाणीकरण विफल रहता है तो उन्हें ऐसा करना चाहिए), लेकिन न तो RFC ऐसा स्पष्ट रूप से कहता है, इसलिए वे वैध रूप से केवल एक सामान्य त्रुटि संदेश दिखा सकते हैं बजाय।

एक संभावित विकल्प (यदि आप केवल 200 की प्रतिक्रिया का उपयोग नहीं करना चाहते हैं जैसा कि बाकी सभी करते हैं) 403 फोर्ब्स स्टेटस कोड का उपयोग करना होगा । यह एक व्यापक रूप से उपयोग किया जाने वाला प्रतिक्रिया कोड है, और जहाँ तक मुझे पता है, लगभग सभी संवादात्मक उपयोगकर्ता एजेंट (अर्थात ब्राउज़र, जैसा कि कहते हैं, खोज इंजन या डाउनलोड प्रबंधक) के विपरीत, उपयोगकर्ता को सामग्री प्रस्तुत करके उस पर प्रतिक्रिया करना चाहिए, कम से कम अगर यह काफी लंबा है

हालाँकि, 403 स्टेटस कोड का वर्णन कहता है कि "[a] यूटोरीकरण से कोई मदद नहीं मिलेगी", इसे IMO को RFC 2617 ऑथेंटिकेशन या इसी तरह के प्रोटोकॉल-लेवल ऑथराइजेशन मैकेनिज्म के संदर्भ में समझा जाना चाहिए; जहां तक ​​ब्राउज़र का सवाल है, इसका कोई मतलब नहीं है कि क्या फॉर्म जमा करना और जवाब में एक कुकी प्राप्त करना "प्राधिकरण" या कुछ और है।

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

किसी भी स्थिति में, यदि आप लॉगिन के बाद प्रमाणीकरण टोकन को संग्रहीत करने के लिए HTTP कुकीज़ का उपयोग कर रहे हैं, तो आपको अनुचित कैशिंग को रोकने के लिए अपनी प्रतिक्रियाओं (प्रमाणीकरण से पहले और बाद दोनों) में एक वैरी हैडर शामिल करना चाहिए Vary: Cookie


2

सबसे पहले, यदि पृष्ठ को लॉगिन की आवश्यकता है, तो आपको शायद इसे robots.txt द्वारा ब्लॉक करना चाहिए

दूसरा, अगर रोबोट पृष्ठ पर नहीं पहुंचते हैं, तो 401 त्रुटि उचित है।


0

शायद, स्थिति कोड गैर-मानव [और कुछ ब्राउज़रों के लिए उपयोगी हो सकते हैं? ]

लॉगिन विधि द्वारा स्वतंत्र रूप से, सही हेडर भेजा जाना चाहिए

उदाहरण के लिए भविष्य में आपको एक रैपर क्लाइंट (वेब ​​ब्राउज़र नहीं) लिखने की आवश्यकता हो सकती है, जो केवल पृष्ठ हेडर का अनुरोध करके खुद को प्रमाणित करेगा, html कोड की समग्रता नहीं।

आप उपयोगकर्ता सूची के समान डेटाबेस का उपयोग करके दोनों तरीकों से अपने लॉगिन आवेदन को लागू कर सकते हैं

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