क्या सत्र चर से बचा जाना चाहिए?

36

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

मेरा एक सहयोगी सत्र चर का उपयोग करने से इनकार करता है। क्या यह एक यथार्थवादी लक्ष्य है और सत्र चर को किसी भी व्यावहारिक कारणों से बचा जाना चाहिए? क्या सत्र चर को पूरी तरह से टाला जा सकता है (लॉग कुकीज़ की अनुमति देने के लिए सत्र कुकीज़ को छोड़कर) और क्या इसका परिणाम बेहतर डिजाइन होगा?

मेरे सहकर्मी द्वारा उपयोग न करने के कुछ कारण:

सत्र चर की अनुपलब्ध प्रकृति
राज्य के नुकसान का कारण सत्र समय-आउट
सत्र चर की वैश्विक गुंजाइश प्रकृति
सत्रों को खोने वाले लोड संतुलन सर्वर (.Net विशिष्ट?)
अनुप्रयोग पूल / सर्वर पुनः आरंभ
वे अनावश्यक हैं

web-development design

— Tjaart
स्रोत

3

using things like query string parameters instead- इस एक मामले के साथ, यदि संभव हो तो हमेशा हमेशा क्वेरी स्ट्रिंग पैरामीटर का उपयोग करें। उस प्रकार के पैरामीटर के लिए सत्र का उपयोग करना नाजुक है और जब उपयोगकर्ता कई टैब खोलते हैं तो वे अजीब बग का परिचय दे सकते हैं।

— इज़काता

2

व्यक्तिगत अनुशंसा - अपने सहकर्मी से कोई सलाह न लें क्योंकि वह स्पष्ट रूप से नहीं जानता कि वह किस बारे में बात कर रहा है। सत्र समय समाप्त? क्या उसे पता नहीं है कि सत्र अवधि वेब ऐप द्वारा नियंत्रित होती है?

— ग्रैंडमास्टरबी

2

@GrandmasterB अहम या तो वे नहीं जानते कि वे क्या कर रहे हैं या अपने करियर के दौरान उन बुलेट बिंदुओं में से हर एक के द्वारा जलाया गया है (मैं खुद उनमें से लगभग 4 को मार चुका हूं) और अस्थायी स्थिति से निपटने के लिए अधिक उपयुक्त तरीके जानता हूं।

— एड जेम्स

क्या कोई कृपया सत्र राज्य और कई टैब खोलने के बीच संबंध की व्याख्या कर सकता है? जब आप एक नया टैब खोलते हैं, तो क्या यह या पिछले टैब से स्टेट को समाहित करता है? धन्यवाद।

— रे

41

यदि आपके आवेदन में सत्र चर है, तो स्वयं से यह पूछें:

जब मैं अपने ब्राउज़र के बैक बटन पर क्लिक करता हूं, तो मुझे अपने वैरिएबल का क्या मूल्य चाहिए?

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

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

बैक बटन का व्यवहार सही होना किसी भी तरह से सभी के लिए सही नहीं है, लेकिन यह आपको एक वेब साइट के बारे में सोचने में मदद करता है। सामान्य तौर पर, मुझे सत्र चर के उपयुक्त उपयोग कुछ और दूर के बीच होने लगते हैं।

— टिम
स्रोत

मैं सहमत हूँ। एक बार जब आप कई टैब के साथ वांछित शब्दार्थ के बारे में सोचते हैं तो यह आमतौर पर स्पष्ट हो जाता है यदि सत्र चर या अनुरोध पैरामीटर सही विकल्प हैं।

— कोडइन्चोस

मैंने सत्र चर के साथ इस प्रकार की त्रुटियों को ठीक से देखा है, और खुद को कठिन तरीके से सीखा है।

— तजार्ट

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

— Lawtonfogle

25

