2009-02-22 17 views
10

मैं PHP के लिए नया हूँ। पीएचपी भाषा सीखने की राह में, मैं ध्यान दें कि, कुछ वेबसाइट होगा यूआरएल इस तरह की:"?" क्या है PHP में उपयोग किए गए यूआरएल में प्रतीक?

www.website.com/profile.php?user=roa3 & ...

मेरे सवालों का:

  1. "?" क्या है प्रतीक के लिए इस्तेमाल किया?

  2. यदि मैं एक PHP वेबसाइट विकसित कर रहा था, तो क्या मुझे इसे अपने यूआरएल में उपयोग करना चाहिए? उदाहरण के लिए, के बाद एक उपयोगकर्ता (roa3) सफल प्रवेश किया था, मैं बजाय "www.website.com/profile.php" के "www.website.com/profile.php?user=roa3"

  3. पर रीडायरेक्ट करेगा इसका उपयोग करने के फायदे और नुकसान क्या हैं?

उत्तर

21

अच्छा सवाल है, संक्षेप में,

  1. "?" स्ट्रिंग पूछताछ की शुरुआत के लिए खड़ा है जिसमें डेटा को सर्वर से पास किया गया है। इस मामले में आप उपयोगकर्ता = roa3 से profile.php पृष्ठ पर जा रहे हैं। profile.php के भीतर आप $ _GET ['user'] का उपयोग कर डेटा प्राप्त कर सकते हैं। querystring क्लाइंट एजेंट से सर्वर को डेटा भेजने के तरीकों में से एक है। दूसरा HTTP सर्वर में डेटा और सर्वर पर POST रखता है, आपको सीधे ब्राउज़र से HTTP पोस्ट डेटा नहीं दिखाई देता है।

  2. क्वेरीस्ट्रिंग उपयोगकर्ता द्वारा संपादित किया जा सकता है और यह जनता के लिए दृश्यमान है। यदि www.website.com/profile.php?user=roa3 सार्वजनिक होने का इरादा है तो यह ठीक है, अन्यथा आप वर्तमान उपयोगकर्ता के संदर्भ प्राप्त करने के लिए सत्र का उपयोग करना चाह सकते हैं।

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

0

सर्वर के दृष्टिकोण से,? बस एक और चरित्र है। PHP यूआरएल के कुछ हिस्सों के लिए आसान तरीकों प्रदान करता है? चरित्र, उदा। "/profile.php?user=roa3" के लिए, PHP $ _GET ['user'] = 'roa3' सेट करेगा।

कारण? यूआरएल में उपयोगी है कि ब्राउज़र फॉर्म का उपयोग करके गतिशील यूआरएल बना सकते हैं - उपर्युक्त मामले में, मैं उम्मीद करता हूं कि यूआरएल एक HTTP फॉर्म द्वारा "उपयोगकर्ता" फ़ील्ड के साथ बनाया गया था, जिसमें मानव उपयोगकर्ता ने "roa3" टाइप किया है।

+0

यह गलत है। "?" सर्वर के लिए "बस एक और चरित्र" नहीं है। सर्वर यूआरएल को "?" पर विभाजित करता है (यदि कोई है तो)। पहले का हिस्सा अनुरोधित फ़ाइल है, और बाद में "क्वेरी स्ट्रिंग" है, जिसे CGI को QUERY_STRING पर्यावरण चर के रूप में प्रस्तुत किया गया है। –

+1

मुझे शायद यह कहना चाहिए कि सर्वर * सामान्य रूप से * विशेष रूप से इसका इलाज करने की अपेक्षा नहीं की जाती है। PHP (और अधिकांश अन्य वेब ढांचे) के मामले में कुछ उपचार प्रदान किए जाते हैं, जैसा कि मैंने चर्चा की थी। सवाल कहीं भी CGI निर्दिष्ट नहीं करता है। – Edmund

+1

यह सर्वर के लिए विशेष नहीं हो सकता है, लेकिन यह PHP के बजाय HTTP मानक का हिस्सा है। –

0
  1. "?"यूआरएल और मानकों को अलग करने के लिए प्रयोग किया जाता है। उदाहरण के लिए, यह http://www.url.com/resourcepath?a=b&c=d की तरह है। इस मामले में एक = ख request_parameter = request_value की तरह है।

  2. हां, इसकी वजह से कुल मापदंडों का ज्यादा उपयोग करने के लिए उचित नहीं यूआरएल आकार सीमित है और यह जीईटी अनुरोध की तरह है, जहां सभी पैरामीटर यूआरएल पर दिखाए जाते हैं और उपयोगकर्ता इसे संशोधित कर सकता है। अपने उदाहरण में, यह कहें कि क्या उपयोगकर्ता यूजर को "user = techmaddy" में संशोधित करता है।

  3. लाभ यह जीईटी के अनुरोधों के लिए उपयोग किया जा सकता है। नुकसान कम सुरक्षा, आकार में सीमा है।

4

1) एक उपयोगकर्ता लॉग में आपकी साइट के लिए, आपको Sessions का प्रयोग करेंगे तो यूआरएल जैसे profile.php?username=roa3

2) में यह पारित करने में एक ? प्रतीक का उपयोग करने के बजाय वहाँ उपयोगकर्ता नाम स्टोर करने के लिए यूआरएल को आम तौर पर Search Engine Optimization के लिए बुरा माना जाता है। इसके अलावा, यूआरएल थोड़ा बदसूरत लग रहा है। mod_rewrite का उपयोग करके आप profile.php?user=roa3 या products.php?id=123&category=toys के साथ वही काम कर सकते हैं: site.com/profile/roa3 या products/toys/123

CodeIgniter ढांचे का उपयोग करके आप डिफ़ॉल्ट रूप से अनुकूल यूआरएल देंगे और आपके यूआरएल में ? एस की आवश्यकता को खत्म कर देंगे। उदाहरण के लिए this page देखें।

3)? प्रतीक का उपयोग PHP पृष्ठ के कोड के अंदर भी किया जाता है। उदाहरण के लिए, एक if else ब्लॉक जैसे:

if ($x==1) 
    $y=2; 
else 
    $y=3; 

के रूप में भी लिखा जा सकता है: "?"

$y=($x==1) ? 2 : 3; 
3

यह दर्शाता है कि कुछ जीईटी चर का पालन करना है। आप उदाहरण "उपयोगकर्ता" नामक चर का उपयोग करते हैं, और "roa3" नामक एक चर निर्दिष्ट करते हैं।

प्राप्त वैरिएबल का उपयोग कर के लाभ:

  • वे यूआरएल

नुकसान के हिस्से के रूप बुकमार्क किया जा सकता

  • वे सार्वजनिक कर रहे हैं .. किसी को भी रोकना और इस जानकारी को देख सकते हैं । इन यूआरएल अनुरोधों को भी यात्रा के साथ सर्वर द्वारा कैश किया जाता है। तो किसी को भी सिर्फ हाथ से उस जानकारी टाइप करके अपने roa3 प्रयोक्ता का रूप धारण कर सकते हैं ... भी वे किसी दूसरे उपयोगकर्ता के लिए roa3 बदलने और उन्हें का रूप धारण कर सकता है ..

तुम भी एक "&" प्रतीक अलग करने के लिए उपयोग कर सकते हैं कई चर जैसे: www.website.com/profile.php?user=roa3&fav_colour=blue

अन्य विकल्प:

  • पोस्ट चर

    • आप POST चर के माध्यम से अपने चर भेज सकते हैं।ये चर अनुरोध के शीर्षलेख में पास किए गए हैं, अनुरोध के यूआरएल नहीं। वे तुरंत स्पष्ट नहीं हैं, और टीएच यात्रा के साथ सर्वर द्वारा कैश नहीं किए जाते हैं, लेकिन वे अभी भी पढ़ सकते हैं। जब तक आपके पास एक HTTPS प्रक्षेपण स्थापित न हो।
    • किसी रूप में चर को POST या GET विधियों द्वारा भेजा जा सकता है .. आप इसे फ़ॉर्म के "विधि" में निर्दिष्ट करते हैं। <form action="index.php" method='post'/>
  • सत्र चर

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

