PHP: $ _SESSION - पेशेवरों और $ _SESSION चर

Question

एक बात में अस्थायी रूप से उपयोग डेटा भंडारण मैं अधिक बार हाल ही में कर एक कार्य की शुरुआत में कुछ डेटा पुनर्प्राप्त कर रहा है शुरू कर दिया है और यह भंडारण की विपक्ष क्या हैं एक $ _SESSION ['myDataForTheTask'] में।

अब ऐसा करने में बहुत सुविधाजनक लगता है लेकिन मुझे इस दृष्टिकोण का उपयोग करके प्रदर्शन, सुरक्षा जोखिम या इसी तरह के बारे में कुछ भी पता नहीं है। क्या यह ऐसा कुछ है जो नियमित रूप से प्रोग्रामर द्वारा अधिक विशेषज्ञता के साथ किया जाता है या क्या यह शौकिया चीज है?

उदाहरण के लिए:

if (!isset($_SESSION['dataentry'])) 
{ 
    $query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=" . mysql_real_escape_string($_GET['wave_id']); 
    $result_taskinfo = $db->query($query_taskinfo); 
    $row_taskinfo = $result_taskinfo->fetch_row(); 

     $dataentry = array("pcode" => $row_taskinfo[0], "modules" => $row_taskinfo[1], "data_id" => 0, "wavenum" => $row_taskinfo[2], "prequest" => FALSE, "highlight" => array()); 

     $_SESSION['dataentry'] = $dataentry; 
} 

Answer 1

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

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

मैं सुरक्षित रूप से अस्थायी चर भंडारण के किसी अन्य तरीके से नहीं सोच सकते हैं (क्योंकि कुकीज़ आसानी से संशोधित किया जा सकता है और इस ज्यादातर मामलों में अवांछनीय हो जाएगा) तो $ _SESSION

Answer 2

$ _SESSION आइटम सत्र, जो डिफ़ॉल्ट रूप से है, में जमा हो जाती है, डिस्क पर रखा। अपनी खुद की सरणी बनाने और इसे 'डेटाेंट्री' सरणी प्रविष्टि में करने की आवश्यकता नहीं है जैसे आपने किया था। आप $ _SESSION ['pcode'], $ _SESSION ['मॉड्यूल'] और इसी तरह का उपयोग कर सकते हैं।

जैसा कि मैंने कहा, सत्र डिस्क पर संग्रहीत है और सत्र में एक पॉइंटर कुकी में संग्रहीत किया जाता है। इस प्रकार उपयोगकर्ता आसानी से सत्र डेटा को रोक नहीं सकता है।

Answer 3

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

हालांकि कुछ भी पसंद है, बस सावधान रहें कि आप हमेशा उपयोगकर्ता इनपुट को स्वच्छ कर रहे हैं, खासकर यदि आप उपयोगकर्ता इनपुट को $ _SESSION चर में डाल रहे हैं, तो बाद में उस चर का उपयोग SQL क्वेरी में कर रहे हैं।

Answer 4

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

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

Answer 5

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

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

Answer 6

यदि आप अपने सर्वर पर चल रहे हैं, या ऐसे माहौल में जहां कोई भी सर्वर पर आपकी फाइल/मेमोरी पर स्नूप नहीं कर सकता है, तो सत्र डेटा सुरक्षित है। वे सर्वर पर संग्रहीत हैं और क्लाइंट को भेजी गई एक पहचान कुकी है। समस्या यह है कि अगर अन्य लोग कुकी को छीन सकते हैं और निश्चित रूप से किसी और का प्रतिरूपण कर सकते हैं। एचटीटीपीएस का उपयोग करना और यूआरएल में सत्र आईडी डालना सुनिश्चित करना आपके उपयोगकर्ताओं को उन समस्याओं में से अधिकांश से सुरक्षित रखना चाहिए। (यदि आप सावधान नहीं हैं, तो XSS का उपयोग अभी भी कुकीज़ को छीनने के लिए किया जा सकता है, Jeef Atwoods post on this भी देखें।)

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

Answer 7

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

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

Answer 8

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

SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".$_GET['wave_id']; 

आप कभी नहीं, मैं कभी नहीं दोहराएं करना चाहिए, और किसी SQL चलाने के लिए इसका इस्तेमाल करते हैं:

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

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id='".mysql_real_escape_string($_GET['wave_id'])."'"; 

Answer 9

Zend फ्रेमवर्क जो समाप्ति और (कैप्चा की तरह सामान के लिए) सुरक्षा के साथ मदद करता है सत्र डेटा प्रबंधन के लिए एक उपयोगी पुस्तकालय है। उनके पास सत्रों का एक उपयोगी स्पष्टीकरण भी है। देखें http://framework.zend.com/manual/en/zend.session.html

Answer 10

एक और तरीका है पर जाने के लिए तरीका होगा

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".(int)$_GET['wave_id']." LIMIT 1"; 

मैं मानते हुए कर रहा हूँ wave_id एक पूर्णांक है, और वहाँ केवल एक ही जवाब है कि: इनपुट सत्यापन में सुधार [ 'wave_id'] चर _GET कास्ट करने के लिए है।

Answer 11

मैं बहुत उपयोगी हो करने के लिए सत्र पाया है जाएगा, लेकिन कुछ बातें ध्यान रखें:

1) यही कारण है कि PHP एक tmp फ़ोल्डर या अन्य निर्देशिका है कि अन्य के लिए सुलभ हो सकता है कि आपका सत्र संग्रहीत कर सकते हैं आपके सर्वर पर उपयोगकर्ता। निर्देशिका को बदल सकते हैं php.ini फ़ाइल पर जाकर सत्र संग्रहीत किए जाते हैं।

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

3) मुझे लगता है कि session_destroy(); सत्र को तुरंत हटा नहीं देता है, आपको अभी भी सत्र को साफ करने के लिए PHP कचरा कलेक्टर की प्रतीक्षा करनी होगी। आप आवृत्ति को बदल सकते हैं कि कचरा कलेक्टर php.ini फ़ाइल में चलाया जाता है। लेकिन अभी भी बहुत विश्वसनीय नहीं लगता है, अधिक जानकारी http://www.captain.at/howto-php-sessions.php

Answer 12

$ _SESSION तंत्र कुकीज़ का उपयोग कर रहा है।

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

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

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

Answer 13

आप यह विचार करना चाहेंगे कि यह कितना आरईएसटी-फुल है?

यानी "A Brief Introduction to REST" में "statelessly संवाद" पैरा देखें ...

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

(या REST के लिए विकिपीडिया पर अन्य किसी भी लिंक)

अपने मामले में

तो, 'wave_id' प्राप्त करने के लिए एक समझदार संसाधन, है, लेकिन क्या तुम सच में सत्र में संग्रहीत करना चाहते हैं?निश्चित रूप से memcached ऑब्जेक्ट संसाधन को कैश करने का आपका समाधान है?

Answer 14

सत्र का उपयोग कर के कुछ अन्य नुकसान:

1. $_SESSION डेटा session.gc_maxlifetime निष्क्रियता के सेकंड के बाद समाप्त हो जाएगा।
2. आपको सत्र डेटा का उपयोग करने वाली प्रत्येक स्क्रिप्ट के लिए session_start() पर कॉल करना याद रखना होगा।
3. एकाधिक सर्वरों पर लोड संतुलन द्वारा वेबसाइट स्केल करना एक समस्या हो सकती है क्योंकि उपयोगकर्ता को हर बार एक ही सर्वर पर निर्देशित करने की आवश्यकता होगी। इसे "चिपचिपा सत्र" के साथ हल करें। क्योंकि यह जब तक अपने वास्तविक php फ़ाइल या सर्वर कमजोरियों कि शोषण किया जाता है हैक करने एक सर्वर साइड तरह से जानकारी स्टोर करने के लिए, जबकि एक उपयोगकर्ता अपने पृष्ठों पर सक्रिय रूप से है, इसलिए कठिन

Answer 15

$ _SESSION, सुरक्षा में बहुत उपयोगी है। एक बहुत ही अच्छा कार्यान्वयन यह पुष्टि करने के लिए एक वैरिएबल संग्रहीत कर रहा है कि उपयोगकर्ता लॉग इन है, और केवल लॉग इन होने की पुष्टि होने पर ही क्रियाएं करने की इजाजत दे रही है।