HTTP प्रोटोकॉल स्टेटलेस है। सत्र HTTP अनुरोधों के दौरान क्लाइंट स्थिति को संरक्षित करने का एक तरीका है। आप ऐसा करना चुन सकते हैं कि किसी प्लेटफ़ॉर्म के बिल्ट-इन सेशन को हैंडल करना या क्वेरी स्ट्रिंग पैरामीटर के साथ स्वयं करना। किसी भी तरह एक सत्र की कुछ अवधारणा कई कार्यों के लिए आवश्यक है।

आपका सहकर्मी संभवतः एक विशिष्ट कार्यान्वयन को नापसंद करता है, या अपने इच्छित उद्देश्यों के लिए सत्र का उपयोग नहीं कर रहा है। यदि आपको HTTP अनुरोधों पर किसी विशिष्ट क्लाइंट कनेक्शन के बारे में जानकारी बनाए रखने की आवश्यकता है, तो आपको सत्र दृढ़ता के कुछ प्रकार की आवश्यकता है।

निम्नलिखित समस्याएं विशिष्ट हैं:

सत्र चर की अनुपलब्ध प्रकृति

सत्र चर की वैश्विक गुंजाइश प्रकृति

सत्र गंवाने वाले सर्वरों को लोड करना

अनुप्रयोग पूल / सर्वर पुनः आरंभ

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

यह एक और दिलचस्प है:

राज्य के नुकसान का कारण सत्र समय-आउट

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

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

— मैट एस
स्रोत

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

— तजार्ट

क्या आप सत्रों के लिए इच्छित उद्देश्यों के कुछ उदाहरण दे सकते हैं?

— तजार्ट

@ टैजार्ट: मैंने पिछले पैराग्राफ को थोड़ा बढ़ाया है। उम्मीद है की वो मदद करदे।

— मैट एस

14

दूसरों ने बहुत सारे अच्छे अंक बनाए हैं (जो मैं दोहराने से बचूंगा), लेकिन आपके दोस्त की तकनीक का एक पहलू है जिस पर अभी तक चर्चा नहीं हुई है: सुरक्षा ।

यह जानना असंभव है कि आप कोड को देखे बिना किस तरह की कमजोरियां खोलते हैं, लेकिन यहां कुछ चीजें हैं जो मैं अपने सिर के ऊपर से सोच सकता हूं।

सत्र निर्धारण : एक शक्तिशाली हमला जो थोड़ा आसान है यदि आप उपयोगकर्ता को केवल एक लिंक पर क्लिक कर सकते हैं जो पहले से ही URL में आवश्यक जानकारी है (इसके बजाय उपयोगकर्ता को एक ऐसी मशीन का उपयोग करने के लिए प्राप्त करने की कोशिश करनी चाहिए जो इसके कुकीज़ उचित रूप से सेट है)।
SQL इंजेक्शन (या अन्य दुर्भावनापूर्ण इनपुट) : कभी भी उपयोगकर्ता से मिलने वाली किसी चीज़ पर भरोसा न करें। सेशन वैरिएबल का एक फायदा है कि सर्वर को कभी न छोड़ें, इस प्रकार उपयोगकर्ता सीधे उन्हें बदल नहीं सकता है। जबकि आपको सत्र में डालने से पहले डेटा को सैनिटाइज़ करना चाहिए , आप हमेशा उन मूल्यों पर भरोसा कर सकते हैं जो आपके बाद निकलते हैं। यदि सब कुछ क्वेरी स्ट्रिंग के माध्यम से पास किया गया है, तो आपके पास सत्यापन का एक बहुत कुछ है जो आपको यह सुनिश्चित करने के लिए करने की आवश्यकता है कि आप दुर्भावनापूर्ण इनपुट स्वीकार नहीं कर रहे हैं।
गलत इनपुट्स का उपयोग करके डेटा को दूषित करना : SQL इंजेक्शन के समान, आप कितना डेटा आगे-पीछे कर रहे हैं? यह कितना महत्वपूर्ण है? क्या मैं क्वेरी स्ट्रिंग में मान बदलकर आपके ऐप के व्यवहार को बदल सकता हूं? क्या मैं मूल्यों को बदलकर आपके सर्वर पर डेटा को भ्रष्ट कर सकता हूं? यदि मैं सर्वर पर डेटा को दूषित करने का प्रबंधन करता हूं, तो क्या यह अन्य उपयोगकर्ताओं को प्रभावित करेगा? (यदि आपका उत्तर "नहीं" था, तो मेरी प्रतिक्रिया है "क्या आप सुनिश्चित हैं? आपके पास बहुत सी जगहें हैं जिनकी आपको जांच करने की आवश्यकता है")।

ये सभी तब भी हो सकते हैं जब आप सत्र का उपयोग करते हैं, लेकिन वे बहुत आसान हो सकते हैं यदि आपका दोस्त नहीं जानता कि वह क्या कर रहा है।

— riwalk
स्रोत

2

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

एकमात्र बुरी चीज जो मैंने सत्र चर का उपयोग करने में चलायी है, वह है कि आप उन पर नज़र रखने के लिए आप पर बोझ डालते हैं, सुनिश्चित करें कि वे relavent डेटा और उन्हें निपटाने के साथ आबाद हैं।

क्या यह नहीं है कि जब हम किसी भी तरह से प्रोग्रामिंग कर रहे होते हैं तो हम क्या करते हैं?

— मैक
स्रोत

1

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

सत्र चर के साथ काम करते समय आपको बस सेट और अनसेट होने पर नज़र रखने की आवश्यकता होती है, क्योंकि यह एप्लिकेशन के तर्क प्रवाह को निर्धारित करेगा। यह C जैसी भाषा में मेमोरी मैनेजमेंट की तरह है।

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

— primehunter326
स्रोत

2

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

— कोडइन्कॉउंस

मुझे यकीन नहीं है, जो मैंने पोस्ट किया था वह PHP / MySQL में डेटाबेस संचालित वेब ऐप के निर्माण पर अपने स्वयं के सीमित सीमित अनुभव के आधार पर था। ब्राउज़रों में कई टैब आमतौर पर कैसे संभाले जाते हैं (मैं मान रहा हूँ कि आप क्या जिक्र कर रहे हैं)?

— प्राइमहंटर 326

@ Primehunter326 मार्ग पार्म्स या क्वेरी स्ट्रिंग्स या छिपे हुए प्रपत्र फ़ील्ड्स के साथ।

— केसी

0

जैसा कि पहले कहा गया है कि HTTP स्टेटलेस और सेशन वैरिएबल ब्रेक है। HTTP डिजाइन स्टेटलेस होने के कारण संसाधनों के कैशिंग में मदद करता है। उन संसाधनों के लिए जो सार्वजनिक रूप से उपलब्ध हैं।

सत्र चर के बिना वेबसाइट डिजाइन करना संभव है, लेकिन यह कठिन है। सबसे कठिन (IMHO) फैंसी लॉगिन / लॉगआउट है, HTTP प्रमाणीकरण योजनाएं HTML फॉर्म के माध्यम से प्रमाणित करने के लिए आवश्यक उपकरण प्रदान नहीं करती हैं (आप जावास्क्रिप्ट के साथ कुछ हैक कर सकते हैं - XHR से https: // untel: passowrd@mobomain.com ) और लॉगआउट करना और ब्राउज़र संगत पार करना और भी कठिन है। उस बारे में w3 mailling सूचियों पर कुछ चर्चा हुई थी, लेकिन अगर मुझे याद है कि विचार सही ढंग से गिरा था

बाकी के लिए, आपको सत्र चर के बिना रहने में सक्षम होना चाहिए। आपके पास डेटाबेस, फ़ाइलों या कहीं भी कुछ स्थिति होगी लेकिन सत्र चर के लिए उपयोग दुर्लभ होना चाहिए।

यदि आपके उपयोगकर्ता के पास खरीदारी की टोकरी है, तो यह केवल एक चर सत्र है, यदि उपयोगकर्ता को कार्ट को साझा किए बिना दो कंप्यूटर / ब्राउज़र पर ब्राउज़ करने में सक्षम होना चाहिए।

— मैथ्यु
स्रोत