[PHP/(My)SQL] voor dummies - Deel 61

Ipv _POST en _GET kan je beter _REQUEST gebruiken... _POST en _GET zitten gewoon in _REQUEST:

http://nl3.php.net/manual/en/reserved.variables.request.php

quote:

Op woensdag 6 augustus 2008 17:27 schreef slacker_nl het volgende:
Ipv _POST en _GET kan je beter _REQUEST gebruiken... _POST en _GET zitten gewoon in _REQUEST:

http://nl3.php.net/manual/en/reserved.variables.request.php

Geprobeerd maar haalt niks uit

Dat lijkt me sterk...

Een URL met daarin debug info, zodat we kunnen zien wat er fout gaat?

en verder zou ik me eens inlezen in sql injecties, want die code is erg vulnerable.

quote:

Op woensdag 6 augustus 2008 17:37 schreef slacker_nl het volgende:
Dat lijkt me sterk...

Een URL met daarin debug info, zodat we kunnen zien wat er fout gaat?

Code draait local he Of hoe doe ik het anders

quote:

Op woensdag 6 augustus 2008 17:44 schreef DionysuZ het volgende:
en verder zou ik me eens inlezen in sql injecties, want die code is erg vulnerable.

yes i know, maar script is toegankelijk voor één persoon (verder geen excuus)

quote:

Op woensdag 6 augustus 2008 17:27 schreef slacker_nl het volgende:
Ipv _POST en _GET kan je beter _REQUEST gebruiken... _POST en _GET zitten gewoon in _REQUEST:

http://nl3.php.net/manual/en/reserved.variables.request.php

$_REQUEST heeft ook nadelen. Je weet niet meer of een waarde via GET of POST (of COOKIE) geset is. En het is meer typen.

quote:

Op woensdag 6 augustus 2008 18:18 schreef Light het volgende:

[..]

$_REQUEST heeft ook nadelen. Je weet niet meer of een waarde via GET of POST (of COOKIE) geset is. En het is meer typen.

Mja, _GET en _POST zijn nagenoeg hetzelfde, in JSP moet je ook een _get en een _post functie maken, waarbij je 9 vd 10 keer _get doorsluist naar de _post functie.

_COOKIE kan ik het nog begrijpen, maar je weet toch zelf wel waar je de value vandaan haalt...

En if ($_REQUEST['val'] == 'blaat') is korter dan: if ($_GET['val'] == "blaat" || $_POST['val'] == "blaat").

quote:

Op woensdag 6 augustus 2008 18:59 schreef slakkie het volgende:
Mja, _GET en _POST zijn nagenoeg hetzelfde, in JSP moet je ook een _get en een _post functie maken, waarbij je 9 vd 10 keer _get doorsluist naar de _post functie.

Daar gaat de illusie dat JSP professioneel is verschil GET/POST

quote:

Op woensdag 6 augustus 2008 18:59 schreef slakkie het volgende:

[..]

Mja, _GET en _POST zijn nagenoeg hetzelfde, in JSP moet je ook een _get en een _post functie maken, waarbij je 9 vd 10 keer _get doorsluist naar de _post functie.

_GET bevat alle variabelen die via de url (na het vraagteken) of via een formulier met method="get" worden meegezonden
_POST bevat alle variabelen die via een formulier met method="post" worden meegezonden. Da's niet hetzelfde.
Als je _REQUEST gebruikt kan ik een linkje bouwen dat hetzelfde doet als een formuliertje. Door dan iemand op dat linkje te laten klikken (klik hier om 1 miljoen euro te winnen), kunnen er dingen gebeuren die jij niet had voorzien. Het effect kan onbeduidend zijn maar ook tot gekkere dingen leiden.

quote:

_COOKIE kan ik het nog begrijpen, maar je weet toch zelf wel waar je de value vandaan haalt...

En if ($_REQUEST['val'] == 'blaat') is korter dan: if ($_GET['val'] == "blaat" || $_POST['val'] == "blaat").

Je moet dan ook of if('blaat' == $_GET['val']) of if('blaat' == $_POST['val']) gebruiken. En ja, ik heb de constante expres vooraan gezet in die vergelijkingen.

