2012-06-19 11 views
6

मैं हाल ही में एक PHP स्क्रिप्ट में इस रेखा के पार पहुंचा

$_REQUEST['start_date']=$date; 

यह अनुमति या किसी भी तरह सुपर वैश्विक $ _REQUEST चर के लिए कुछ आवंटित करने के लिए करने में उपयोगी है? यदि कोई $ _COOKIE ['start_date'] है तो क्या यह कुकी मान को बदल देगा?

+0

हाँ, असाइनमेंट पूरी तरह से मान्य है, हालांकि मैं इसका उपयोग नहीं कर सकता – gopi1410

+2

क्यों कोशिश नहीं करें और देखें कि क्या होता है? इस तरह आप कोड सीखना सीखते हैं। – vascowhite

+0

आप वह हाँ कर सकते हैं। पता नहीं क्यों तुम? Btw। आप कोड को आज़माकर निष्पादित कर सकते हैं; पी – Bono

उत्तर

6

हां, इसकी अनुमति है और कई कारणों से सहायक हो सकता है।

  • डिबगिंग - हैं, तो किसी कारण से आप "बल" एक निश्चित अनुरोध पैरामीटर, आप $_REQUEST, $_GET, या $_POST सरणियों में एक मूल्य निर्धारित कर सकते हैं करना चाहते हैं। यह अनुरोध पृष्ठ द्वारा भेजे गए किसी भी मूल्य को ओवरराइड करेगा, जिसे वांछित किया जा सकता है।
  • आप पूरे सरणी साथ कुछ करने के लिए जा रहे हैं क्योंकि - अगर आप, उदाहरण के लिए, json_encode$_REQUEST कुंजी-मान जोड़ों के सभी के साथ-साथ कुछ अतिरिक्त मूल्यों के रूप में, यह हो सकता है चाहता हूँ $_REQUEST पर इस तरह से "add" मानों को तेज़ करने के लिए तेज़ी से $_REQUESTjson_encode() पर जाएं।

$_COOKIE के बारे में अपने प्रश्न के संबंध में, आप कुकी के मूल्य को इस तरह से नहीं बदल सकते हैं, केवल इसे एक्सेस करें।

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

अपनी वेबसाइट पर SQL इंजेक्शन हमले को रोकने के बारे में सोचो। यही कारण है कि सरल कोड उन सब $_REQUEST चर के लिए बंद हो जाएगा (mysqli उदाहरण):

function injectionwall($dbinterface) 
{ 
    foreach($_REQUEST as $key => $data) 
    { 
     $_REQUEST[$key]=$dbinterface->real_escape_string($data); 
    } 
} 

सभी $_REQUEST चर अब उपयोग करने के लिए :)

+0

आरई: "लेखक से नोट" - आपको उस चेतावनी को जोड़ने का बहुत अधिकार है। मैं वास्तव में उस उदाहरण को हटाने का समर्थन करता हूं क्योंकि यह वास्तव में कई तरीकों से बहुत खराब अभ्यास है। एक सुरक्षित उदाहरण होना चाहिए (हालांकि मैं एक उपयोगी सोचने के लिए संघर्ष कर रहा हूं)। – Robbie

0

यह अनुमति या किसी भी तरह सुपर वैश्विक $ _REQUEST चर के लिए कुछ आवंटित करने के लिए करने में उपयोगी है?

हां, इसकी अनुमति है, लेकिन उपयोगी नहीं है।

यदि कोई $ _COOKIE ['start_date'] है तो यह कुकी मूल्य को बदल देगा?

नहीं है, उपयोग setcookie http://php.net/manual/en/function.setcookie.php

यह सब सुपर वैश्विक चर केवल साधारण वैश्विक सरणियों।

+4

मैं पूरी तरह से इस बयान से असहमत हूं कि "यह है उपयोगी नहीं"। – jedwards

+0

@jedwards उसे इस सुपर ग्लोबल वैरिएबल का उपयोग देखभाल के साथ करना है, क्योंकि वह इसे जानने के बिना प्राथमिक डेटा को फिर से लिख सकता है। यदि यू इस यू का उपयोग करता है तो यह जानना होगा कि यह कैसे काम करता है। मुझे लगता है, उन्होंने ' – Sergey

+0

