Tijden veranderen
$_SERVER['REQUEST_METHOD'], altijd 1 method?
Code (php)
Op deze manier heb je al je variabelen altijd in dezelfde variabele (in dit geval $the_request) zitten.
Nu lijkt mij dit eigenlijk ook wel handig om te doen... maar ik zit me af te vragen of het mogelijk is dat je een POST en GET method tegelijk hebt. Bijvoorbeeld als je action in een formulier een GET parameter bevat: <form action="http://www.mijnsite.nl/inloggen?formulier=inloggen" method="post">
Hier heb je zowel een POST als GET method lijkt mij, of wordt die GET hier genegeerd?
(ik zag dat de $_SERVER['REQUEST_METHOD'] ook HEAD of PUT kan zijn. Iemand een idee wat dat inhoudt?)
Als je hier method=get van maakt.. krijg je &veldnaam=veldwaarde.
Maar wat gebeurt er nu dan met "formulier=inloggen"? Waar blijft dat?
$_REQUEST
Dat haalt zijn informatie uit $_GET, $_POST of $_COOKIE.
Mij lijkt het vooral niet interessant om dit te doen.
Als ik een $_REQUEST krijg, zou ik direct willen weten waar de informatie van komt.
POST en GET gebruik je namelijk om andere redenen.
"POST en GET gebruik je namelijk om andere redenen."
Wat bedoel je hiermee?
(even ander vraagje, als ik een variabele unset die niet bestaat kan dit dan kwaad?)
Een Post request kan gewoon Get variabelen hebben (andersom niet)
Code (php)
Want dat worden de POST variabelen in $the_request gestopt, maar de GET variabelen niet. Script klopt dus niet?
De praktische bezwaren die je zelf aanhaalt, lijken me goede redenen om dit niet te doen.
PS zijn er meer mensen die ineens geen mail meer ontvangen van PHPhulp? Of ligt mijn mailprovider te kloten?
(even ander vraagje, als ik een variabele unset die niet bestaat kan dit dan kwaad?)
Ozzie PHP op 10/01/2011 17:43:30:
(even ander vraagje, als ik een variabele unset die niet bestaat kan dit dan kwaad?)
Ja, je krijgt eerst een bekeuring en daarna doet je muis het niet meer.
over de email's van PHPHulp,
had ik ook opeens, bleek dat het naar spam werd gestuurd,
heb dus maar even een filter erop gezet dat hij dat dus niet meer doet :P
en over unset,
voor zover ik weet kan dit geen kwaad nee.
- SanThe - op 10/01/2011 17:50:24:
Gotver... vandaar dat mn muis het telkens niet meer doet!!!Ja, je krijgt eerst een bekeuring en daarna doet je muis het niet meer.
Ik bedoelde natuurlijk in de vorm van warnings of iets dergelijks. Omdat je iets unset wat niet bestaat, snappie?
"Ik snap niet waarom je niet gewoon $_POST en $_GET gebruikt, lijkt me toch logischer"
Mja, dat zal ik dan maar doen... het leek me wel geinig om dat via die switch te doen, maar als dat niet werkt dan houdt het op.
"over de email's van PHPHulp,
had ik ook opeens, bleek dat het naar spam werd gestuurd,
heb dus maar even een filter erop gezet dat hij dat dus niet meer doet :P"
Bij mij komt er niks meer aan, ook niet in de spam :-|
Ozzie PHP op 10/01/2011 18:01:11:
Ik bedoelde natuurlijk in de vorm van warnings of iets dergelijks. Omdat je iets unset wat niet bestaat, snappie?
Als je iets unset wat niet bestaat dan is het logisch dat je een notice krijgt lijkt mij.
Ozzie PHP op 10/01/2011 18:20:40:
naja zeg... dat was dus mijn vraag, en eerder zeg jij dat er niks aan de hand is :|
Waar heb ik dat gezegd?
of
Maar de vraag is nu dus of ik wel of niet moet checken of ie bestaat? Of zeg jij dat ik m uberhaupt niet moet unsetten?
het maakt niet uit,
$_COOKIE['id'] blijft z'n eigen waarde houden,
idem voor $_POST en $_GET
volgensmij staat de $_REQUEST variabele in deze volgorde: EGPCS
wat staat voor Environment, Get, Post, Cookie, en Server,
dus het kan heel goed voorkomen dat als je $_REQUEST['id'] gebruikt,
dat dat dan de waarde van $_COOKIE['id'] returnt, terwijl je die van $_GET wou hebben,
daarom kun je hier niet op vertrouwen,
stel je voor dat iemand het lukt om een cookie aan te maken, met weet ik veel wat,
Javascript injection oid...
dit kan slecht aflopen ;)
maar het is niet zo dat omdat $_REQUEST onveilig is, dat de rest ook gelijk onveilig is, dus je hoeft niet persee $_REQUEST te unsetten.
Please, correct me if i'm wrong...