quote:

Op woensdag 6 augustus 2008 19:42 schreef Light het volgende:

[..]

_GET bevat alle variabelen die via de url (na het vraagteken) of via een formulier met method="get" worden meegezonden
_POST bevat alle variabelen die via een formulier met method="post" worden meegezonden. Da's niet hetzelfde.

Als je _REQUEST gebruikt kan ik een linkje bouwen dat hetzelfde doet als een formuliertje. Door dan iemand op dat linkje te laten klikken (klik hier om 1 miljoen euro te winnen), kunnen er dingen gebeuren die jij niet had voorzien. Het effect kan onbeduidend zijn maar ook tot gekkere dingen leiden.

_REQUEST geeft preference op _POST en niet op _GET, dus als jij data post en je zorgt dat de link ?val=bla bevat (om zo de data van _POST te overwriten) dan kom je bedrogen uit aangezien de _POST var voorrang heeft in de _REQUEST var. Dus waarom zou je dan in de problemen komen? Verder is het zo dat als je met _POST of _GET gaat werken dat je meer code moet kloppen (met debuggen gebruik je vaak een GET, en in live situaties ga je POST gebruiken). Jij moet voor deze twee gevallen extra code gaan kloppen terwijl ik alleen met _REQUEST gebruik en dus nergens m'n code hoef aan te passen.... Dus zowel met de GET als de POST kan ik op een generieke wijze overweg.

quote:

Je moet dan ook of if('blaat' == $_GET['val']) of if('blaat' == $_POST['val']) gebruiken. En ja, ik heb de constante expres vooraan gezet in die vergelijkingen.

Uhm, ik zie hier iemand _POST en _GET door elkaar gebruiken, en m.i. moet je een call kunnen maken met zowel POST als GET en hetzelfde resultaat krijgen. _REQUEST is gewoon makkelijker, aangezien je je niet druk hoeft te maken over hoe de variablen in je request terecht komen, via GET of POST.

Het boeit mij verder niet waar je de constante neerzet, zolang ie maar aan de juiste voorwaarde voldoet.

quote:

Op woensdag 6 augustus 2008 20:24 schreef slakkie het volgende:

[..]

_REQUEST geeft preference op _POST en niet op _GET, dus als jij data post en je zorgt dat de link ?val=bla bevat (om zo de data van _POST te overwriten) dan kom je bedrogen uit aangezien de _POST var voorrang heeft in de _REQUEST var. Dus waarom zou je dan in de problemen komen? Verder is het zo dat als je met _POST of _GET gaat werken dat je meer code moet kloppen (met debuggen gebruik je vaak een GET, en in live situaties ga je POST gebruiken). Jij moet voor deze twee gevallen extra code gaan kloppen terwijl ik alleen met _REQUEST gebruik en dus nergens m'n code hoef aan te passen.... Dus zowel met de GET als de POST kan ik op een generieke wijze overweg.

REQUEST bevat idd eerst GET en dan POST, als een variabele in beide geset wordt dan krijg je alleen de POST-waarde.
Het verwerken van formulierdata wil je meestal niet doen met variabelen die uit een GET komen. Voorbeeldje. Je hebt een formuliertje om dingen te verwijderen. Dat formuliertje gebruikt post en stuurt data (id=123) naar example.com/delete.php . In de verwerking wordt _REQUEST gebruikt.
Als ik dan iemand laat klikken op example.com/delete.php?id=123 ziet het formulier ook een id en wordt er dus ook iets verwijderd. En ja, het kan nog zo zijn dat voor die actie bepaalde rechten nodig zijn. Dan moet ik iemand met voldoende rechten op die link laten klikken. Da's niet zo moeilijk als het misschien lijkt.

Had je echter _POST gebruikt dan doet het klikken op het linkje niets, omdat er geen waarde via POST wordt verzonden. En ja, ik weet dat er meer manieren zijn en dat het ook mogelijk is om met bijvoorbeeld javascript een post-request uit te voeren. Maar je maakt het wel lastiger op die manier.
Ander voorbeeld. Stel je hebt een weblog waar bezoekers anoniem kunnen reageren. Dat gaat via een post-formuliertje. Iemand komt erachter dat het ook werkt als je de waardes in de url zet ipv via het formuliertje en zet die url op een forum ofzo. Gevolg, je krijgt 10.000 reacties van "anoniempje" met de tekst "slakkie is gek".

