🧑🏼‍🤝‍🧑🏼 🕺🏾 🖱️ PHP में सत्र का उपयोग करने के नुकसान 🎤 📖 ⚫️

अभिवादन, विशिष्ट समुदाय।

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

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

सत्र का उपयोग करने का सबसे आम उदाहरण, ज़ाहिर है, उपयोगकर्ता प्राधिकरण है। नए कार्यों के रूप में इसे लगातार विकसित करने के लिए सबसे बुनियादी कार्यान्वयन के साथ शुरू करते हैं।

(उदाहरणों में स्थान और समय बचाने के लिए, हम कक्षाओं के एक सुंदर पदानुक्रम, संपूर्ण त्रुटि से निपटने और अन्य सही चीजों के साथ एक पूर्ण परीक्षण परीक्षा के निर्माण के बजाय सत्र के साथ काम करने के केवल कार्यों तक ही सीमित रहते हैं)।

function startSession() { //     ,     TRUE // ( session.auto_start    php.ini    -   ) if ( session_id() ) return true; else return session_start(); // :   5.3.0  session_start() TRUE    . //      5.3.0,    session_id() //   session_start() } function destroySession() { if ( session_id() ) { //    ,   , setcookie(session_name(), session_id(), time()-60*60*24); //    session_unset(); session_destroy(); } }

नोट: यह समझा जाता है कि पाठक को PHP सत्रों का बुनियादी ज्ञान है, इसलिए हम यहां फ़ंक्शन session_start () और session_destroy () के सिद्धांत को कवर नहीं करेंगे। लॉगिन फ़ॉर्म और उपयोगकर्ता प्रमाणीकरण टाइप करने के कार्य लेख के विषय से संबंधित नहीं हैं, इसलिए हम उन्हें भी छोड़ देंगे। मैं आपको केवल यह याद दिलाता हूं कि प्रत्येक बाद के अनुरोध में उपयोगकर्ता की पहचान करने के लिए, हमें सत्र चर (उदाहरण के लिए उपयोगकर्ता नाम, उदाहरण के साथ) में उपयोगकर्ता पहचानकर्ता को बचाने की आवश्यकता है, जो सत्र के जीवन के बाद के सभी अनुरोधों में उपलब्ध होगा। हमारे प्रारंभ () फ़ंक्शन के परिणाम के प्रसंस्करण को लागू करना भी आवश्यक है। यदि फ़ंक्शन FALSE देता है, तो ब्राउज़र में लॉगिन फ़ॉर्म प्रदर्शित करें। यदि फ़ंक्शन TRUE देता है, और सत्र चर अधिकृत उपयोगकर्ता (हमारे मामले में, उपयोगकर्ता नाम) के पहचानकर्ता में मौजूद है, तो अधिकृत उपयोगकर्ता का पृष्ठ प्रदर्शित करें (त्रुटि से निपटने के बारे में अधिक जानकारी के लिए, 2013 चर पर अनुभाग में 2013-06-07 के अतिरिक्त देखें)।

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

PHP अंतर्निहित उपकरणों के साथ उपयोगकर्ता निष्क्रियता की निगरानी करना

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

 function startSession() { //     ( ) $sessionLifetime = 300; if ( session_id() ) return true; //     ini_set('session.cookie_lifetime', $sessionLifetime); //      ,       // :  production-       php.ini if ( $sessionLifetime ) ini_set('session.gc_maxlifetime', $sessionLifetime); if ( session_start() ) { setcookie(session_name(), session_id(), time()+$sessionLifetime); return true; } else return false; }

थोड़ा स्पष्टीकरण। जैसा कि आप जानते हैं, PHP यह निर्धारित करता है कि ब्राउजर द्वारा रिक्वेस्ट हेडर में भेजे गए कुकी के नाम से कौन सा सेशन शुरू किया जाए। ब्राउज़र, बदले में, इस कुकी को सर्वर से प्राप्त करता है, जहां session_start () फ़ंक्शन इसे रखता है। यदि कुकी ब्राउज़र में समाप्त हो जाती है, तो उसे अनुरोध में प्रेषित नहीं किया जाएगा, जिसका अर्थ है कि PHP यह निर्धारित नहीं कर पाएगी कि किस सत्र को शुरू करने की आवश्यकता है, और इसे नया सत्र बनाने के रूप में माना जाएगा। PHP session.gc_maxlifetime सेटिंग्स पैरामीटर, जो उपयोगकर्ता निष्क्रियता के हमारे समय के बराबर सेट है, PHP सत्र के जीवनकाल को सेट करता है और सर्वर द्वारा नियंत्रित होता है। सत्र आजीवन नियंत्रण निम्नानुसार काम करता है (यहां हम अस्थायी फाइलों में सत्र भंडारण के उदाहरण को सबसे आम मानते हैं और PHP विकल्प में डिफ़ॉल्ट रूप से स्थापित किया गया है)।

PHP सेटिंग्स पैरामीटर सेशन में एक सत्र के लिए एक निर्देशिका के रूप में सेट किए गए निर्देशिका में एक नया सत्र बनाने के समय। session_path, sess_ <sessionid> नाम के साथ एक फ़ाइल बनाई जाती है, जहां <sessionid> सत्र पहचानकर्ता होता है। इसके अलावा, प्रत्येक अनुरोध में, मौजूदा सत्र शुरू करने के समय, PHP इस फ़ाइल के संशोधन समय को अपडेट करता है। इस प्रकार, प्रत्येक बाद के अनुरोध में, PHP, वर्तमान समय और सत्र फ़ाइल के अंतिम संशोधन के समय के अंतर से, यह निर्धारित कर सकता है कि सत्र सक्रिय है या इसका जीवनकाल पहले ही समाप्त हो चुका है। (पुराने सत्र की फ़ाइलों को हटाने के लिए तंत्र अगले खंड में अधिक विस्तार से चर्चा की गई है)।

नोट: यह यहां ध्यान दिया जाना चाहिए कि session.gc_maxlifetime पैरामीटर एक ही सर्वर के भीतर सभी सत्रों को प्रभावित करता है (अधिक सटीक, एक ही मुख्य PHP प्रक्रिया के भीतर)। व्यवहार में, इसका मतलब है कि यदि सर्वर पर कई साइटें चल रही हैं, और उनमें से प्रत्येक के पास उपयोगकर्ता गतिविधि की कमी के लिए अपना समयबाह्य है, तो इस पैरामीटर को किसी एक साइट पर सेट करने से अन्य साइटों के लिए इसकी स्थापना हो जाएगी। साझा होस्टिंग के लिए भी यही होता है। इस स्थिति से बचने के लिए, एक ही सर्वर के भीतर प्रत्येक साइट के लिए अलग-अलग सत्र निर्देशिकाओं का उपयोग किया जाता है। सत्र निर्देशिका का पथ php.ini सेटिंग्स फ़ाइल में या ini_set () फ़ंक्शन को कॉल करके session.save_path पैरामीटर का उपयोग करके सेट किया गया है। इसके बाद, प्रत्येक साइट के सत्रों को अलग-अलग निर्देशिकाओं में संग्रहीत किया जाएगा, और किसी एक साइट पर सेट किया गया session.gc_maxlifetime पैरामीटर उसके सत्र में ही मान्य होगा। हम इस मामले पर विस्तार से विचार नहीं करेंगे, खासकर जब से हमारे पास स्टॉक में उपयोगकर्ता गतिविधि की कमी को नियंत्रित करने के लिए अधिक लचीला विकल्प है।

सत्र चर का उपयोग करके उपयोगकर्ता की निष्क्रियता की निगरानी करना

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

इस समस्या को हल करने के लिए, हम अंतर्निहित PHP तंत्र का उपयोग करने से इनकार करेंगे और कई नए सत्र चर पेश करेंगे जो हमें अपने दम पर उपयोगकर्ता की निष्क्रियता के समय को नियंत्रित करने की अनुमति देगा।

 function startSession($isUserActivity=true) { $sessionLifetime = 300; if ( session_id() ) return true; //        (     ) ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; $t = time(); if ( $sessionLifetime ) { //      , //  ,       // (  ,      lastactivity) if ( isset($_SESSION['lastactivity']) && $t-$_SESSION['lastactivity'] >= $sessionLifetime ) { //  ,      , //    ,   ,     destroySession(); return false; } else { //     , //        , //   lastactivity   , //        sessionLifetime  if ( $isUserActivity ) $_SESSION['lastactivity'] = $t; } } return true; }

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

2013-06-07 पर अद्यतन

SessionStart () फ़ंक्शन के परिणाम को संसाधित करना

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

जैसा कि आप देख सकते हैं, sessionStart फ़ंक्शन FALSE को दो मामलों में वापस कर सकता है। या तो सत्र को कुछ आंतरिक सर्वर त्रुटियों (उदाहरण के लिए, php.ini में गलत सत्र सेटिंग्स) के कारण शुरू नहीं किया जा सका, या सत्र समाप्त हो गया है। पहले मामले में, हमें उपयोगकर्ता को एक पृष्ठ पर एक त्रुटि बताते हुए स्थानांतरित करना होगा कि सर्वर पर समस्याएं हैं और समर्थन सेवा से संपर्क करने का तरीका है। दूसरे मामले में, हमें उपयोगकर्ता को लॉगिन फॉर्म में ट्रांसफर करना चाहिए और उसमें यह प्रदर्शित करना होगा कि सत्र समाप्त हो गया है। ऐसा करने के लिए, हमें त्रुटि कोड दर्ज करने और FALSE के बजाय संबंधित कोड वापस करने की आवश्यकता है, और कॉलिंग विधि में इसे जांचें और तदनुसार कार्य करें।

अब, भले ही सर्वर पर सत्र अभी भी मौजूद है, यह पहली बार एक्सेस होने पर नष्ट हो जाएगा, यदि उपयोगकर्ता की निष्क्रियता की समय सीमा समाप्त हो गई है। और यह कोई फर्क नहीं पड़ता कि वैश्विक PHP सेटिंग्स में कौन सा सत्र जीवनकाल सेट है।

नोट: यदि ब्राउज़र बंद कर दिया गया था और सत्र नाम के साथ कुकी स्वचालित रूप से नष्ट हो गई तो क्या होगा? अगली बार जब ब्राउज़र खोला जाता है तो सर्वर के लिए अनुरोध में सत्र कुकी शामिल नहीं होंगी, और सर्वर सत्र को खोलने और उपयोगकर्ता निष्क्रियता के समय की जांच करने में सक्षम नहीं होगा। हमारे लिए, यह एक नया सत्र बनाने के लिए समान है और कार्यक्षमता और सुरक्षा को प्रभावित नहीं करता है। लेकिन एक निष्पक्ष सवाल यह उठता है - जो तब पुराने सत्र को नष्ट कर देता है, अगर अब तक हमने इसे समाप्त कर दिया है? या अब यह सत्र निर्देशिका में हमेशा के लिए लटका रहेगा? PHP में पुराने सत्रों को साफ़ करने के लिए कचरा संग्रह नामक एक तंत्र है। यह सर्वर के अगले अनुरोध के क्षण में शुरू होता है और सत्र फ़ाइलों के अंतिम परिवर्तन की तारीख के आधार पर सभी पुराने सत्रों को साफ करता है। लेकिन कचरा संग्रह तंत्र सर्वर के लिए हर अनुरोध पर शुरू नहीं होता है। लॉन्च की आवृत्ति (या बल्कि, प्रायिकता) सत्र के लिए दो सेटिंग्स द्वारा निर्धारित की जाती है। gc_probability और session.gc_divisor सेटिंग्स। पहले पैरामीटर को दूसरे से विभाजित करने का परिणाम कचरा संग्रह तंत्र को ट्रिगर करने की संभावना है। इस प्रकार, सर्वर के लिए प्रत्येक अनुरोध के साथ सत्र सफाई तंत्र को लॉन्च करने के लिए, इन मापदंडों को समान मूल्यों पर सेट किया जाना चाहिए, उदाहरण के लिए, "1"। यह दृष्टिकोण सुनिश्चित करता है कि सत्र निर्देशिका साफ है, लेकिन जाहिर है कि सर्वर के लिए बहुत महंगा है। इसलिए, उत्पादन प्रणालियों में, session.gc_divisor का डिफ़ॉल्ट मान 1000 पर सेट होता है, जिसका अर्थ है कि कचरा संग्रह तंत्र 1/1000 की संभावना के साथ शुरू होगा। यदि आप अपनी php.ini फ़ाइल में इन सेटिंग्स के साथ प्रयोग करते हैं, तो आप देख सकते हैं कि ऊपर वर्णित मामले में, जब ब्राउज़र अपने सभी कुकीज़ को बंद कर देता है और साफ कर देता है, पुराने सत्र अभी भी कुछ समय के लिए सत्र निर्देशिका में बने रहते हैं। लेकिन यह आपको चिंता नहीं करनी चाहिए, क्योंकि जैसा कि पहले ही उल्लेख किया गया है, यह किसी भी तरह से हमारे तंत्र की सुरक्षा को प्रभावित नहीं करता है।

2013-06-07 पर अद्यतन

सत्र फ़ाइल लॉकिंग के कारण स्क्रिप्ट फ्रीज़ को रोकना

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

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

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

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

अनधिकृत उपयोग से सत्रों की रक्षा करना

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

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

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

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

(हम उस कोड का हिस्सा छोड़ देते हैं जिसे पहले ही माना जा चुका है)।

 function startSession($isUserActivity=true) { //     $idLifetime = 60; ... if ( $idLifetime ) { //      , //  ,         // (  ,      starttime) if ( isset($_SESSION['starttime']) ) { if ( $t-$_SESSION['starttime'] >= $idLifetime ) { //      //    session_regenerate_id(true); $_SESSION['starttime'] = $t; } } else { //   ,      //         $_SESSION['starttime'] = $t; } } return true; }

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

नोट: session_regenerate_id () फ़ंक्शन को कॉल करते समय नया सत्र पहचानकर्ता ब्राउज़र कुकीज़ में जाता है, जो session_start () के समान एक नया कुकी भेजता है, इसलिए हमें कुकीज़ को स्वयं अपडेट करने की आवश्यकता नहीं है।

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

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

कई उपयोगकर्ताओं की ओर से एक ब्राउज़र में एक साथ काम करने की क्षमता

अंतिम कार्य जिस पर मैं विचार करना चाहूंगा, एक ही ब्राउज़र में कई उपयोगकर्ताओं के एक साथ काम करने की संभावना है। , , , «».

, , PHP (PHPSESSID). , , , PHPSESSID. , , . , . .

 function startSession($isUserActivity=true, $prefix=null) { ... if ( session_id() ) return true; //      , //    ,   , //        (, MYPROJECT) session_name('MYPROJECT'.($prefix ? '_'.$prefix : '')); ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; ... }

, startSession() . , , GET/POST .

निष्कर्ष

PHP, .

 function startSession($isUserActivity=true, $prefix=null) { $sessionLifetime = 300; $idLifetime = 60; if ( session_id() ) return true; session_name('MYPROJECT'.($prefix ? '_'.$prefix : '')); ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; $t = time(); if ( $sessionLifetime ) { if ( isset($_SESSION['lastactivity']) && $t-$_SESSION['lastactivity'] >= $sessionLifetime ) { destroySession(); return false; } else { if ( $isUserActivity ) $_SESSION['lastactivity'] = $t; } } if ( $idLifetime ) { if ( isset($_SESSION['starttime']) ) { if ( $t-$_SESSION['starttime'] >= $idLifetime ) { session_regenerate_id(true); $_SESSION['starttime'] = $t; } } else { $_SESSION['starttime'] = $t; } } return true; } function destroySession() { if ( session_id() ) { session_unset(); setcookie(session_name(), session_id(), time()-60*60*24); session_destroy(); } }

, , , , PHP.

PHP में सत्र का उपयोग करने के नुकसान

PHP अंतर्निहित उपकरणों के साथ उपयोगकर्ता निष्क्रियता की निगरानी करना

सत्र चर का उपयोग करके उपयोगकर्ता की निष्क्रियता की निगरानी करना

SessionStart () फ़ंक्शन के परिणाम को संसाधित करना

सत्र फ़ाइल लॉकिंग के कारण स्क्रिप्ट फ्रीज़ को रोकना

अनधिकृत उपयोग से सत्रों की रक्षा करना

कई उपयोगकर्ताओं की ओर से एक ब्राउज़र में एक साथ काम करने की क्षमता

निष्कर्ष

More articles: