[php] Wat is de beste manier om een post te checken?

[RSD]

Er zijn tig manieren om te checken of iemand een formulier post in php. Maar wat is nu volgens jou de beste manier om dit te doen.

bijv:

code:

if ($_POST) {

}

of
(je stuurt een hidden check veld mee)

code:

if ($_POST["check"] =="1") {

}

Ik vroeg me af of er een beste manier is om dit te doen.

Zelf gebruik ik de eerste vaak!

[Alex)]

Ik kijk meestal zo:

PHP:

if(isset($_POST['een_willekeurig_form_field_hier']))
{
  // verzenden...
} else {
  // formulier tonen...
}

[sjroorda]

PHP:

if (isset($_POST) && is_array($_POST))
{
  // check 1
  // check 2
  // net zolang tot alle variabelen gecontroleerd zijn.
}

In ieder geval is isset() netter dan je eerste oplossing, en ook voor je tweede oplossing zou dat in principe beter zijn. Zet eens error_reporting(E_ALL), dan zie je ook al dit soort waarschuwingen!

[We Are Borg]

ik gebruik zelf REQUEST_METHOD, maar of het de beste is geen idee

[ Voor 35% gewijzigd door We Are Borg op 17-11-2005 20:35 ]

[CH4OS]

RSD schreef op donderdag 17 november 2005 @ 20:28:

code:

if ($_POST) {

}

of
(je stuurt een hidden check veld mee)

code:

if ($_POST["check"] =="1") {

}

Hidden form fields hebben mijns inziens niet veel nut. Pagina opslaan en je kan die waarde zo aanpassen naar wat anders en werkt je script niet meer... Ik zou (als ik eerlijk ben) niet op $_POST-variabelen controleren. Ik zou eerst alle gePOSTte variabelen omzetten naar een sessie-variabele en dan de sessie variabele aanpassen...

Mij hebben ze ooit geleert NOOIT de gePOSTte (oftewel de user) variabelen te vertrouwen, dus eerst omzetten naar een andere variabele (hoeft denk ik niet per se sessie te zijn, is (denk ik) wel makkelijker, bijvoorbeeld bij forms, kan je makkelijk die variabelen hergebruiken op punten waar de form wel goed ingevuld was )

* CH4OS dankt Superdeboer voor deze wijze en leerzame les

[ Voor 5% gewijzigd door CH4OS op 17-11-2005 20:47 ]

[Erkens]

GJ-tje schreef op donderdag 17 november 2005 @ 20:45:
[...]
Hidden form fields hebben mijns inziens niet veel nut. Pagina opslaan en je kan die waarde zo aanpassen naar wat anders en werkt je script niet meer... Ik zou (als ik eerlijk ben) niet op $_POST-variabelen controleren. Ik zou eerst alle gePOSTte variabelen omzetten naar een sessie-variabele en dan de sessie variabele aanpassen...

Waarom zou je dat doen? Beetje raar, om alles wat binnenkomt maar in een sessie te duwen, wat is daar concreet het nut van?

Mij hebben ze ooit geleert NOOIT de gePOSTte (oftewel de user) variabelen te vertrouwen,

alle input moet je niet vertrouwen (in principe ook de data uit je database )

dus eerst omzetten naar een andere variabele (hoeft denk ik niet per se sessie te zijn, is (denk ik) wel makkelijker, bijvoorbeeld bij forms, kan je makkelijk die variabelen hergebruiken op punten waar de form wel goed ingevuld was )

mja, dat heeft dus totaal weer geen nut, de gegevens in een andere variabele zetten maakt het niet meteen "veilig" als je over veilig mag spreken.
Sowieso is dat extra overbodig geheugen/cpu verbruik, wat je moet doen is als je zo'n waarde weer terug naar de user wilt sturen ervoor zorgen dat alle html goed blijft (bijvoorbeeld met htmlentities() ) en voor je database iets als mysql_real_escape_string() (als je mysql hebt).

[RupS]

GJ-tje schreef op donderdag 17 november 2005 @ 20:45:
[...]
Hidden form fields hebben mijns inziens niet veel nut. Pagina opslaan en je kan die waarde zo aanpassen naar wat anders en werkt je script niet meer... Ik zou (als ik eerlijk ben) niet op $_POST-variabelen controleren. Ik zou eerst alle gePOSTte variabelen omzetten naar een sessie-variabele en dan de sessie variabele aanpassen...