@jedwards' टिप्पणी के अलावा, आप उस चर का उपयोग नियंत्रक स्तर पर कुछ संग्रहीत करने के लिए नहीं कर सकते थे और इसे देखने के स्तर पर पुनर्प्राप्त कर सकते थे (बशर्ते आप परम नाम को एक सुंदर "अद्वितीय" नाम दें कुछ के साथ टक्कर नहीं है)? यह एक बहुत अच्छा उदाहरण प्रतीत होता है कि यह कैसे उपयोगी हो सकता है, क्या मैं गलत हूं? – reallynice

3

मुझे लगता है कि एक और अधिक उचित प्रतिक्रिया "है हाँ, इसकी अनुमति है सुरक्षित हैं, लेकिन इसे खराब अभ्यास पर विचार करें ताकि बेहतर प्रोग्रामिंग गुणवत्ता के लिए बचें "।

यह क्यों अनुमति दी गई है (और शायद अपने प्रश्न के बिंदु):

  • superglobals प्रोग्राम निष्पादन के शुरू में स्थापित कर रहे हैं और उसके बाद नहीं अन्यथा बदल (जब तक आप यह करते हैं)। तो आपके परिवर्तन किसी भी अन्य समारोह में स्थायी और आसानी से दिखाई दे रहे हैं। तो आगे बढ़ें, जैसा चाहें संपादित करें।

लेकिन - से बचने के लिए क्यों सबसे अच्छा:

  • यह आम तौर पर पता है कि अपने चर हैं और वे कहाँ से आए अच्छी आदत है। आइए मान लें कि आपके पास एक ऐसा फ़ंक्शन है जो $ _REQUEST में हेरफेर करके आपके सभी इनपुट को "सुरक्षित बनाता है"। जब आप $ _REQUEST का उपयोग करने के लिए आते हैं, तो आप कभी भी सुनिश्चित नहीं हो सकते कि आपका "सुरक्षित करें" फ़ंक्शन चलाया गया है या नहीं। यदि यूनिट परीक्षण कर रहा है, तो यह विशेष रूप से समस्याग्रस्त हो जाता है। यदि आप $ _REQUEST को किसी अन्य चर में फिर से असाइन करते हैं, तो आप उस चर के दायरे को अधिक आसानी से ट्रैक कर सकते हैं। यहां तक ​​कि यदि आप उस अन्य चर को "वैश्विक" बनाते हैं तो आप जानते हैं कि यह सुरक्षित है यह मौजूद है। (डाउनसाइड, आप कुछ बेहद भारी ऐप्स के लिए मेमोरी/प्रोग्रामिंग पावर बर्बाद कर सकते हैं, लेकिन यदि आप इस सवाल से पूछ रहे हैं तो आप इसका लंबा सफर तय कर सकते हैं।)

  • यदि आप $ _REQUEST संशोधित करते हैं, तो आप संपादन नहीं कर रहे हैं $ _POST, $ _GET या $ _COOKIE; यदि आप भविष्य में कुछ समय के रूप में अपना कोड $ _POST में बदलना चाहते हैं तो यह भ्रम पैदा कर सकता है (उदाहरण के लिए जो डेटा आपको लगता है कि आपने "सुरक्षित किया है" नहीं होगा)।

अंत में, सामान्य रूप में $ _REQUEST का उपयोग कर के बारे में दो बातें: ये

  • $ _REQUEST $ _COOKIE, $ _POST और $ _GET (और पुराने संस्करणों में $ _FILES) का एक संयोजन है। लेकिन आप नहीं जानते कि जब तक आप php.ini फ़ाइल - http://www.php.net/manual/en/ini.core.php#ini.variables-order पढ़ नहीं लेते हैं, तब तक प्राथमिकता कौन लेगी। तो $ _GET से $ _POST प्राथमिकता लेने पर भरोसा न करें!

  • $ _POST, $ _GET या $ _COOKIE का उपयोग करने का एक अन्य कारण यदि आप कर सकते हैं: - यह भविष्य के डेवलपर के लिए आपके कोड को डीबग करना आसान बनाता है क्योंकि उन्हें पता चलता है कि आप कहां से आने वाले चर की अपेक्षा करते हैं। लेकिन कभी-कभी यह $ _REQUEST के लिए उपयुक्त है यदि आप वास्तव में परवाह नहीं करते हैं कि मूल्य कुकी से आता है, प्राप्त करें या पोस्ट करें।

अस्वीकरण: हाँ, मैं $ _REQUEST का उपयोग करता हूं, और हाँ, मैंने इसे कुछ स्थितियों के आसपास संशोधित करने के लिए संशोधित किया है। सिर्फ यह कहें कि आप बेहतर प्रोग्रामर बनना नहीं चाहते हैं।

संबंधित मुद्दे

 संबंधित मुद्दे