Ga naar inhoud

[PHP] 2 manieren om variabele uit URI te halen, welke beter?


Aanbevolen berichten

Heb twee codes om een variable uit een link te halen (www.blaa.nl/index.php?[b:1e4a9cd235]deel[/b:1e4a9cd235] [code:1:1e4a9cd235] <?php $deel = $_REQUEST["deel"]; if(!$deel || trim($deel) == "") { $inhoud = $_REQUEST["inhoud"]; if(!$inhoud || trim($inhoud) == "") { $bestand = "home"; } .... [/code:1:1e4a9cd235] en deze; gewoon als variable gebruiken [code:1:1e4a9cd235] $deel = blaat etc. [/code:1:1e4a9cd235] Ik dacht dat ik gelezen had dat de bovenste beter was, om veiligheidsreden. Is dat zo?
Link naar reactie
Het heeft ermee te maken dat mensen anders ook op andere manieren variabelen kunnen doorgeven waardoor je beveilingsgaten kunt creeeren. Ik weet het niet heel exact helaas. $_REQUEST is in ieder geval onhandig, omdat deze tevens de $_POST array bevat en wellicht ook nog de $_COOKIE (kijk even op php.net voor het fijne). $_GET is wat dat betreft veel specifieker, en daardoor weet je ook wat je terugkrijgt. Waarschijnlijk staat er op php.net wel wat meer uitleg over.
Link naar reactie
Over die beveiliging: Als jij iets specifieks met POST variabelen aan het doen bent, maar je haalt ze op met $_REQUEST, dan kan ik die POST data 'na-apen' door er GET variabelen mee te sturen, oftewel achte de url zetten (?var1=b). Als jij bijvoorbeeld een POST variabele(ingelogd=true) gebruikt om te kijken of iemand ingelogd is (sowieso verkeerd) kan ik net doen alsof ik ingelogd ben (...ex.php?ingelogd=true). Als je $_REQUEST gebruikt. Dit werkt hetzelfde met $_COOKIE, want die variabelen worden ook in $_REQUEST gezet. Niet echt veilig dus.
Link naar reactie
[quote:b397780ab9="[m]"]Niet echt veilig dus.[/quote:b397780ab9] En een post kan je niet na-apen? Daar heeft het dus niets mee te maken. De reden waarom je beter de superglobals kan gebruiken is dat de kans dat je een lek introduceert in je pagina veel kleiner wordt. Variabelen die niet geinitialiseerd worden maar "ineens" gebruikt worden kunnen via de verkeerde weg aan hun waarde komen (bijvoorbeeld via de querystring). Maar het is, afaik, wel gewoon mogelijk om veilige code te schrijven zonder deze superglobals. Je zal dan alleen al je variabelen moeten declareren/initialiseren voor je deze gebruikt.
Link naar reactie
[quote:c4e7e04b98="Johnny321"]Dankje, et begint me duidelijk te worden. Ben nog betrekkelijk nieuw in de wereld van PHP :D[/quote:c4e7e04b98] Vroeger stond die 'register globals' instelling standaard aan, maar tegenwoordig staat ie standaard uit als je php installeert. Je wordt dus gemotiveerd om $_GET["bla"], $_POST["bla"], enz.. te gebruiken en ik moet zeggen dat ik het stukken fijner vind werken. Bijkomend voordeel is namelijk dat je gelijk aan de variabele kunt zien waar ie vandaan komt. Ook handig bij bijvoorbeeld het debuggen van een lang script.
Link naar reactie
[quote:e111771f45="Anne"]$_REQUEST is in ieder geval onhandig, ...[/quote:e111771f45] $_REQUEST is wel handig, omdat het alle variabelen bevat die door een request van een client worden gestuurd. Aangezien het meestal onbelangrijk (dare me ;)) is waar een variabele van een request zijn waarde krijgt (POST, GET of COOKIE) is $_REQUEST dus ideaal. Je kan hierdoor later makkelijk tussen bv. POST, GET en COOKIE wisselen zonder alle code te hoeven herschrijven (als je applicatie uit lagen bestaat tenminste). Het enige voordeel is dus dat je met $_POST weet hoe het verstuurt is, maar de situaties waarin je dit wil weten zijn er heel weinig. Oké, voor debuggen kan het handig zijn, maar ik zet dan tijdelijk print_r($GLOBAL) in mijn script. [quote:e111771f45="[m]"]Niet echt veilig dus.[/quote:e111771f45]Alle variabelen via een request dienen altijd gecontroleerd\gefilteerd worden op hun inhoud (klopt de inhoud met wat je verwacht), omdat deze variabelen gemanipuleerd kunnen worden buiten de 'applicatie' om. Dus $_POST is niets beter dan $_REQUEST, maar dat heeft Annie ook al toegelicht. -Rémy
Link naar reactie

Om een reactie te plaatsen, moet je eerst inloggen

Gast
Reageer op dit topic

×   Geplakt als verrijkte tekst.   Herstel opmaak

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...