php में इन चरों का उपयोग करने के लिए आप उपयोग कर सकते हैं:

  • $x = $_GET['user'] के लिए एक मिल चर
  • $x = $_POST['user]
  • $x = $_REQUEST['user'] - मिलता है, पद और कुकी चर
  • $x = $_COOKIE['user'] का संयोजन - कुकी चर
  • $x = $_SESSION['user'] सत्र चर

काफी सरल सामान (user चर उपयोग किए जा रहे के नाम के साथ प्रतिस्थापित किया जा सकता) तक पहुँचने के लिए है, लेकिन महत्वपूर्ण पता है कि वे वास्तव में करते हैं।

+1

आईपीएस के खिलाफ सत्र आईडी जांचना बहुत अच्छा नहीं है अगर लोग कई आईपी पते के साथ कुछ प्रॉक्सी फार्म के पीछे बैठते हैं। साथ ही, एक प्रॉक्सी साझा करने वाले लोगों को अभी भी किसी अन्य से बचाया नहीं जाएगा। एप्लिकेशन को इसे किसी अन्य तरीके से संभालना है - यदि आप संवेदनशील डेटा से निपटते हैं: https का उपयोग करें। –

+0

हाँ यह सच है। सत्रों के खिलाफ आईपी की जांच से सुरक्षा बढ़ेगी, लेकिन इससे कुछ बड़े छेद निकल जाएंगे। Https स्थापित होने के बाद तेह सत्र स्थापित करना हमेशा सबसे सुरक्षित है। – Bingy

+0

बस एक sidenote: जीईटी वर्रों को अलग करने के लिए ';' का उपयोग करना कानूनी है। हालांकि मैंने इसे कभी नहीं देखा है और इसलिए इसकी अनुशंसा नहीं की जाएगी। – alex

6

अब तक जो उत्तर मैंने देखा है, वे PHP के संदर्भ में हैं, जब वास्तव में यह भाषा विशिष्ट नहीं है। अब तक दिए गए उत्तरों PHP के दृष्टिकोण से हैं और जानकारी का उपयोग करने के लिए उपयोग की जाने वाली विधियों को एक भाषा से अगले भाषा में भिन्न होता है, लेकिन जिस प्रारूप में डेटा यूआरएल (क्वेरी स्ट्रिंग के रूप में जाना जाता है) में रहता है वही (उदा: पृष्ठ.ext? key1 = मान & key2 = मान & ...)।

मैं अपने तकनीकी पृष्ठभूमि या ज्ञान पता नहीं है, तो कृपया मुझे माफ कर ...

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

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

दो विधियों और जब उन्हें इस्तेमाल करने के बारे में कुछ संसाधनों ...

http://www.cs.tut.fi/~jkorpela/forms/methods.html http://weblogs.asp.net/mschwarz/archive/2006/12/04/post-vs-get.aspx http://en.wikipedia.org/wiki/Query_string

अब एक सख्ती से पीएचपी स्थिति से, वहाँ अब आप प्राप्त करने के लिए उपयोग कर सकते हैं 3 अलग सरणियों जानकारी एक वेबपेज सर्वर पर वापस भेज दिया है। आप अपने निपटान करने के लिए है ...

  • $ _POST [ 'कीनेम'], एक POST पद्धति से केवल जानकारी
  • $ _GET [ 'कीनेम'], केवल जानकारी किसी GET से हड़पने के लिए आकर्षित करने के लिए विधि
  • $ _REQUEST ['keyname'], आपको पोस्ट, GET, और सबमिट की गई किसी भी कुकी जानकारी को पकड़ने की अनुमति देने के लिए। एक कैचल का क्रमबद्ध करें, खासतौर से ऐसे मामलों में जहां आप नहीं जानते कि डेटा सबमिट करने के लिए कोई पृष्ठ किस विधि का उपयोग कर रहा हो।

$ _REQUEST विधि के साथ सीधे जाकर मैला मत बनो। जब तक आपके पास $ _REQUEST चर के लिए ऊपर वर्णित कोई मामला नहीं है, तो इसका उपयोग न करें। जब आप सुरक्षा की बात करते हैं तो आप 'इन सभी को अस्वीकार कर सकते हैं और केवल x, y, z' दृष्टिकोण का उपयोग करना चाहते हैं। केवल उस डेटा की तलाश करें जिसे आप जानते हैं कि आपकी अपनी साइट भेज रही है, केवल उन संयोजनों की तलाश करें जिन्हें आप उम्मीद करेंगे, और इसका उपयोग करने से पहले सभी जानकारी साफ़ करें। उदाहरण के लिए ..

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

यह दूर नहीं अंत सब कर रहा है हो सकता है-सभी पीएचपी सुरक्षा के लिए , लेकिन हम इसके लिए यहां नहीं हैं। यदि आप लाइन के साथ और जानना चाहते हैं, तो यह SO के लिए एक और सवाल है।

उम्मीद है कि यह किसी भी प्रश्न पूछने में मदद करता है और स्वतंत्र महसूस करता है।

+1

आप $ _COOKIE के साथ कुकी जानकारी तक पहुंच सकते हैं। –

1

? HTTP मानक का हिस्सा है और PHP का हिस्सा नहीं है। सोचा था कि मुझे यह इंगित करना चाहिए कि जब आप किसी अन्य भाषा में जाते हैं और इसे फिर से देखते हैं तो आप भ्रमित नहीं होते हैं कि PHP शामिल है।

अन्यथा ऊपर कुछ उत्कृष्ट उत्तर दिए गए हैं।

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