क्या वेब सत्र "खराब डिजाइन" है? क्यों?

13

दूसरे दिन मैं एक सहकर्मी के साथ चर्चा कर रहा था और वह यह कहते हुए निकला कि वेब एप्लिकेशन में उपयोगकर्ता के सत्र का उपयोग करना गलत है। मैंने उत्तर दिया कि आपके द्वारा संग्रहीत जानकारी के आधार पर यह गलत हो सकता है, अन्यथा Microsoft द्वारा प्रदान की जा रही एक वेब सत्र सेवा भी क्यों होनी चाहिए (हम ASP.NET के बारे में बात कर रहे थे)।

उसने मुझे जवाब दिया, फिर से, कि एमएस में भी वे आसानी से मुझे जवाब दे सकते हैं कि यह खराब डिजाइन था। और यह कि वह मुझे कुछ श्वेत-पत्र दिखा सकता है।

दुर्भाग्य से मेरे पास अब इस लड़के से संपर्क करने का कोई अवसर नहीं है, लेकिन मैं वास्तव में उसकी बातों के बारे में अधिक समझना चाहूंगा। क्या किसी को यहाँ के बारे में जानकारी / दृष्टिकोण है?

web-applications

— abx78
स्रोत

2

HTTP प्रोटोकॉल मूल रूप से "स्टेटलेस" होने के लिए डिज़ाइन किया गया था - ताकि सभी लेनदेन एकवचन थे, और प्रदान की गई जानकारी के आधार पर। कुछ उपयोगों में सत्र इसके आसपास होने का एक तरीका है। व्यावहारिक रूप से, हालांकि, कई आधुनिक वेबसाइटों के लिए, मैं एक साधारण तरीके के बारे में नहीं सोच सकता हूं जिसे आप सत्रों से बचेंगे; शायद मैं पर्याप्त रचनात्मक नहीं हूं।

— कटान ३१४

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

— इज़काता

2

कुकीज के साथ डेटाबेस स्टोरेज आपके सत्र को डेटाबेस में रखने की बात है।

— एलन शटको

11

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

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

हालांकि, एक बार जब आप रुबिकॉन पार कर लेते हैं, तो बहुत सारे प्रोग्रामर सत्र में न केवल प्रमाणीकरण जानकारी बल्कि कई अन्य चीजों को बचाने के लिए लुभाते हैं। यह एक एंटी-पैटर्न है और आपके वेब एप्लिकेशन को राज्य पर बहुत अधिक निर्भर करता है, जो कि ठीक वही है जो पहली बार में टाला जाना चाहिए था।

कुछ प्रोग्रामर स्प्रिंग (यदि आप जावा का उपयोग कर रहे हैं) जैसी तकनीक पर लगाम कसेंगे तो यह निर्भर करेगा कि क्या निर्भरता में गड़बड़ी होगी, लेकिन मैं तर्क दूंगा कि इससे उन्हें खत्म करने के बजाय निर्भरता पैदा करना आसान हो जाता है। ऐसी प्रौद्योगिकियों को आपके विकास में सहायता करनी चाहिए, न कि आपके विरोधी पैटर्न को किसी समस्या से कम करना चाहिए।

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

— नील
स्रोत

1

but you can't always count on the client being able to save cookiesतब AFAIK, आप या तो सत्रों पर भरोसा नहीं कर सकते। कुकीज़ का उपयोग यह पहचानने के लिए नहीं किया जाता है कि कौन सा सत्र किस उपयोगकर्ता का है, या अन्य तरीके हैं और यह केवल सबसे आम है?

— इज़्काता

प्रत्येक सर्वर / क्लाइंट कनेक्शन के लिए सर्वर पर सामान्य रूप से सत्र की जानकारी को सहेजा जाता है, और यह बड़ी वेब साइटों के लिए एक लोकप्रिय प्रवृत्ति बन गई, जो कुकीज़ सक्षम होने वाले उपयोगकर्ताओं पर भरोसा नहीं कर सकती थी। विकल्प (और / या जेएस लाइब्रेरी) हैं जो क्लाइंट पीसी पर उक्त जानकारी को सहेजने के लिए मजबूर करते हैं (जो कि देर से बहुत लोकप्रिय हो रहा है), लेकिन एचटीएमएल 5 के बिना, कुकीज़ इसे प्राप्त करने का एकमात्र तरीका है। मेरी जानकारी के लिए, ऐसा करने के अन्य तरीके नहीं हैं।

— नील

8

मुझे लगता है कि आप दो अलग-अलग विषयों को भ्रमित कर रहे हैं: 1) सत्र और 2) asp.net वेबफॉर्म के पेज मॉडल

उपयोगकर्ता के प्रमाणीकरण के लिए एक वेब सत्र आवश्यक है । आदर्श रूप से इस उद्देश्य के लिए एक सत्र का उपयोग किया जाना चाहिए। आपको एक सत्र में उपयोगकर्ता डेटा संग्रहीत नहीं करना चाहिए (चाहे वह कुकी में सर्वर पर हो, या जैसा कि asp.net/webforms यह करता है: पृष्ठ के भीतर ही)। किसी को यह नहीं कहना चाहिए कि एक वेब सत्र खराब है, बल्कि उपयोगकर्ता डेटा संग्रहीत कर रहा हैएक सत्र में एक बुरा अभ्यास है। सर्वर पर उपयोगकर्ता डेटा को संग्रहीत न करने के कारणों में वैश्विक चर से बचने के समान कारण शामिल हैं। कुकीज़ या पृष्ठ में उपयोगकर्ता डेटा संग्रहीत करना सुरक्षा समस्याओं को प्रस्तुत कर सकता है। Asp.net के पेज मॉडल का उपयोग करना भी वेब की स्टेटलेस प्रकृति का पालन नहीं करता है। आप यह जानने के लिए एक खोज कर सकते हैं कि वेबफॉर्म एक खराब डिज़ाइन क्यों है। दूसरी ओर सत्र वेब अनुप्रयोगों का एक आवश्यक हिस्सा हैं।

— सांकेतिक शब्दों में बदलनेवाला
स्रोत

"दूसरी ओर सत्र वेब अनुप्रयोगों का एक आवश्यक हिस्सा हैं।" नंबर

— मास्टरएक्सिलो

6

एक पृष्ठ पर नियंत्रण और भंडारण सत्र की स्थिति अनिवार्य रूप से एक हैक है। एमएस का मामला है - एक आवश्यक एक के रूप में वे एक विकास वातावरण प्रदान करने में सक्षम होना चाहते थे जहां आप पृष्ठों को डिजाइन कर सकते थे जैसा कि आप winform के वातावरण में कर सकते हैं।

एमएस खुद एमवीसी आर्किटेक्चर (नवीनतम संस्करण - एमवीसी 4) की ओर बढ़ गया है, जो उस प्रोटोकॉल के प्रति एक वापसी से अधिक है जो वास्तव में होना चाहिए - स्टेटलेस।

ऐसी स्थितियां हैं जहां भंडारण की स्थिति अभी भी आसान है लेकिन यह समझा जाना चाहिए कि यह नियम के बजाय अपवाद है।

— रोबी डी
स्रोत