Mij hebben ze ooit geleert NOOIT de gePOSTte (oftewel de user) variabelen te vertrouwen, dus eerst omzetten naar een andere variabele (hoeft denk ik niet per se sessie te zijn, is (denk ik) wel makkelijker, bijvoorbeeld bij forms, kan je makkelijk die variabelen hergebruiken op punten waar de form wel goed ingevuld was )

* RupS dankt Superdeboer voor deze wijze en leerzame les

Het gaat er niet om of je de POST vars vertrouwd, je moet zorgen dat de checks die je daarop doet goed zijn. Het blijft user input, wat de user ook verstuurd, dat mag hij (m/v) helemaal zelf weten. Zolang jij je checks goed hebt kan er niets fout gaan (ik snap ook niet zo goed wat je bedoelt met "omzetten" ?)

Ikzelf gebruik eigenlijk ook altijd $_SERVER['REQUEST_METHOD'], omdat je dan niet hoeft na te denken over de vars die je hebt. Het werkt wat dat betreft altijd

[Brakkie]

Ik volg je echt niet geloof ik GJ-tje

Maareh

PHP:

if($_SERVER['REQUEST_METHOD'] == "POST") {
    //Doe je form acties
}
else {
    //Laat je form zien
}

Zou moeten werken.

[Erkens]

RupS schreef op donderdag 17 november 2005 @ 20:52:
Ikzelf gebruik eigenlijk ook altijd $_SERVER['REQUEST_METHOD'], omdat je dan niet hoeft na te denken over de vars die je hebt. Het werkt wat dat betreft altijd

owja, dat was de strekking van het topic.

Soms werk ik ook met die REQUEST_METHOD, maar alleen als het echt nodig is, en dat is bijna nooit.

Sowieso moet je alle velden checken, waarbij je er niet aan ontkomt om te kijken of bepaalde POST waarden wel gezet zijn, op die manier hoef je dan niet ook nog eens die extra check voor die REQUEST_METHOD te doen

[RSD]

ik gebruik:

PHP:

foreach ($_POST as $key=>$value){
    $_POST[$key] = trim(htmlspecialchars($value));
}

ook vaak om te checken is dat wat? Of moet er nog iets als addslashes bij?

Daar ben ik ook steeds nog niet uit wat het beste is. En ja het is afhankelijk van je server instelling... maar de meningen over het posten verschillen nogal volgens mij.

[ Voor 3% gewijzigd door RSD op 17-11-2005 20:59 ]

[RupS]

Erkens schreef op donderdag 17 november 2005 @ 20:55:
[...]

owja, dat was de strekking van het topic.

Soms werk ik ook met die REQUEST_METHOD, maar alleen als het echt nodig is, en dat is bijna nooit.

Sowieso moet je alle velden checken, waarbij je er niet aan ontkomt om te kijken of bepaalde POST waarden wel gezet zijn, op die manier hoef je dan niet ook nog eens die extra check voor die REQUEST_METHOD te doen

Eensch, dat sowieso, ik doelde alleen maar op het punt waarop je besluit tot de verwerking van de geposte data over te gaan
Zoals Brakkie dus doet

[CH4OS]

Erkens schreef op donderdag 17 november 2005 @ 20:50:
Waarom zou je dat doen? Beetje raar, om alles wat binnenkomt maar in een sessie te duwen, wat is daar concreet het nut van?

Het heeft niet echt veel nut, ik vind het zelf gewoon het makkelijkst om het zo te doen...

mja, dat heeft dus totaal weer geen nut, de gegevens in een andere variabele zetten maakt het niet meteen "veilig" als je over veilig mag spreken.

True, maar kan je je variabele wel weer aanpassen, kan anders ook wel natuurlijk, maar in mijn ogen voelt het gewoon veilger aan...

Sowieso is dat extra overbodig geheugen/cpu verbruik, wat je moet doen is als je zo'n waarde weer terug naar de user wilt sturen ervoor zorgen dat alle html goed blijft (bijvoorbeeld met htmlentities() ) en voor je database iets als mysql_real_escape_string() (als je mysql hebt).

Wat maakt het geheugen / CPU gebruik voor een programmeur / webdevver uit? Kan me niet echt voorstellen dat het veel geheugen kost om een variabele met tekst (neem aan dat het plain tekst is anders of een getal (wat nog minder geheugen is volgens mij)

alle input moet je niet vertrouwen (in principe ook de data uit je database )

Ben ik niet helemaal met je eens... Je kan wat je IN de database stopt immers 'manipuleren' of aanpassen, dus je kan (in zekere zin) wél je DB vertrouwen

RupS schreef op donderdag 17 november 2005 @ 20:52:
Het gaat er niet om of je de POST vars vertrouwd, je moet zorgen dat de checks die je daarop doet goed zijn. Het blijft user input, wat de user ook verstuurd, dat mag hij (m/v) helemaal zelf weten. Zolang jij je checks goed hebt kan er niets fout gaan (ik snap ook niet zo goed wat je bedoelt met "omzetten" ?)

Omzetten bedoel ik mee dat je je variabelen checkt en ombouwd om ellende te voorkomen, zoals bijvoorbeeld htmlentities doet

[ Voor 4% gewijzigd door CH4OS op 17-11-2005 21:03 ]

[YopY]

RSD schreef op donderdag 17 november 2005 @ 20:58:
ik gebruik:

PHP:

foreach ($_POST as $key=>$value){
    $_POST[$key] = trim(htmlspecialchars($value));
}

ook vaak om te checken is dat wat? Of moet er nog iets als addslashes bij?

Daar ben ik ook steeds nog niet uit wat het beste is. En ja het is afhankelijk van je server instelling... maar de meningen over het posten verschillen nogal volgens mij.

Ik doe persoonlijk ook nog strip_tags om eventuele HTML eruit te halen (indien dat niet toegestaan is). En addslashes() spreekt voor zich, zeker als de gegevens in een database komen te staan. PHP heeft wel een instelling (magic_quotes_gpc) om die slashes automatisch toe te voegen, maar het is ALTIJD beter om addslashes te doen - ga er nooit van uit dat die instelling op aan staat.

Edit: *leest verkeerd*.

"De Beste" methode in PHP is nogal discutabel, gezien het feit dat zoiets simpels als dit op duizend-en-een verschillende manieren kan. Het punt is, ze kunnen allemaal, alleen ze werken allemaal een beetje anders. Ik denk persoonlijk niet dat je een van de voorgenoemde methodes als "De Beste" kunt beschrijven, ze hebben allemaal hun voor- en nadelen.

[ Voor 19% gewijzigd door YopY op 17-11-2005 21:05 ]

[LauPro]

Soms kan het tijdelijk wegzetten van gePOSTte vars wel handig zijn, mocht je bijvoorbeeld bepaalde charsets moeten afhandelen, dan moet je het ruwe POST-spul omzetten naar een leesbaar geheel.

Daarbij kan wanneer de user gaat kloten of een firewall die checkt op content fatal error krijgen als je van bepaalde variabelen uit gaat. Maar wanneer je alles met isset checkt is er eigenlijk niets aan de hand, maarja als je een formulier hebt met 30 variabelen wordt dat weer een beetje eentonig.

[RSD]

'Maar welke volgorde dan... ik ben nu van alles aan het proberen, maar het is een beetje een chaos:

PHP:

if ($_SERVER["REQUEST_METHOD"]=="POST") {
   foreach ($_POST as $key=>$value){
       $_POST[$key] = addslashes(trim(htmlentities(strip_tags($value))));
   }                
}

en als ik het uit de database haal doe ik alleen stripslashes maar dit is een beetje een chaos...

[ Voor 5% gewijzigd door RSD op 17-11-2005 21:21 ]

[Erkens]

addslashes en removeslashes etc gebruik ik nooit, die doen bijna nooit wat je daadwerkelijk wilt.
Verder blijf ik van de ingevoerde data af en pas ik het enkel aan als ik het moet verwerken, dus niet alle quotes gaan escapen, maar pas op het moment dat het nodig is en dan alleen op de manier waarop het moet, htmlentites voor html output, mysql_escape_string voor data naar een mysql database

[RSD]

Maar goed, als je toch al die bewerkingen moet doen bij het ophalen van die page , kun je het toch het beste eenmalig doen bij het invoegen? (minder load op de server?)

[Erkens]

RSD schreef op donderdag 17 november 2005 @ 21:44:
Maar goed, als je toch al die bewerkingen moet doen bij het ophalen van die page , kun je het toch het beste eenmalig doen bij het invoegen? (minder load op de server?)

ehm, wat bedoel je?


$_POST['text'] bevat een tekstje wat de gebruiker heeft ingevuld.

Zodra ik deze wil opslaan naar de database gooi ik deze daar rechtstreeks heen dmv de mysql_escape_string() functie.
Als ik later deze waarde weer uitlees uit de database en naar mijn html output wil sturen gaat hij eerst langs htmlentities().
Nu kan je wel zeggen dat het handiger is om eerst htmlentities te doen en dan inserten in de database, echter dan moet je "veel" moeite doen als je later wilt dat de gebruiker het weer kan aanpassen, of als je het in een ander formaat zou willen.

[seamus21]

Ok in het geval van een form met een submit knop:

PHP:

if ($_POST['submit']) {} // name van submit veld

In het geval van een form zonder submit knop:

PHP:

if ($_POST['naam']) {} // willekeurig form var

Zoals al eerder aangegeven als je mogelijkheden creeert voor input, bijvoorbeeld via een form, moet je deze input niet vertrouwen. En dus waar nodig geacht goede controles inbouwen. Al naar gelang de risico's die je kunt bedenken als er iets misgaat maak je de controles uitgebreider en laat je misschien wat mooie functies op de data los voordat je dit in een databse plaatst of weer weergeeft op bijvoorbeeld een website.

Vertrouw geen input en probeer zelf in te schatten welke controles je op de data loslaat voordat je het wel vertrouwt.

[ Voor 7% gewijzigd door seamus21 op 18-11-2005 00:13 ]

[Erkens]

seamus21 schreef op vrijdag 18 november 2005 @ 00:12:
Ok in het geval van een form met een submit knop:

PHP:

if ($_POST['submit']) {} // name van submit veld

ik zou het niet zo doen, niet alle browsers geven die knop mee als het formulier niet via een klik op die knop is verstuurd, bijvoorbeeld dmv "enter"

[Verwijderd]

ik doe het meestal zo

PHP:

$var = (isset($_POST['var'])) ? $_POST['var'] : null;

[ Voor 22% gewijzigd door Verwijderd op 18-11-2005 00:25 ]

[crisp]

Erkens schreef op vrijdag 18 november 2005 @ 00:16:
[...]

ik zou het niet zo doen, niet alle browsers geven die knop mee als het formulier niet via een klik op die knop is verstuurd, bijvoorbeeld dmv "enter"

idd, plus dat je de javascript submit() method onbruikbaar maakt als je een formveld name="submit" geeft

Ik durf dus wel te stellen dat dat de slechtste methode is

[ Voor 9% gewijzigd door crisp op 18-11-2005 00:26 ]

[ShadowLord]

Ik stop met het systeem waar ik nu aan werk altijd een hidden var in m'n forms om ook de 'state' van het geheel bij te houden of wat voor actie de gebruiker wilt nemen. (Ik gebruik dus geen sessies omdat daar ook weer genoeg haken & ogen aan zitten). Ik heb dus standaard al een waarde waarop ik kan checken. M'n formafhandeling gaat meestal ongeveer zo:

PHP:

if (!empty($_POST["actie"]))
{
    switch ($_POST["actie"])
    {
    case "lees":
        if(isset($_POST["id"]) && $_POST["id"] > 0))
        {
            print("Hier haal ik wat data op aan de hand van 'id'");
        }
        else
        {
            print("Fout: ontberekende ID. De fout is gelogged.");
            $db->logerror(); // Iets complexer dan dit met wat meer info, maar je snapt um wel
        }
        break;

    case "schrijf":
        /* Zelfde idee als bij lees, maar dan met checks op de te schrijven vars. */
        /* Overigens log ik hier niet elke fout: users vergeten wel eens forms helemaal in te vullen :+ */
        break;

    default:
        print("Inbraak poging gedetecteerd. Je gegevens zijn opgeslagen.");
        $db->logerror(); // Ook weer wat complexer, met meer info in de func call
    }
}

