2009-02-13 16 views
151

अस्वीकरण: मैं विचार के आरईएसटी स्कूल में नया हूं, और मैं इसके चारों ओर अपने दिमाग को लपेटने की कोशिश कर रहा हूं।क्या आप इसे समझने में मेरी मदद कर सकते हैं? "सामान्य आरईएसटी गलतियों: सत्र अप्रासंगिक हैं"

तो, मैं इस पृष्ठ को पढ़ रहा हूं, Common REST Mistakes, और मैंने पाया है कि मैं सत्रों पर अप्रासंगिक होने के अनुभाग से पूरी तरह से परेशान हूं। पृष्ठ यही कहता है:

क्लाइंट "लॉगिन" या "कनेक्शन प्रारंभ करने" के लिए कोई आवश्यकता नहीं होनी चाहिए। HTTP प्रमाणीकरण स्वचालित रूप से प्रत्येक संदेश पर किया जाता है। ग्राहक एप्लिकेशन संसाधनों के उपभोक्ता हैं, सेवाओं नहीं। इसलिए में लॉग इन करने के लिए कुछ भी नहीं है! आइए कहें कि आप REST वेब सेवा पर उड़ान बुकिंग कर रहे हैं। आप सेवा के लिए नया "सत्र" कनेक्शन नहीं बनाते हैं। इसके बजाय आप एक नया यात्रा कार्यक्रम बनाने के लिए "यात्रा कार्यक्रम निर्माता ऑब्जेक्ट" से पूछें। आप रिक्त स्थान भरना शुरू कर सकते हैं लेकिन फिर कुछ अन्य रिक्त स्थान भरने के लिए वेब पर कहीं और विभिन्न घटक प्राप्त करें। कोई सत्र नहीं है इसलिए क्लाइंट के बीच सत्र स्थिति माइग्रेट करने की समस्या नहीं है। सर्वर में "सत्र संबंध" के अंक भी नहीं हैं (हालांकि अभी भी जारी रखने के लिए बाध्यकारी समस्याएं हैं)।

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

क्या /session कहें, आरईएसटी सेवा होने के लिए बुरा होगा, जो अनुरोध के हिस्से के रूप में उपयोगकर्ता नाम/पासवर्ड में पास होगा, और प्रमाणीकरण सफल होने पर सत्र टोकन देता है , जिसे बाद के अनुरोधों के साथ पारित किया जा सकता है? क्या यह एक आरईएसटी दृष्टिकोण से समझ में आता है, या क्या यह बिंदु गुम है?

उत्तर

76

रीस्टफुल होने के लिए, प्रत्येक HTTP अनुरोध को अपने प्राप्तकर्ता के लिए HTTP की स्टेटलेस प्रकृति के साथ पूर्ण सद्भाव में प्रक्रिया करने के लिए पर्याप्त जानकारी लेनी चाहिए।

ठीक है, मुझे लगता है कि HTTP प्रमाणीकरण हर संदेश पर स्वचालित रूप से किया जाता है मिलता है - लेकिन कैसे?

हां, उपयोगकर्ता नाम और पासवर्ड प्रत्येक अनुरोध के साथ भेजा जाता है। ऐसा करने के लिए सामान्य तरीके मूल पहुंच प्रमाणीकरण और डायजेस्ट एक्सेस प्रमाणीकरण हैं। और हां, एक गुप्तचर उपयोगकर्ता के प्रमाण-पत्रों को कैप्चर कर सकता है। इस प्रकार ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) का उपयोग करके भेजे गए और प्राप्त किए गए सभी डेटा एन्क्रिप्ट करेंगे।

यह एक बाकी सेवा, कहते हैं,/सत्र, कि एक GET अनुरोध है, जहां आप अनुरोध के भाग के रूप में एक उपयोगकर्ता नाम/पासवर्ड में दे देते हैं स्वीकार करता है करने के लिए बुरा होगा, और एक रिटर्न सत्र टोकन अगर प्रमाणीकरण सफल रहा था, है कि तब बाद अनुरोधों के साथ पारित किया जा सकता है? क्या यह रीसेट बिंदु से समझ बनाता है, या है जो इस बिंदु को याद कर रहा है?

