एक उपयोगकर्ता को आरईएसटी-आधारित वेबसाइट पर लॉग इन कैसे किया जाएगा?

Question

एक साल या उससे पहले मैंने इस सवाल से पूछा: Can you help me understand this? “Common REST Mistakes: Sessions are irrelevant”। मेरा सवाल अनिवार्य रूप से यह था:

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

जवाब मैं प्राप्त एक मोबाइल (iPhone, Android, WP7) अनुप्रयोग के संदर्भ में सही भावना बनाया है। यह मेरे लिए बहुत अच्छा काम किया।

लेकिन अब, मैं बेहतर ढंग से समझना चाहता हूं कि कोई एक आरईएसटी जैसी वेबसाइट कैसे सुरक्षित करेगा, जैसे स्टैक ओवरफ्लो स्वयं या रेडडिट जैसे कुछ। आईफोन ऐप के माध्यम से लॉग इन किए जाने के बजाय वेब ब्राउज़र के माध्यम से लॉग इन करने वाला उपयोगकर्ता क्या काम करेगा?

• उपयोगकर्ता लॉग इन करते समय क्या होता है? क्या किसी भी तरह ब्राउज़र में क्रेडेंशियल सहेजे गए हैं?
• ब्राउज़र को पता होगा कि बाद के आरईएसटी अनुरोधों के साथ कौन से प्रमाण पत्र भेजना है?
• क्या होगा यदि यह एक webservice के लिए एक जावास्क्रिप्ट कॉल है? जावास्क्रिप्ट कॉल में उपयोगकर्ता प्रमाण-पत्र कैसे शामिल होंगे?

मैं काफी स्पष्ट हूं: वेबसाइटों की बात आने पर सुरक्षा की मेरी समझ बहुत सीमित है, मैं एक वेब डेवलपर नहीं हूं (डमनीट जिम, मैं डेस्कटॉप डेवलपर हूं!)। मुझे एक ऐप परिप्रेक्ष्य से आरईएसटी सेवाओं के साथ काम करना अच्छा लगा, लेकिन अब मैं आरईएसटी सिद्धांतों पर आधारित एक वेबसाइट बनाना और बनाना चाहता हूं, और मैं खुद को बहुत खोने के लिए ढूंढ रहा हूं।

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

Answer 1

वास्तविक समस्या यह है कि वेब ब्राउज़र चूसते हैं। ठीक है, तो शायद मैं सिर्फ कड़वा हूँ ;-)।

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

हालांकि, अधिकांश लोग अपने लॉगिन पेज के तरीके पर नियंत्रण चाहते हैं, लेकिन मेरे ज्ञान के लिए यदि आप इस तरह से लॉगिन जानकारी प्राप्त करते हैं तो ब्राउज़र को बताने का कोई तरीका नहीं है, हे, भविष्य में प्रमाणीकरण शीर्षलेख में इन प्रमाण-पत्रों का उपयोग करें अनुरोध।

यह भी अच्छा होगा अगर ब्राउज़र को बताने का कोई तरीका था, हे, आप जिन प्रमाण पत्रों का उपयोग कर रहे हैं, कृपया उन्हें भूल जाएं। इससे आपको प्रभावी रूप से लॉगआउट करने की अनुमति मिल जाएगी।

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

Answer 2

प्रमाणीकृत होने के बाद, उपयोगकर्ता को आमतौर पर "कुकी" (जिसमें एक अद्वितीय सत्र पहचानकर्ता होता है) प्राप्त होता है, जिसे प्रत्येक बाद के अनुरोध पर क्लाइंट से सर्वर पर वापस भेजा जाता है।

http://en.wikipedia.org/wiki/HTTP_cookie

Answer 3

आप Fiddler की तरह एक प्रॉक्सी का उपयोग करते हैं, तो आप देख सकते हैं stackoverflow वास्तव में क्या करता है।

यह/उपयोगकर्ताओं/प्रमाणीकरण /? एस = पर संसाधन से जुड़ता है .... जो हेडर (gauth और usr) में दो "सेट-कुकी" कमांड के साथ प्रतिक्रिया करता है।

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

मुझे लगता है कि स्टैक ओवरफ्लो उन कुकीज़ से कुंजी को देखता है ताकि आप यह सुनिश्चित कर सकें कि आप पहले अधिकृत हैं। जब कुकी समाप्त हो जाती है, तो आपको लॉग आउट माना जाता है।