Natuurlijk ga ik niet op iedere fout in. Maar het helpt je systeem te debuggen, want ergens een ID vergeten ofzo kan makkelijk en dat zie je gelijk terug. En als iemand je systeem probeert te hacken zie je dat ook terug (het verschil in echte fouten en hackpogingen is meestal vrij duidelijk).

[Andre-85]

Erkens schreef op donderdag 17 november 2005 @ 22:37:
[...]

ehm, wat bedoel je?


$_POST['text'] bevat een tekstje wat de gebruiker heeft ingevuld.

Zodra ik deze wil opslaan naar de database gooi ik deze daar rechtstreeks heen dmv de mysql_escape_string() functie.
Als ik later deze waarde weer uitlees uit de database en naar mijn html output wil sturen gaat hij eerst langs htmlentities().
Nu kan je wel zeggen dat het handiger is om eerst htmlentities te doen en dan inserten in de database, echter dan moet je "veel" moeite doen als je later wilt dat de gebruiker het weer kan aanpassen, of als je het in een ander formaat zou willen.

offtopic:
Hoe verwijder je de slashes van mysql_escape_string() dan weer? Op php.net kan ik geen mysql_unescape_string() functie oid vinden.

[Erkens]

Andre-85 schreef op vrijdag 18 november 2005 @ 10:44:
[...]

