सत्र को समाप्त करने वाले ग्राहक को बताने के लिए क्या http स्थिति कोड का उपयोग किया जाना चाहिए?

Question

एक वेबपेज में, यह सर्वर के लिए AJAX अनुरोध भेजने के लिए YUI कनेक्शन मैनेजर / डेटासोर्स का उपयोग करता है, यदि सत्र (जिसमें यह जानकारी है कि क्या उपयोगकर्ता प्रमाणित हो चुका है) पहले ही समय से बाहर हो चुका है, तो उन ajax प्रतिक्रियाओं को जिन्हें केवल प्रमाणित किया जा सकता है उपयोगकर्ताओं को एक http स्थिति कोड वापस करना चाहिए, ग्राहक को बता रहा है कि सत्र पहले ही समाप्त हो गया है, फिर ग्राहक या तो उसे लॉगिन पृष्ठ पर पुनर्निर्देशित करता है या उससे पूछता है कि क्या वह सत्र का विस्तार करना चाहता है।

मेरा सवाल यह है कि इस स्थिति में, क्लाइंट को यह बताने के लिए कि क्या सत्र समाप्त हो चुका है, http स्थिति कोड सबसे उपयुक्त है?

विकि से HTTP स्थिति कोडों की सूची

Comments

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

— जेसन

क्यों, 418 बेशक! शॉर्ट और स्टाउट ...

— टिम पोस्ट

वाडिन 410 गॉन का उपयोग करता है, लेकिन चूंकि यह ब्राउज़र द्वारा कैश करने योग्य है, इसलिए मैं इसकी सिफारिश नहीं

— करूंगा

Answer 1

सबसे अच्छा मैं सुझाव दे सकता हूं कि एक डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेट हेडर के साथ HTTP 401 स्थिति कोड है।

403 अनुरोधों के साथ समस्या RFC 2616 है "प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए।" (यानी इससे कोई फर्क नहीं पड़ता कि आप प्रमाणित हैं या नहीं, आप उस संसाधन तक पहुँच पाने वाले नहीं हैं, कभी भी)।

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

मैं RFC 2617 में कोई कारण नहीं देख सकता कि क्यों एक HTTP 401 स्थिति को एक कस्टम WWW-Authenticate हेडर के साथ जोड़ा गया जैसे यह ठीक नहीं होगा:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

OAuth कल्पना वास्तव में, बस यह करने के लिए लगता है के रूप में वे ऐसा करने का सुझाव (वे मेरे मन आरएफसी का एक अजीब व्याख्या करने के लिए है, हालांकि):

WWW-Authenticate: OAuth realm="http://server.example.com/"

यह RFC द्वारा विशेष रूप से घोषित नहीं किया गया है, लेकिन मैं वास्तव में यह नहीं देख सकता कि यह इसके द्वारा मना किया गया है (यह किसी भी प्रकार या जरूरी नहीं है, SHOULD या SHOULD NOT शर्त के साथ संघर्ष नहीं लगता है)।

मैं चाहता हूं कि टाइमआउट के लिए और CSRF टोकन जैसी चीजों के लिए एक अधिक विशिष्ट HTTP स्थिति कोड अमान्य था, इसलिए यह स्पष्ट था।

Answer 2

मैं एक HTTP 401 की सिफारिश करूंगा।

जबकि एक 403 मूल रूप से कहता है, "आपको अनुमति नहीं है, चले जाओ और वापस मत आना", एक 401 कहता है, "हमें नहीं पता कि आपको अनुमति है या नहीं क्योंकि आप अपनी आईडी नहीं लाए हैं।" इसे प्राप्त करें और फिर से प्रयास करें। "

विकिपीडिया की परिभाषाओं की तुलना करें :

HTTP 403 - अनुरोध एक कानूनी अनुरोध था, लेकिन सर्वर इस पर प्रतिक्रिया देने से इनकार कर रहा है।

HTTP 401 - 403 निषिद्ध के समान है, लेकिन विशेष रूप से उपयोग के लिए जब प्रमाणीकरण संभव है, लेकिन विफल रहा है या अभी तक प्रदान नहीं किया गया है।

Comments

401 HTTP प्रमाणीकरण के लिए होना चाहिए । आरएफसी 2616 का कहना है response MUST include a WWW-Authenticate header field। तो उस कोड को बिना WWW-Authenticate हेडर फील्ड में भेजना गलत है ।

— टॉक्सालॉट

Answer 3

419 के बारे में क्या है - यह मानक नहीं है, लेकिन विकिपीडिया पर वर्णन फिट बैठता है:

419 प्रमाणीकरण टाइमआउट

HTTP मानक का हिस्सा नहीं, 419 ऑथेंटिकेशन टाइमआउट दर्शाता है कि पहले वैध प्रमाणीकरण समाप्त हो चुका है। इसका उपयोग 401 अनधिकृत के विकल्प के रूप में किया जाता है ताकि विशिष्ट क्लाइंट संसाधनों तक पहुंच से वंचित होने वाले अन्यथा प्रमाणित ग्राहकों से अंतर किया जा सके।

Comments

कोई भी विचार जहां यह (विकिपीडिया के अलावा) से आता है? यदि यह आधिकारिक RFC में नहीं है, तो इसे किसने परिभाषित किया है?

— anaximander

ऐसा लगता है कि विकी पेज से भी हटा दिया गया है

— सलेम उयरदानी

यह विनिर्देशन का हिस्सा नहीं है, न HttpServletResponseही जावा @ जॉ में उपलब्ध है यदि आप किसी अन्य विश्वसनीय स्रोत को इसके संदर्भ में बेहतर जानते हैं।

— विश्रांत

मुझे प्रतीत होता है कि इसका इस्तेमाल केवल PHP Laravel

— TroySteven

Answer 4

मेरा मानना ​​है कि उपयुक्त कोड 403 / निषिद्ध है। कोई भी ऐसा नहीं है जो सीधे सत्रों से संबंधित हो।

Comments

बिल्कुल यह सही जवाब है। चूंकि सत्र समाप्त हो गया है, इसलिए अनुरोध निषिद्ध है, इसलिए यह सबसे अच्छा विकल्प है।

— marcc

403 ग्राहक को बताता है (मूल रूप से) "ऐसा मत करो जब तक कि आप अपने अनुरोध को संशोधित नहीं करते हैं", लेकिन यदि सत्र स्थापित किया गया था, तो किसी भी संशोधन की आवश्यकता नहीं होगी। इसके अलावा, आप ज्यादातर मामलों में सत्र को फिर से स्थापित करने के लिए (वर्तमान) अनुरोध के लिए कुछ नहीं कर सकते।

— टिम पोस्ट

बिल्कुल सही! 401 बेहतर होगा, मुझे लगता है, लेकिन इसके लिए HTTP प्रमाणीकरण की आवश्यकता है। मुझे लगता है कि यह 401 + 303 (इसलिए, स्पष्ट रूप से, 704) की तर्ज पर एक नई स्थिति के लिए कहता है, जिसका अर्थ है "प्राधिकरण प्राप्त करने के लिए नहीं, अन्य देखें"। इसके अलावा, यह शब्दार्थिक रूप से सही होने के साथ, यह trampoline पुनर्निर्देशन के लिए HTTP समाधान भी हो सकता है, मूल रूप से "यहां जाएं, फिर जब आप वापस आएंगे तो हम फिर से कोशिश करेंगे", ताकि लॉगिन पेज अज्ञेय के संबंध में हो सके गंतव्य।

— एंथनी

मैं इस एक से सहमत नहीं हो सकता, RFC 2616 में स्पष्ट रूप से कहा गया है कि ग्राहक द्वारा 403 प्रतिक्रिया "SHOULD NOT दोहराया जाना चाहिए" के परिणामस्वरूप अनुरोध किया जाता है और यह कि "प्राधिकरण मदद नहीं करेगा"।

— इयान कॉलिन्स

authorization will not help- मुझे लगता है कि HTTP प्रमाणीकरण मदद नहीं करेगा। क्या सही है। एक प्राधिकरण शीर्ष लेख भेजने से कुछ भी नहीं बदलेगा। न तो 401 और न ही 403 आदर्श है, लेकिन मुझे लगता है कि 403 401 से बेहतर है। 401 सत्र सत्र के लिए गलत है क्योंकि आरएफसी 2616 स्पष्ट रूप से बताता है client MAY repeat the request with a suitable Authorization header field। लेकिन, इस मामले में, ग्राहक अनुरोध को दोहराना नहीं चाहिए (कम से कम अंतरिम कदम के बिना नहीं)। दुर्भाग्य से, हम बाद वाले हिस्से को एक स्थिति कोड के साथ संवाद नहीं कर सकते हैं।

— टॉक्सालॉट

Answer 5

सत्य है, सत्र टाइमआउट के लिए कोई मानक HTTP स्थिति कोड नहीं है। एप्लिकेशन को लेयर लेयर में कार्यान्वित किया जाता है, न कि HTTP ट्रांसपोर्ट लेयर पर।