यह RESTful बाद से यह राज्य में किया जाता है, लेकिन यह फिर भी काफी आम है, क्योंकि यह उपयोगकर्ताओं के लिए एक सुविधा है नहीं होगा, एक उपयोगकर्ता को हर बार लॉगिन करने की ज़रूरत नहीं है।

"सत्र टोकन" में आप जो वर्णन करते हैं उसे आमतौर पर लॉगिन कुकी के रूप में जाना जाता है। उदाहरण के लिए, यदि आप अपने याहू में लॉगिन करने का प्रयास करते हैं! खाते में एक चेकबॉक्स है जो कहता है "मुझे 2 सप्ताह तक लॉग इन रखें"। यह अनिवार्य रूप से कह रहा है (आपके शब्दों में) "यदि मैं सफलतापूर्वक लॉगिन करता हूं तो" मेरे सत्र टोकन को 2 सप्ताह तक जीवित रखें। " वेब ब्राउज़र आपके द्वारा किए जाने वाले प्रत्येक HTTP अनुरोध के साथ ऐसी लॉगिन कुकीज़ (और संभवतः अन्य) भेज देंगे।

+5

यह उत्तर मुझे कोई समझ नहीं आता है। सबसे पहले, यह कहता है कि हर बार लॉगिन और पासवर्ड पास करना ठीक है और इस तरह एक बार भी, जो समझ में आता है। फिर, ग्राहक को वापस जाने का विचार टोकन के रूप में सफल लॉगिन स्थिति का सुझाव दिया जाता है। यदि आवश्यक हो, तो टोकन सृजन के समय को एन्कोड कर सकता है। हमें निश्चित रूप से ग्राहक को जानकारी वापस करने की अनुमति है। तो, यह सुझाव मेरे लिए ठीक लगता है। जवाब कहता है कि यह ठीक नहीं है क्योंकि "यह राज्य करता है," लेकिन "आरईएसटी" में "एसटी" का विचार नहीं है कि राज्य को ग्राहक और सर्वर के बीच स्थानांतरित किया जा सकता है? –

31

प्रत्येक HTTP अनुरोध के लिए प्रमाणीकरण की आवश्यकता के लिए एक आरईएसटी सेवा के लिए असामान्य नहीं है। उदाहरण के लिए, अमेज़ॅन एस 3 की आवश्यकता है कि प्रत्येक अनुरोध में हस्ताक्षर हो जो उपयोगकर्ता प्रमाण-पत्र, निष्पादित करने का सटीक अनुरोध, और वर्तमान समय से लिया गया हो। यह हस्ताक्षर क्लाइंट साइड पर गणना करना आसान है, जिसे सर्वर द्वारा त्वरित रूप से सत्यापित किया जा सकता है, और हमलावर को सीमित उपयोग होता है जो इसे रोकता है (क्योंकि यह वर्तमान समय पर आधारित है)।

+0

मुझे इस दृष्टिकोण से प्यार है। इसे तुरंत इस्तेमाल करना शुरू कर देंगे। –

+3

+1 क्या आप कृपया विस्तार कर सकते हैं: हमलावर को सीमित उपयोग के _is जो इसे रोकता है (क्योंकि यह वर्तमान समय पर आधारित है) _? क्या आप एक कुकी के बारे में बात नहीं कर रहे हैं जिसमें एन्क्रिप्टेड उपयोगकर्ता नाम और पासवर्ड है? जैसे एसओ करता है? (आईएमएचओ) –

+1