offtopic:
Hoe verwijder je de slashes van mysql_escape_string() dan weer? Op php.net kan ik geen mysql_unescape_string() functie oid vinden.

Dat hoeft ook helemaal niet
Je moet het enkel escapen zodat mysql de data goed aangeleverd krijgt, je krijgt vervolgens de data weer terug zoals je die had voordat je het door die functie heen haalde. Zoek anders eens het nut/doel op van escapen

[seamus21]

crisp schreef op vrijdag 18 november 2005 @ 00:25:
[...]

idd, plus dat je de javascript submit() method onbruikbaar maakt als je een formveld name="submit" geeft

Ik durf dus wel te stellen dat dat de slechtste methode is

Ik denk dat we juist door alle genoemde punten kunnen concluderen dat er geen beste of slechste methode is maar dat het zoals altijd weer afhangt van de situatie waarin je het gebruikt.

[LauPro]

ShadowLord schreef op vrijdag 18 november 2005 @ 10:09:
Natuurlijk ga ik niet op iedere fout in. Maar het helpt je systeem te debuggen, want ergens een ID vergeten ofzo kan makkelijk en dat zie je gelijk terug. En als iemand je systeem probeert te hacken zie je dat ook terug (het verschil in echte fouten en hackpogingen is meestal vrij duidelijk).

Jij gaat dus helemaal volgespammed worden als een user loopt te kloten of dat een firewall met HTML-scanengine je HTML verbeukt (Norton anyone?). Log je bij de error ook datgene is gepost en de HTML die eerder is verstuurd (lijkt me lastig). Het lijkt me verstandig om elke actie als een geheel te zien, daar zijn een aantal velden gewoon verplicht, heb je die niet geef je een dikke error want dan heeft iemand met het formulier lopen spelen.

[Erkens]

seamus21 schreef op vrijdag 18 november 2005 @ 11:29:
Ik denk dat we juist door alle genoemde punten kunnen concluderen dat er geen beste of slechste methode is maar dat het zoals altijd weer afhangt van de situatie waarin je het gebruikt.

Het is gewoon fout om een element de naam "submit" te geven

[seamus21]

Erkens schreef op vrijdag 18 november 2005 @ 11:56:
[...]

Het is gewoon fout om een element de naam "submit" te geven

Ja want gelukkig dekt submit niet de lading van wat je aan het doen bent

Afgezien van die javascript onsubmit, wat dus situatieafhankelijk is, of je dat nodig hebt zie ik niet echt waarom het nou zo evil is

[T-MOB]