एक कस्टम स्थिति कोड है जिसे Microsoft सत्र टाइमआउट: 599 के लिए उपयोग कर रहा है, या केवल 5xx श्रेणी में अपना स्वयं का स्थिति कोड बनाता है।

स्थिति कोड विकी से:

599 नेटवर्क कनेक्ट टाइमआउट त्रुटि (अज्ञात) यह स्थिति कोड किसी भी RFC में निर्दिष्ट नहीं है, लेकिन इसका उपयोग Microsoft Corp. HTTP प्रॉक्सी द्वारा किया जाता है ताकि नेटवर्क कनेक्ट होने के समय को प्रॉक्सी के सामने क्लाइंट के पीछे टाइमआउट से संकेत दिया जाए।

मैं एक सत्र टाइमआउट के लिए कस्टम स्थिति कोड 599 का उपयोग करता हूं और फिर AJAX प्रतिक्रिया में इसके लिए जांच करता हूं।

Comments

एक नेटवर्क कनेक्शन टाइमआउट एक सत्र टाइमआउट से बहुत अलग है। यदि आप Microsoft एक्सटेंशन के किसी कोड का उपयोग करने जा रहे हैं, तो फैसल440 Login Timeout (Microsoft)

— मैक

उस विकिपीडिया पृष्ठ के बारे में 599 गलत था और कोई उद्धरण नहीं था। यह स्पष्ट रूप से कहता था कि Microsoft प्रॉक्सी नेटवर्क टाइमआउट पर 599 बढ़ाता है, लेकिन मुझे इसका कोई सबूत नहीं मिला।

— गैरेथ डेविडसन

Answer 6

बोबो द्वारा ऊपर दिए गए Http स्थिति कोड के विकिपीडिया लिंक के अनुसार :

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Comments

ध्यान दें कि अपाचे उस वापसी स्थिति को 500 में बदल सकता है, जैसा कि मेरा था - stackoverflow.com/questions/17735514/…

— आम

मुझे ASP.NET वातावरण के लिए यह समाधान पसंद है।

— ट्रायसेवेन

Answer 7

जैसा कि आप एक लिंक पोस्ट करते हैं, उस लिंक में मुझे यह HTTP स्टेटस कोड 440 मिला । आप सत्र समाप्त होने के लिए 440 HTTP स्थिति कोड का उपयोग कर सकते हैं।

440 लॉगिन टाइम-आउट

 The client's session has expired and must log in again.

401 अनधिकृत हम उपयोग कर सकते हैं जब, उपयोगकर्ता लॉगिन क्रेडेंशियल गलत है। या हेडर में उत्तीर्ण ऑर्टिकल टोकन अमान्य है।

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

इसलिए मेरी राय में हमें 440 Login Time-out का उपयोग करना चाहिए ।

Answer 8

तकनीकी रूप से, स्वीकृत उत्तर निश्चित रूप से सही है: यदि आप पहले से ही यह सुनिश्चित करने के लिए जानते हैं कि आप अनुरोध को विफल करने जा रहे हैं, और आप पूछ रहे हैं कि किस विफलता कोड को वापस करना है, तो HTTP 401 "अनधिकृत (अनअथोउंटेड)" उपयुक्त है। ताकि पुन: प्रमाणीकरण का संकेत दिया जा सके।

लेकिन सबसे पहले, खुद से पूछें: क्या आपको अनुरोध को विफल करना चाहिए?

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

मेरी सलाह इस तथ्य को अनदेखा करना है कि सत्र टोकन अज्ञात है, और बस एक नया सत्र टोकन उत्पन्न करने और इसके लिए एक नया सत्र बनाने के लिए आगे बढ़ें। सत्र की प्रारंभिक स्थिति निश्चित रूप से "नहीं-अभी तक-प्रमाणित" होगी, इसलिए यदि उपयोगकर्ता एक गैर-सार्वजनिक पृष्ठ तक पहुंचने का प्रयास कर रहा है, तो पृष्ठ यह देखेगा कि उन्हें एक HTTP 401 प्राप्त हुआ है "अनधिकृत (Unauthenticated) “और प्रमाणित करना होगा। लेकिन अगर उपयोगकर्ता सार्वजनिक पृष्ठ पर लैंड करता है, तो वे कुछ भी अलग नहीं देखेंगे।

Answer 9

मैं एक "स्थान" शीर्षक के साथ 302 पुनर्निर्देशन प्रतिसाद का उपयोग करूंगा, जैसे "संसाधन के लिए आवश्यक है"

