स्टेटलेस सर्वर कैसे काम करते हैं?

Question

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

ऐसा करने के लिए वसंत-सुरक्षा को कैसे कॉन्फ़िगर करें?

Answer 1

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

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

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

तो एचएमएसी में यह कमजोरी है और आपको सावधान रहना चाहिए कि आप इन अनुप्रयोगों का उपयोग किस प्रकार करते हैं। पेपैल के लिए इस योजना का उपयोग करना वास्तव में एक बुरा विचार होगा क्योंकि मुझे बस इतना करना है कि आपकी सुरक्षित कुकी प्राप्त करें और फिर अपने सभी को स्थानांतरित करें मुझे धन बड़ा उछाल यह है कि आपका ऐप वास्तव में स्टेटलेस है।

अंतिम विकल्प एक वितरित हैश में अपने जावा सत्रों को स्टोर करना है। PHP और अन्य प्लेटफार्म डेटाबेस में अपने सत्र डंप करेंगे, गरीब मॅन वितरित कैश, या उन्हें memcache में डंप करेंगे। जावा के साथ आप एक ही काम कर सकते हैं। आप अपने सत्र ऑब्जेक्ट्स को वितरित कैश में भी डाल सकते हैं। यह विकल्प पक्षपात से बाहर हो गया है क्योंकि लोग सोचते हैं "अब मैं शांत हूं कि मैं अपने सत्र में जो चाहूं उसे डंप कर सकता हूं और यह स्टेटलेस होगा।" हालांकि, सभी वितरित कैशों के साथ स्थानांतरण गति, प्रतिकृति समय, और पेलोड आकार पर सीमाएं हैं। यह जावा या Memcache के लिए सच है। अपने सत्रों को छोटा रखें, और यह अच्छी तरह से काम करता है। सत्र में सबकुछ फेंको और आप एक सर्वर के साथ अपने मुद्दों को स्केल करने के लिए वापस जाएं। और वास्तव में यह शायद इससे भी बदतर है कि आपने अभी अपना सर्वर स्टेटफ किया है क्योंकि कभी-कभी ग्रिड कंप्यूटिंग एकल सर्वर से भी बदतर होती है।

अद्यतन:

http://www.manageability.org/blog/stuff/distributed-cache-java

Answer 2

एक राज्यविहीन सेवा एक सेवा है जो आवेदन सर्वर पर किसी भी डाटा स्टोर नहीं करता है: यहाँ जावा वितरित कैशिंग पुस्तकालयों आप ऐसा करने के लिए उपयोग कर सकते की एक सूची है। यह डेटाबेस को डेटा पढ़ता या लिखता है, एक मान (या नहीं) देता है, और उसके बाद, कार्य पर कोई भी जानकारी स्वयं भूल जाती है।

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

ज्यादातर मामलों में, आप दोनों तरीकों से लेनदेन लागू कर सकते हैं, लेकिन यदि आप स्टेटलेस सेवाओं का उपयोग करना चाहते हैं, तो आपके ग्राहक आवेदन को उचित आदेश और कार्यों को पूरा करने का ख्याल रखना होगा, या आपको कुछ अन्य ढूंढना होगा लेनदेन की जानकारी को सही तरीके से स्टोर करने और रोलबैक प्रबंधित करने का तरीका। यह राज्यव्यापी क्लाइंट-साइड होगा, जैसा कि आपने इसे कहा था।

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