quote:

Uhm, ik zie hier iemand _POST en _GET door elkaar gebruiken, en m.i. moet je een call kunnen maken met zowel POST als GET en hetzelfde resultaat krijgen. _REQUEST is gewoon makkelijker, aangezien je je niet druk hoeft te maken over hoe de variablen in je request terecht komen, via GET of POST.

Ik kan me situaties voorstellen waarin een deel van de velden via _GET en een deel via _POST komt of waarbij je beide opties wilt kunnen gebruiken. Maar _REQUEST is niet de oplossing die ik wil prediken als juist in alle situaties. Het kan een oplossing zijn, maar dan moet het wel goed doordacht worden.

quote:

Het boeit mij verder niet waar je de constante neerzet, zolang ie maar aan de juiste voorwaarde voldoet.

True. Het grootste verschil is dat je meteen een dikke foutmelding om je oren krijgt als de constante eerst staat en je een = vergeet. Dat kan debugtijd schelen.

quote:

Op woensdag 6 augustus 2008 21:07 schreef Light het volgende:
REQUEST bevat idd eerst GET en dan POST, als een variabele in beide geset wordt dan krijg je alleen de POST-waarde.
Het verwerken van formulierdata wil je meestal niet doen met variabelen die uit een GET komen. Voorbeeldje. Je hebt een formuliertje om dingen te verwijderen. Dat formuliertje gebruikt post en stuurt data (id=123) naar example.com/delete.php . In de verwerking wordt _REQUEST gebruikt.
Als ik dan iemand laat klikken op example.com/delete.php?id=123 ziet het formulier ook een id en wordt er dus ook iets verwijderd. En ja, het kan nog zo zijn dat voor die actie bepaalde rechten nodig zijn. Dan moet ik iemand met voldoende rechten op die link laten klikken. Da's niet zo moeilijk als het misschien lijkt.

Had je echter _POST gebruikt dan doet het klikken op het linkje niets, omdat er geen waarde via POST wordt verzonden. En ja, ik weet dat er meer manieren zijn en dat het ook mogelijk is om met bijvoorbeeld javascript een post-request uit te voeren. Maar je maakt het wel lastiger op die manier.

Ander voorbeeld. Stel je hebt een weblog waar bezoekers anoniem kunnen reageren. Dat gaat via een post-formuliertje. Iemand komt erachter dat het ook werkt als je de waardes in de url zet ipv via het formuliertje en zet die url op een forum ofzo. Gevolg, je krijgt 10.000 reacties van "anoniempje" met de tekst "slakkie is gek".

Als je een delete.php form niet de GET accepteert maar in je code staat alleen dat het dmv POST opgestuurd wordt, dan klop je zelf wat stuut je een linkje op: http://opperschaap.net/ditwerktniet en zodra je daar op klikt wordt er een POST verzoek uitgevoerd naar example.com/delete.php met id=1234&hoedje=papier. Problem solved .

Kortom, als je vanwege security redenen iets niet GET zet maar in POST ben je enigsinds naief bezig. Je houdt misschien het beginnende lastpakje buiten de deur, maar anderen die iets meer verstand hebben kunnen die POST wel scripten en die proberen wel wat meer dan 10.000 keer zeggen dat ik gek ben (wat wel klopt overigens ).

Als je echt niet wilt dat bepaalde acties uitgevoerd worden dan ga je access toelaten op basis van IP adres (in Apache, of via je netwerk devices, etc), en zou je in de applicatie laag ook nog gebruik kunnen maken van ACL's (Xins is hier een voorbeeld van, daar kan je calls naar functies toelaten op basis van IP adresses, of je het nou via een GET of een POST uitvoert). En zo kan je van meer dingen gebruik maken om ervoor te zorgen dat er geen oneigenlijk gebruik wordt gemaakt van je systeem/applicatie.