@ रॉयनामिर: मैं एक कुकी के बारे में बात नहीं कर रहा हूं। एस 3 द्वारा उपयोग किया गया हस्ताक्षर HTTP अनुरोध के लिए एक पैरामीटर है, लेकिन * कुकी * नहीं है, यह हर अनुरोध के लिए पुन: गणना की जाती है। –

3

मुझे लगता है कि अपने सुझाव ठीक है, आप ग्राहक सत्र जीवन समय को नियंत्रित करना चाहते हैं। मुझे लगता है कि रेस्टस्टाइल आर्किटेक्चर आपको स्टेटलेस एप्लिकेशन विकसित करने के लिए प्रोत्साहित करता है। के रूप में @ 2pence लिखा "प्रत्येक HTTP अनुरोध HTTP का राज्यविहीन प्रकृति के साथ पूर्ण सामंजस्य में होने की यह कार्रवाई करने के लिए अपने प्राप्तकर्ता के लिए अपने आप में पर्याप्त जानकारी करना चाहिए"।

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

5

ठीक है, मुझे लगता है कि HTTP प्रमाणीकरण हर संदेश पर स्वचालित रूप से किया जाता है मिलता है - लेकिन कैसे?

"प्रमाणीकरण:" HTTP शीर्षलेख क्लाइंट द्वारा भेजता है। या तो बुनियादी (सादा पाठ) या पचाना।

यह एक बाकी सेवा, कहते हैं,/सत्र, कि एक GET अनुरोध है, जहां आप अनुरोध के भाग के रूप में एक उपयोगकर्ता नाम/पासवर्ड में दे देते हैं स्वीकार करता है करने के लिए बुरा होगा, और एक रिटर्न सत्र टोकन अगर प्रमाणीकरण सफल रहा था, है कि तब बाद अनुरोधों के साथ पारित किया जा सकता है? क्या यह रीसेट बिंदु से समझ बनाता है, या है जो इस बिंदु को याद कर रहा है?

सत्र के पूरे विचार, सर्वर के पक्ष में राज्य बनाए रखने के द्वारा स्टेटफुल राज्यविहीन प्रोटोकॉल (HTTP) और गूंगा ग्राहक (वेब ​​ब्राउज़र) का उपयोग कर आवेदन पत्र बनाने के लिए है। बाकी सिद्धांतों में से एक "हर संसाधन हाइपरमीडिया लिंक में इस्तेमाल के लिए एक सार्वभौमिक सिंटैक्स का उपयोग विशिष्ट पता है" है। सत्र चर कुछ ऐसा है जिसे यूआरआई के माध्यम से नहीं पहुंचा जा सकता है। वास्तव में विश्वसनीय एप्लिकेशन क्लाइंट के पक्ष में राज्य बनाए रखेगा, HTTP द्वारा सभी आवश्यक चर भेजकर, अधिमानतः यूआरआई में।

उदाहरण: अंकन के साथ खोजें। आप के रूप में यूआरएल होगा

http://server/search/urlencoded-search-terms/page_num 

यह बुकमार्क यूआरएल

+4

प्रमाणीकरण जानकारी यूआरआई के माध्यम से पहुंच योग्य नहीं है, हालांकि - सभी अनुरोध हेडर के हिस्से के रूप में ऑथ जानकारी भेजने के बारे में बात कर रहे हैं। अनुरोध के साथ सत्र टोकन को शामिल करने से अलग कैसे है? मैं यूआरआई में सत्र टोकन का उपयोग नहीं कर रहा हूं, लेकिन अनुरोध में पारित डेटा में। –

+0

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

+4

एक सत्र टोकन भी स्थापित करता है यदि आप उस क्रिया को निष्पादित करने के लिए अधिकृत हैं। इसका क्या मतलब है कि यह इसके परिणाम को प्रभावित नहीं करेगा? यदि कॉलर अधिकृत नहीं है, तो उन्हें अधिकृत प्राधिकृत त्रुटि नहीं मिलती है। एक सत्र टोकन के साथ वही बात। मुझे वास्तव में अंतर नहीं दिख रहा है? –

