सत्र - क्या उन्हें हमेशा ज़रूरत होती है?

मैं एक बार फिर उपयोगकर्ताओं को प्रमाणित करने के लिए सत्र का उपयोग करने के विषय को उठाना चाहता हूं। मुझे आपके अनुभव की ऊंचाई से लेख में दी गई विधि की आलोचना सुनने की उम्मीद है।







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

1. सत्र निर्धारण। सत्रों की चोरी से बचाने के लिए, सीसाइड को कुछ सूचनाओं के साथ जोड़ा जाता है
   
   उपयोगकर्ता। आमतौर पर यह IP या UserAgent, या सभी एक साथ होता है।
   
   
   
   आपका सेशन_सेट_सेवे_हैंडलर। चूंकि फ़ाइल सिस्टम में सत्र चर संग्रहित करना इष्टतम समाधान नहीं है,
   
   जितनी जल्दी या बाद में आपको सत्रों को हस्तांतरित करने के बारे में सोचना होगा, आधार, या कहीं और।
   
   
   
   session.use_trans_sid = 0. PHP में निर्मित url_rewriter तंत्र एक असामान्य रूप से शक्तिशाली और उपयोगी है, लेकिन इसके साथ
   
   सत्रों में इसका उपयोग अप्रिय क्षणों की एक श्रृंखला है। उन्मत्त खोज इंजन, बदसूरत लिंक,
   
   एक झूठे नाम के तहत प्रवेश करना, पूरी तरह से बाहरी साइटों (HTTP_REFERER इत्यादि के माध्यम से) आदि के लॉग में अपने sessid को "प्रकाश करना"।
   
   इसलिए, यह फ़ंक्शन आमतौर पर अक्षम होता है, और केवल कुकीज़ को प्रसारण करने के लिए उपयोग किया जाता है।
   
   
   
   
   
   मैं अंतिम बिंदु पर अधिक विस्तार से ध्यान देना चाहता हूं। तथ्य यह है कि अधिकांश बड़ी साइटें
   
   (google, ozon, livejournal, paypal ..) केवल कुकीज़ के माध्यम से काम करते हैं। यह मुझे बहुत अजीब लग रहा था
   
   चूंकि यह संभावना नहीं है कि इंटरनेट पर कुकीज़ के बिना लोग इतने दुर्लभ हैं कि उन्हें उपेक्षित किया जा सकता है।
   
   
   
   लाइवइंटरनेट आंकड़े बताते हैं कि विकलांग लोगों की संख्या लगभग 4% है।
   
   इतना कम नहीं। यह संभावना नहीं है कि ऐसे दिग्गज जानबूझकर दर्शकों के इस हिस्से को काट देंगे, कम से कम
   
   बहुत अच्छे कारण होने चाहिए थे। और वे मिल गए।
   
   
   
   यह पता चला है कि इन 4% में ऐसे लोग शामिल हैं जिनके पास लगातार कुकीज़ नहीं हैं
   
   (एक कठिन जीवनकाल के साथ), लेकिन सत्र वाले काम करते हैं - जीवन भर = 0 के साथ। और सत्र कुकीज़ लगभग सभी के लिए काम करते हैं,
   
   यहां तक ​​कि उन लोगों के लिए भी जिन्होंने सुरक्षा सेटिंग्स में "कुकीज़ अक्षम करें", और यहां तक ​​कि लिंच में भी। :)
   
   
   
   यह स्पष्ट है कि 100% गारंटी वैसे भी नहीं दी जा सकती है। उदाहरण के लिए, कुकीज़ एक फ़ायरवॉल काट सकती हैं (हालांकि फिर से यह ज्ञात नहीं है
   
   क्या यह जीवनकाल के साथ कट जाएगा = 0)। उपयोगकर्ता के पास कुकीज़ के समर्थन के बिना एक स्व-निर्मित ब्राउज़र हो सकता है
   
   (उदा। मोती पर क्रॉलर) लेकिन आप कभी नहीं जानते कि और क्या ...
   
   
   
   लेकिन मेरे स्वयं के अनुभव (और "वरिष्ठ कामरेडों के अनुभव" को अप्रत्यक्ष रूप से इसकी पुष्टि करता है), मैं कहता हूँ कि यह संभव है कि व्यवहार में
   
   यह उम्मीद करना सुरक्षित है कि उपयोगकर्ता के पास सत्र कुकीज़ हैं। और इस थीसिस के पक्ष में भी
   
   डिफ़ॉल्ट रूप से PHP में session.use_only_cookies पैरामीटर 1 पर सेट है, अर्थात कुकीज़ के बिना लोगों के लिए, सत्र काम नहीं करते हैं।
   
   
   
   और चूंकि हम कुकीज़ के समर्थन पर भरोसा कर सकते हैं, ज्यादातर जगहों पर जहां सत्र आमतौर पर उपयोग किए जाते हैं, व्यवहार में, हम कुकीज़ के माध्यम से सब कुछ आसान और अधिक सुविधाजनक कर सकते हैं, और एक ही समय में यह सभी मामलों में काम करेगा,
   
   सत्र के रूप में। मैं आसान क्यों कह रहा हूं? क्योंकि कुकी फेंक दिया - और भूल गया, जब इसे मैन्युअल रूप से निर्धारित करने की आवश्यकता नहीं है
   
   शीर्षलेख (स्थान: ..), आपको अजाक्स के साथ काम करते समय इसके बारे में याद नहीं रखना होगा, यह अनुरोध में मौजूद है, भले ही
   
   क्या यह अनुरोध एक स्क्रिप्ट, स्थिर HTML, छवि या सीएसएस को संदर्भित करता है। सत्र को केवल तभी भुलाया जा सकता है यदि
   
   यदि वे एक ही कुकीज़ के माध्यम से काम करते हैं, और तब भी हमेशा नहीं। :)
   
   
   
   अब हमारे अपने सत्र_सेट_सैव_हैंडलर के बारे में कुछ शब्द। बेशक, यह सब निर्भर करता है कि कौन सा डेटा और कितने समय के लिए है
   
   संग्रहीत करने की आवश्यकता है। सामान्य स्थिति के लिए, निश्चित रूप से, आपको डेटाबेस या फ़ाइल सिस्टम का उपयोग करने की आवश्यकता है। यदि सत्र का जीवनकाल छोटा है,
   
   और सत्र में स्वयं डेटा आसानी से पुनर्प्राप्त करने योग्य है, फिर मेमोरी (या मेमकेड) भी काम करेगी। और अगर सत्र केवल के लिए प्रयोग किया जाता है
   
   उपयोगकर्ता का प्रमाणीकरण, यह विचार करने योग्य है कि क्या यह आम तौर पर आवश्यक है, सिद्धांत रूप में, सर्वर साइड पर कुछ स्टोर करने के लिए।
   
   दरअसल, कुकीज़ का उपयोग करते समय, हम save_handler को पूरी तरह से छोड़ सकते हैं, और क्लाइंट से सभी डेटा को स्टोर कर सकते हैं।
   
   
   
   फिर, phpbb, wordpress, gmail, आदि द्वारा छोड़े गए कुकीज़ का एक सरसरी अध्ययन से पता चला कि यह दृष्टिकोण काफी सामान्य है
   
   इस्तेमाल किया और जीवन का अधिकार है। याद रखने वाली एकमात्र बात यह है कि कुकीज़ को आसानी से पकाया जा सकता है,
   
   और इसलिए आँख बंद करके उन पर भरोसा करें, जो किसी भी मामले में असंभव नहीं।
   
   
   
   और यहाँ हम बिंदु 1 पर आते हैं - सत्र निर्धारण। मानक सत्र तंत्र के साथ के रूप में, अपने
   
   हमें ट्रांसमिशन की संभावना को बाहर करने के लिए उपयोगकर्ता को पहचानने वाली कुछ जानकारी के लिए कुकीज़ को भी बांधना चाहिए
   
   उसका दूसरा। इसके अलावा, हमें उपयोगकर्ता द्वारा कुकी को संभावित परिवर्तनों से बचाना चाहिए।
   
   
   
   सत्रों की तरह, आप सर्वर पर सहेज कर और फिर सामंजस्य स्थापित करके ऐसा कर सकते हैं
   
   आवश्यक जानकारी (समान IP और UserAgent)।
   
   लेकिन हमने सर्वर पर कुछ भी स्टोर नहीं करने का फैसला किया। चलो देखते हैं कि क्या यह सर्वर मेमोरी का उपयोग किए बिना किया जा सकता है।
   
   
   
   प्राधिकरण के एक सामान्य मामले पर विचार करें: जब आप सही उपयोगकर्ता नाम और पासवर्ड दर्ज करते हैं, तो हम उपयोगकर्ता को कुकी में सहेजते हैं
   
   इसकी विशिष्ट पहचानकर्ता (आईडी), और फिर हर बार जब आप सर्वर तक पहुंचते हैं, तो हम इस पहचानकर्ता द्वारा उपयोगकर्ता की पहचान करते हैं
   
   और लॉग इन पर विचार करें। यदि कोई पहचानकर्ता नहीं है, या समय समाप्त हो गया है, तो हम फिर से उपयोगकर्ता से उपयोगकर्ता नाम और पासवर्ड मांगते हैं।
   
   
   
   यहाँ क्या नुकसान हैं:
   
   
   1. उपयोगकर्ता आसानी से कुकी में आईडी बदल सकता है, और हमारे द्वारा किसी अन्य उपयोगकर्ता के रूप में पहचाना जाएगा।
      
      
      
      एक उपयोगकर्ता दूसरे उपयोगकर्ता से कुकी चुरा सकता है और उसे प्रतिरूपित कर सकता है।
      
      
      
      यह स्पष्ट नहीं है कि समय कैसे निर्धारित किया जाए। हम सर्वर पर किसी भी टाइमआउट को स्टोर नहीं करते हैं, इसलिए हम यह नहीं जानते हैं कि क्या है
      
      एक उपयोगकर्ता कल हमारे पास आया था या वह पहले से ही दो महीने के लिए एक ही कुकी के साथ आ रहा है। जब वह हमारे पास लॉग इन करता है तो हमें याद नहीं रहता
      
      विशेष रूप से इस कंप्यूटर से।
      
      
      
      
      
      उपयोगकर्ता को कुकी में डेटा बदलने से रोकने के लिए, हम एक डिजिटल हस्ताक्षर का उपयोग कर सकते हैं। उदाहरण के लिए, md5
      
      कुछ गुप्त शब्द और उपयोगकर्ता आईडी से। या इस उपयोगकर्ता के पासवर्ड से। या पासवर्ड हैश से, अगर पासवर्ड ही हम
      
      डेटाबेस में स्टोर न करें। संक्षेप में, हमें ऐसी जानकारी चाहिए जो उपयोगकर्ता केवल अपने बारे में जानता हो, लेकिन दूसरों के बारे में नहीं जानता हो
      
      जिन उपयोगकर्ताओं के लिए वह स्वयं को बंद करना चाहता है। या बिलकुल नहीं जानते (गुप्त शब्द)
      
      इस प्रकार, हम जो कुकी सेट करते हैं, वह इस तरह दिखाई देगी:
      
      

         $ कुकी = $ उपयोगकर्ता।  '|'  ।  md5 ($ उपयोगकर्ता नाम। 'गुप्त शब्द');
      

      
      
      
      
      उपयोगकर्ता को दूसरे उपयोगकर्ता की कुकी भेजने से रोकने के लिए, हम समान डिजिटल हस्ताक्षर में IP का उपयोग करते हैं और
      
      UserAgent।
      
      

         $ कुकी = $ उपयोगकर्ता।  '|'  ।  md5 ($ उपयोगकर्ता। 'गुप्त शब्द'।   
              $ _SERVER ['REMOTE_ADDR']]
      

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

         $ कुकी = $ उपयोगकर्ता।  '|'  ।  $ समय।  '|'  ।  md5 (
      	 $ उपयोगकर्ता।  $ समय।  'गुप्त शब्द'। 
      	 $ _SERVER ['REMOTE_ADDR']।  $ _SERVER ['HTTP_USER_AGENT']
         )
      

      
      
      
      
      अंत में हमारे पास क्या है: साइट पर उपयोगकर्ताओं को प्रमाणित करने के लिए एक पूरी तरह से विश्वसनीय तंत्र, एक न्यूनतम लोड बनाना
      
      सर्वर के लिए।
      
      
      
      हमारे पास क्या नहीं है: हम बहुत सारे सत्र डेटा संग्रहीत नहीं कर सकते हैं। कुकी का आकार सीमित है, लंबी लाइनों पर md5 खाती है
      
      प्रोसेसर समय, और उपयोगकर्ता के लिए यह कचरा हर बार आगे और पीछे पंप करना बेकार है।
      
      अधिकतम लंबाई शायद gmail की तरह करने लायक है - लगभग 120 बाइट्स। हालाँकि सत्र में वहाँ क्या संग्रहीत किया जा सकता है
      
      "मुझे नहीं पता।" किसी भी मामले में, यदि आपको कई चर स्टोर करने की आवश्यकता है, तो IMHO आपको अभी भी मानक का उपयोग करना चाहिए
      
      PHP सत्र, जो सामान्य मामले के लिए डिज़ाइन किए गए हैं और हमारे साथ अच्छी तरह से उपयोग किए जा सकते हैं, भले ही कम हो
      
      प्रदर्शन।
      
      
      
      हम यह भी नहीं जानते कि इस समय हमारे पास कितने सत्र खुले हैं। आप उन्हें असीमित रूप से खोल सकते हैं।
      
      सिद्धांत रूप में, कुछ भी हमें इस तरह के रिकॉर्ड रखने से रोकता है, लेकिन हम खुद सर्वर को लोड करना चाहते थे ...
      
      
      
      मानक सत्रों का उपयोग करने से बेहतर क्या है, लेकिन आपके save_handler और session_fixation के साथ? तथ्य यह है कि यहाँ सब कुछ सादे दृष्टि से होता है और आप किसी भी स्थान पर हस्तक्षेप कर सकते हैं। कोड की सादगी। खैर, गति - बहुमुखी प्रतिभा के बदले में।