quote:

Op woensdag 6 augustus 2008 22:03 schreef slakkie het volgende:

[..]

Als je een delete.php form niet de GET accepteert maar in je code staat alleen dat het dmv POST opgestuurd wordt, dan klop je zelf wat stuut je een linkje op: http://opperschaap.net/ditwerktniet en zodra je daar op klikt wordt er een POST verzoek uitgevoerd naar example.com/delete.php met id=1234&hoedje=papier. Problem solved .

Kortom, als je vanwege security redenen iets niet GET zet maar in POST ben je enigsinds naief bezig. Je houdt misschien het beginnende lastpakje buiten de deur, maar anderen die iets meer verstand hebben kunnen die POST wel scripten en die proberen wel wat meer dan 10.000 keer zeggen dat ik gek ben (wat wel klopt overigens ).

Als een browser iets kan, is het ook te scripten. Maar er zijn wel dingen om het lastiger te maken. En een post-request doen met een (server-side) script gaat vaak niet werken, omdat je niet over de juiste koekjes beschikt. Dus je moet het door een browser laten doen. Is ook best mogelijk met wat javascript, daar niet van.

quote:

Als je echt niet wilt dat bepaalde acties uitgevoerd worden dan ga je access toelaten op basis van IP adres (in Apache, of via je netwerk devices, etc), en zou je in de applicatie laag ook nog gebruik kunnen maken van ACL's (Xins is hier een voorbeeld van, daar kan je calls naar functies toelaten op basis van IP adresses, of je het nou via een GET of een POST uitvoert). En zo kan je van meer dingen gebruik maken om ervoor te zorgen dat er geen oneigenlijk gebruik wordt gemaakt van je systeem/applicatie.

Da's ook geen 100% garantie. Als ik een actie http://opperschaap.net/ditwerktniet wil laten uitvoeren zonder dat ik de rechten heb (lees: op het goede ip zit) dan moet ik zorgen dat ik iemand met de goede rechten op die link laat klikken. Dan kan ik jou wel een mail sturen met een blaatverhaal over die site en een link om aan te klikken. Als je dan half oplet en ziet dat die link naar http://example.org/ gaat dan is dat verdacht en klik je niet. Maar een link naar het goede domein valt minder op, dus is de kans dat je klikt groter.

Maar ik denk dat we het nooit helemaal eens zullen worden.

Dat denk ik ook

Los van het security issue. Bij een GET request moet je er *per definitie* van kunnen uitgaan, dat er niks zichtbaar wijzigt. Alleen met een POST operatie moet je records kunnen aanmaken, wijzigen, wissen etc. Dat is voor mensen niet zo belangrijk want wij zien het verschil nauwelijks, maar voor bijv webservices is het belangrijk. Die moeten ondubbelzinnig weten welke operatie iets aan de data van de webapplicatie verandert, en welke niet. En daar is het GET/POST onderscheid zeer bruikbaar voor.

Betekent dus dat je in je applicatiecode ook onderscheid moet maken tussen GET en POST, zodat een operatie die bedoeld is om gePOST te worden, nooit werkt dmv een GET request.

Het is een beetje de discussie tabellen vs divs+css: het werkt allebei en je kan met beide methodes alles wel voor elkaar krijgen, maar het is gewoon het beste om wel duidelijk onderscheid tussen GET en POST te maken. Het is absoluut essentieel als je bijv een RESTful webinterface maakt - sterker nog het is een van de hoekstenen van het RESTful principe. Niet zonder reden.

Als illustratie het vast wel bekende verhaal van iemand die een CMS had gebouwd, en daar alleen GET methodes in had gebruikt. Er werd een hele site ingezet, met veel data. Hij had er geen wachtwoord voorgezet, en het CMS werd op een gegeven moment gespiderd door Google. Gevolg: de hele site gewist. Want alle delete-knoppen waren gewoon linkjes met een GET querystring.

quote:

Op woensdag 6 augustus 2008 22:36 schreef Farenji het volgende:

Als illustratie het vast wel bekende verhaal van iemand die een CMS had gebouwd, en daar alleen GET methodes in had gebruikt. Er werd een hele site ingezet, met veel data. Hij had er geen wachtwoord voorgezet, en het CMS werd op een gegeven moment gespiderd door Google. Gevolg: de hele site gewist. Want alle delete-knoppen waren gewoon linkjes met een GET querystring.

Priceless
Wel een leuk trucje tegen vervelende klanten, als je een site handig opzet Als een spider langskomt ben je in zeer korte tijd zeer veel data kwijt, met die GETs.

quote:

Op woensdag 6 augustus 2008 22:36 schreef Farenji het volgende:
Als illustratie het vast wel bekende verhaal van iemand die een CMS had gebouwd, en daar alleen GET methodes in had gebruikt. Er werd een hele site ingezet, met veel data. Hij had er geen wachtwoord voorgezet, en het CMS werd op een gegeven moment gespiderd door Google. Gevolg: de hele site gewist. Want alle delete-knoppen waren gewoon linkjes met een GET querystring.

Whehehehe . (Je kan me hier opvegen .) Is natuurlijk wel het ubervoorbeeld hoe het niet moet .

quote:

Op donderdag 7 augustus 2008 09:15 schreef WyriHaximus het volgende:

[..]

Whehehehe . (Je kan me hier opvegen .) Is natuurlijk wel het ubervoorbeeld hoe het niet moet .

Tja je zal de mensen de kost moeten geven... en de eerlijkheid gebiedt me te zeggen dat ik zelf ook wel zulke fouten heb gemaakt - al was ik altijd wel zo slim om er een wachtwoord voor te plempen

quote:

Op donderdag 7 augustus 2008 16:18 schreef Farenji het volgende:

[..]

Tja je zal de mensen de kost moeten geven... en de eerlijkheid gebiedt me te zeggen dat ik zelf ook wel zulke fouten heb gemaakt - al was ik altijd wel zo slim om er een wachtwoord voor te plempen

Ik denk dat iedereen wel eens zo'n fout gemaakt heeft.

quote:

Op donderdag 7 augustus 2008 16:42 schreef Light het volgende:

[..]

Ik denk dat iedereen wel eens zo'n fout gemaakt heeft.

Echt niet Haha

Farenji, volgens de RFC heb je wel gelijk (alleen is het wel zo dat de RFC zegt dat een GET wel zaken mag aanpassen maar dat de gebruiker er niet verantwoordelijk voor gehouden kan worden). Tevens moet/behoort een GET cachable zijn, dus 2 calls naar delete.php?id=123 moet hetzelfde resultaat geven. Wat dus niet zal gebeuren als de GET ook geprocessed wordt.

quote:

Op donderdag 7 augustus 2008 16:42 schreef Light het volgende:

[..]

Ik denk dat iedereen wel eens zo'n fout gemaakt heeft.

Idd, vallen en opstaan, vallen en opstaan babe .

kan iemand me even helpen met een regexp?



Deze matcht goed tegen bijv test/id=22132
Maar als ik test/id=-22312 probeer, dan matcht ie weer niet..?

[ Bericht 0% gewijzigd door DionysuZ op 07-08-2008 19:40:46 ]

uhm ik heb het opgelost:



werkt dan weer wel. Kan iemand me vertellen waarom? :P

Het ligt aan het streepje, als je daarop wil matchen binnen een [ en een ] dan moet je hem altijd achteraan of helemaal vooraan zetten. Anders wordt ie echt als een range operator geinterpreteerd, blijkbaar zelfs als je hem escapet met een backslash (wat op zich best wel raar is).

Je vertelt niet wat precies de bedoeling is, en dat is meestal wel handig om te weten om te begrijpen of iets wel of niet "werkt". Welke tekens mogen er voorkomen in de string?
Je wil een streepje - gebruiken in een set, als die niet aan het begin of eind van de set staat, dan moet je die escapen met een backslash. Een set met letters, cijfers, streepje en gelijkteken wordt dan [a-z0-9\-=]. Deze set zet je in een string, daarbij moet je tekens als " en \ escapen met een backslash: "[a-z0-9\\-=]".

Is preg_match() niet sneller dan eregi()?