seamus21 schreef op vrijdag 18 november 2005 @ 12:20:
[...]
Ja want gelukkig dekt submit niet de lading van wat je aan het doen bent

Het dekt helemaal geen lading... elk formulier wordt namelijk gesubmit. Je kunt beter aangeven wat er gesubmit wordt.

[Erkens]

seamus21 schreef op vrijdag 18 november 2005 @ 12:20:
Ja want gelukkig dekt submit niet de lading van wat je aan het doen bent

imo dekt 'submit' niet de lading, 'submitbutton' wel

Afgezien van die javascript onsubmit, wat dus situatieafhankelijk is, of je dat nodig hebt zie ik niet echt waarom het nou zo evil is

je komt jezelf vroeg of laat nog wel tegen dan wanneer je uren lang aan het zoeken bent waarom het formulier niet werkt zoals je verwacht

[Verwijderd]

Werk zelf altijd met constructies als deze;

PHP:

// init
$rm = strtolower($_SERVER['REQUEST_METHOD']);

// no post data received
if($rm!='post'){
    // part one

} else
if($rm=='post') {
    if(!isset($_POST['showpartthree'])) {
        // part two
    
    } else
    if(isset($_POST['showpartthree'])) {
        // part three
    
    }
    // etc.

}

Werkt i.m.o. uitstekend, en om op het (offtopic?) submit-verhaaltje in te gaan; je kunt met zowel een submitbutton- als de javascript method submit() werken. Zorg wel dat je het eerst genoemde element nooit de naam `submit` geeft. Dit neemt functionaliteit weg, zoals Crisp eerder meld, en of jij als programmeur dat nou interessant vindt of niet, het lijkt me niet de bedoeling

[mosymuis]

Erkens schreef op donderdag 17 november 2005 @ 20:50:
alle input moet je niet vertrouwen (in principe ook de data uit je database )

Ik beschouw alle gegevens in mijn database als veilig. Alle controle zou al moeten zijn toegepast voordat user input werd ingevoegd. Het enige controlemiddel wat er bij de weergave van data bij mij nog overheen gaat zijn HTML functies, omdat ik er niet van hou entities etc. al toe te passen voor het de DB in gaat. Je weet nooit hoe je de gegevens later zou kunnen verwerken.

Wat betreft de topicvraag: ik werk zoals ferenc hierboven. Ik neem alle variabelen aan, verwerk ze met controlefuncties en plaats ze buiten de $_POST array, en bekijk vervolgens of de variabelen gevuld zijn en dus verstuurd met het formulier.

[Verwijderd]

Doe mij inderdaad maar de:

PHP:

if ($_SERVER['REQUEST_METHOD'] == "POST") {
  [...]
}

Werkt tot nog toe altijd!

[ Voor 15% gewijzigd door Verwijderd op 18-11-2005 14:51 ]

[NMe]

Verwijderd schreef op vrijdag 18 november 2005 @ 13:54:
Werk zelf altijd met constructies als deze;

PHP:

// init
$rm = strtolower($_SERVER['REQUEST_METHOD']);

// no post data received
if($rm!='post'){
    // part one

} else
if($rm=='post') {

Ho even. Welke waarde dacht je zelf dat $rm überhaupt nog kàn hebben op deze laatste regel? Waar is die laatste if goed voor?
Verder is het controleren van de REQUEST_METHOD een goeie manier om te kijken òf er gepost is, maar daarna moet je nog gaan kijken of de individuele onderdelen van de $_POST-array wel gevuld zijn. Ik gebruik zelf dus altijd beide methoden.

[seamus21]

imo dekt 'submit' niet de lading, 'submitbutton' wel

Submit of submitbutton ik vind het een beetje mierenneuken. Je bent er toch zelf bij als je zo progged. Natuurlijk moet je goede benaming hanteren als je progreammeert maar ook naamgeving is persoonsgebonden.

je komt jezelf vroeg of laat nog wel tegen dan wanneer je uren lang aan het zoeken bent waarom het formulier niet werkt zoals je verwacht

Ik prog gelukkig al lang genoeg om te weten wat ik van een formulier kan verwachten... Blijf er bij dat de meeste manieren dus persoons en situatiegebonden zijn...