8

नहीं, यह बात याद आती है नहीं करता है के साथ आम में एक बहुत कुछ है। Google के ClientLogin इस तरह से उल्लेखनीय अपवाद के साथ काम करता है कि क्लाइंट को HTTP 401 प्रतिक्रिया का उपयोग करके "/ सत्र" पर जाने का निर्देश दिया जाता है। लेकिन यह सत्र नहीं बनाता है, यह केवल स्पष्ट रूप से प्रमाण-पत्र पारित किए बिना ग्राहकों को (अस्थायी रूप से) प्रमाणित करने का एक तरीका बनाता है, और सर्वर के लिए इन अस्थायी प्रमाण-पत्रों की वैधता को नियंत्रित करने के लिए उपयुक्त बनाता है।

+0

हालांकि यह अस्थिर प्रतीत नहीं होता है। –

+11

@ unforgiven3 जब तक लौटा टोकन केवल उपयोगकर्ता को प्रमाणीकृत करने के लिए उपयोग किया जाता है और सर्वर द्वारा सर्वर पर संग्रहीत अन्य राज्य को जोड़ने के लिए सर्वर द्वारा उपयोग नहीं किया जाता है, तो मुझे कोई भी वास्तविक बाधाओं का उल्लंघन नहीं होता है। –

+0

@ डेरेल, बाद के HTTP अनुरोध कैसे प्रमाणित किए जा सकते हैं? मेरी समझ प्रमाणीकरण प्रत्येक HTTP अनुरोधों पर होता है। –

10

कई लोग आरईएसटी प्रिंसिपल को बहुत स्पष्ट रूप से नहीं समझते हैं, एक सत्र टोकन का उपयोग करने का मतलब यह नहीं है कि आप हमेशा सतर्क हैं, प्रत्येक अनुरोध के साथ उपयोगकर्ता नाम/पासवर्ड भेजने का कारण केवल प्रमाणीकरण के लिए है और टोकन भेजने के लिए समान है (लॉगिन प्रक्रिया द्वारा उत्पन्न) यह तय करने के लिए कि क्या ग्राहक को डेटा का अनुरोध करने की अनुमति है या नहीं, आप केवल उपयोगकर्ता नाम/पासवर्ड या सत्र टोकन का उपयोग करते समय आरईएसटी रूपांतरणों का उल्लंघन करते हैं, यह तय करने के लिए कि कौन सा डेटा दिखाना है! इसके बजाय आपको केवल उन्हीं के लिए उपयोग करना होगा (डेटा दिखाने के लिए या डेटा दिखाने के लिए नहीं)

आपके मामले में मैं कहता हूं कि यह आरईएसटी है, लेकिन अपने आरईएसटी एपीआई में देशी PHP सत्रों का उपयोग करने से बचने का प्रयास करें और अपना खुद का उत्पादन शुरू करें शेड टोकन जो समय के निर्धारित पेरीओड में समाप्त हो जाते हैं!

+0

धन्यवाद। किसी को देशी PHP सत्र से क्यों बचना चाहिए और इसके बजाय अपने हैश टोकन का उपयोग करना चाहिए? – Matthew

+0

मैं किसी भी शानदार कारण से नहीं कहता हूं, केवल अधिक सुरक्षा और अधिक नियंत्रण के लिए। – EvilThinker

+0

यह स्वीकृत उत्तर से बेहतर है। कम से कम, यह सुझाव को रेस्टी के रूप में स्वीकार करता है, जो समझ में आता है। हालांकि, मुझे नहीं लगता कि पास की गई जानकारी का उपयोग उपयोगकर्ता निर्भर प्राधिकरण के लिए क्यों नहीं किया जा सकता है। कुछ उपयोगकर्ताओं के पास कुछ डेटा तक पहुंच हो सकती है और अन्य नहीं। यह प्रोटोकॉल को गैर-भरोसेमंद नहीं बनाता है। –

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

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