क्लाइंट किसी अन्य पृष्ठ पर उपयोगकर्ता को स्थानांतरित करने से बचने के लिए लॉगिन / पासवर्ड फ़ॉर्म के साथ एक मॉडल के लिए संसाधन पथ को रूट कर सकता है।

Answer 10

गैर-अजाक्स अनुरोधों के लिए, मैं 302 रीडायरेक्ट का उपयोग करता हूं।

Ajax अनुरोधों के लिए, मैं ज्ञात त्रुटियों के लिए 200 का उपयोग करता हूं । इस तरह मैं डेटा ऑब्जेक्ट का लाभ उठा सकता हूं। मुझे जानकारी के लिए jqXHR को पार्स करने के साथ डेटा ऑब्जेक्ट को काम करना आसान लगता है। और फिर मुझे इस बारे में चिंता करने की ज़रूरत नहीं है कि मेरी स्थिति के लिए पुन: उद्देश्य के लिए HTTP स्थिति कोड क्या है।

jQuery का उदाहरण:

$.ajax({
    //send data to server
})
.done(function(data, textStatus, jqXHR) {
    if (data.success) {
        //then process return data
    }
    else {
        //get error type or message from data object
        //could use custom error codes
    }
})
.fail(function(jqXHR, textStatus, errorThrown) {
    //handle unknown errors
});

Comments

प्रतिक्रिया को पार्स करने के लिए नहीं चाहते हैं HTTP युक्ति से विचलित करने का एक अच्छा कारण नहीं है, खासकर जब आप सिर्फ JSON.parse (responseText) कर सकते हैं।

— डेविड नेल्सन

मुझे नहीं लगता कि इस मामले में एचटीटीपी युक्ति से 200 रिस्पांस कोड का उपयोग हो रहा है क्योंकि परिवहन स्तर पर यह अनुरोध तकनीकी रूप से सफल था । मेरे लिए, सत्र टाइमआउट त्रुटि बनाने के समान है जहां मैं उपयोगकर्ता के अनुकूल त्रुटि संदेश देता हूं। इस सवाल के जवाबों में व्यक्त असहमति स्पष्ट रूप से दर्शाती है कि HTTP कल्पना सत्र के समय के लिए उद्योग-स्वीकृत प्रतिक्रिया कोड प्रदान नहीं करती है । कोई ऐसे युक्ति से कैसे विचलित हो सकता है जो अस्तित्व में नहीं है?

— टोक्सालॉट

Answer 11

कोड 408. "अनुरोध टाइमआउट", सही लगता है - RFC 2616 इसका अर्थ बताता है

क्लाइंट ने उस समय के भीतर अनुरोध का उत्पादन नहीं किया, जिसके लिए सर्वर प्रतीक्षा करने के लिए तैयार था।

यानी, बिल्कुल "टाइम-आउट", जिस तरह से आपको आवश्यकता है!

Comments

आह, लेकिन बाकी परिभाषा पर एक नज़र डालें: "क्लाइंट किसी भी समय बाद संशोधनों के बिना अनुरोध दोहरा सकता है।" "संशोधनों के बिना" का अर्थ यह होगा कि अनुरोध को पुनः लोड / ताज़ा करके एक नया सत्र बनाया जा सकता है। ज्यादातर मामलों में, जब प्रमाणीकरण का उपयोग किया जा रहा है, तो उपयोगकर्ता को पहले फिर से लॉगिन करना होगा।

— ए जे।

@AJ, निश्चित रूप से दोहराया अनुरोध एक प्रमाणीकरण चुनौती (HTTP कोड 401) में चल सकता है - HTTP स्पेक्स में ऐसा कुछ भी न देखें जो मना हो , क्या आप कुछ भी इंगित कर सकते हैं?

— एलेक्स मार्टेली

408 क्लाइंट को बताता है कि उन्हें बस अनुरोध को फिर से प्रस्तुत करने का प्रयास करना चाहिए, जो स्पष्ट रूप से काम नहीं कर सकता है यदि सत्र समाप्त हो गया है।

— टिम पोस्ट

408 एक 'रिक्वेस्ट' टाइमआउट है, जो सेशन टाइमआउट नहीं है। मतलब, सॉकेट स्थापित किया गया था, लेकिन बहुत लंबा समय ले रहा था। यह साइट इसे समझाने के लिए एक अच्छा काम करती है: checkupdown.com/status/E408.html

— ब्रैड कपिट