Mag het ietsje minder zijn?

Goeie shit: extract($_POST);

die wist ik niet! leuke tutorial beetje kort maar voor mij effectief (Y)

Ik zal meer toevoegen over time, bijvoorbeeld een simpele lijst genereren zonder gedoe, mailen zonder gedoe en validatie zonder gedoe

Ziet er goed uit, en dat van extract wist ik ook niet, iig niet dat het bij post ook kan ^^

Intressante tut!

ik mis nog wel een klein deeltje wat je kan gebruiken in php.. Classes (of functions).. Hiermee kan je een script waarin je steeds iets herhaalt makkelijker aanroepen en wordt er ook een stuk makkelijker door

Goeie tutorial, alleen het nadeel van dat extract dat als ik doe:



En iemand zet ?wortel=11 in de url, dat dan mijn variabele opnieuw wordt geset, dus is het wel korter maar niet veiliger.

Wow!
\me heb nog nooit gehoord van dat extract! :)

Toch wat puntjes van kritiek:



Maar hoe weet je nu nog waar $naam vandaan komt? In grotere scripts wordt dit erg verwarrend.



Dit riekt een beetje naar "misbruik" van deze functie, het werkt natuurlijk wel maar het is niet de bedoeling dat die functie te pas en te onpas wordt gebruikt om verschillende bestanden te schrijven, de functie is bedoelt voor het loggen van errors, zoals de naam ook impliceert. Wederom; in grotere scripts waar je met meerdere personen aan werkt kan dit knap verwarrend zijn.

Verder heeft het niet veel weg van een tutorial maar meer wat handige tips :)

Als beginner kan je hier je helemaal lens naar zoeken. Ik geef ook aan dat het niet altijd de beste methodes zijn, maar het geeft wel een boel duidelijkheid.

error_log kan er wel niet voor bedoeld zijn, maar tis net als fietsen over een stoep, tgaat prima en werkt net zo goed.

hoe je weet waar $naam nu vandaag komt? Dit moet je hoe dan ook anders toch defineren, whats the difference.

@deadaluz, ik gebruik extract dan ook puur voor POST, met GET krijg je idd tricky stuff erin.

met dat extract, kan je er dan meteen ook htmlentities overheen gooien bijvoorbeeld? Of resulteert dat in een rits foutmeldingen? Kan het nu even niet zelf testen :)

Dat je zoiets krijgt:

extract(htmlentities($_POST));

probeer het ff voor je :)

edit: niet op die manier, want dan is $_POST uiteraard nog een array, andersom werkt het wel



gaat prima!

Kijk eens aan, heel tof! Bedankt voor het testen :o) Gaat mij een hoop schelen ;o)

BTW leuke tutorial. Wist de meeste dingen nog niet eens!

kijk , kan het wel kort zijn (vind ik ook /schaam) , maar wel krachtig :)

Ik vind het van error_log echt niet kunnen. Dat is naar mijn mening vele malen erger dan beginners leren variabelen binnen quotes te zetten en mysql_fetch_object te gebruiken en isset bij elkaar! Maar dat is mijn mening.

Waarom denk je trouwens dat register_globals standaard uit staat? Veiligheidsredenen! En met extract maak je dat weer ongedaan. Maar kijk even hier, dan zie je dat extract() 3 parameters aankan. Laat er nu net een constante EXTR_SKIP bestaan! Whee! Nu overschrijft hij geen bestaande variabelen meer, veiligheidsprobleem opgelost!



Ow, en let wel op dat extract niet hetzelfde doet als register_globals. De 'uitvoer' van extract (geen echte uitvoer, maar daar kom ik zo op terug) is gebonden aan standaard scopes net als andere normale variabelen. Het zijn dus geen superglobals.

En dat htmlentities(extract($_POST)) werkt betwijfel ik sterk. Extract geeft namelijk een integer (aantal goed ge?mporteerde waarden) terug als return-waarde. Die wordt dus door htmlentities getrokken. Niet de variabelen.

getest jelmer, anders probeer je het zelf nog even, kan je het zelf zien :)

ik probeer niemand hier iets aan te leren wat goed of fout is. Laat dat even duidelijk zijn. Ik wil beginnende coders laten zien dat er meerdere wegen naar rome leiden. Iemand die niet weet hoe je een map uitleest voor inhoud gaat op internet een boel tegenkomen wat hij niet begrijpt. Zo is het duidelijk en hier kan je weer op verder bouwen. Ken je het principe van wat hier staat , kijk dan naar de meer gevorderde scripts. Het is eigenlijk gewoon een soort springplank voor mensen die vastzitten.

Waarom zou je extract doen? Je slaat ??n variabel alleen maar twee keer op en de bron van de variabel is onduidelijk. Als je het houdt bij $_POST['naam'] weet je in ieder geval dat het uit een formulier moet komen.

Weet niet of onderstaande al genoemd is:
Error_log is eigenlijk bedoeld voor het schrijven naar de fout log van de server/php. Deze functie is echter uitgebreid met dat je je eigen log file en e-mail kan opgeven. Maar de bedoeling is anders.

htmlentities(extract($_GET, EXTR_SKIP), ENT_QUOTES);

werkt hier niet tbh ...

nu een mooi scriptje erom heen bouwen zodat ie het automatisch doet, als ik een keer zin en tijd heb zal ik er een classje van maken ;)

Jij zegt:
Nu heb je de hele boel wat gepost is, in bijhorende variabele staan. Dus $_POST['naam'] wordt automatisch $naam. Kind kan de was doen.

En als de variabele $naam al bestaat?

Edit: ik zie dat hier wat over gezegd is :-)

wes : GEWELDIG en chapeau hoor!!! Zoals ik zelf van je gewend ben om feedback te krijgen is ook dit voor de beginner zeer helder en duidelijk en bovenal zeer overzichtelijk!! Bedankt voor het delen en voor de moeite die je hebt genomen om dit allemaal in te typen :-)

Regeltjes als '$_POST['naam'] wordt automatisch $naam' huiveren mij enorm op gebied van beveiliging.

Wat als mensen/hackers formulier velden toevoegen en die de namen hebben van veel gebruikte variabelen.. bijvoorbeeld een formulierveld met de naam 'sql', 'query', 'user_id'. Essentiele variabelen zijn niet meer betrouwbaar.. als je commando's als extract gebruikt moet je heel goed weten wat je doet..

Maar buiten enkele beveiligheids issues zijn vele tips inderdaad hele goede tips! Nice!

Mijns inziens zou je extract() alleen mogen gebruiken in prefix-mode:

extract($_POST, EXTR_PREFIX_ALL, 'abcd');

$_POST['naam'] wordt dan $abcd_naam, en als je ervoor zorgt dat geen enkele "normale" variabele met abcd_ begint, zit je redelijk safe.

In een eerdere reactie werd gezegd dat EXTR_SKIP de magische functie is die alle veiligheidsproblemen oplost, maar daar ben ik het niet mee eens.

Stel dat ergens in je code iets staat als:

if($username == goed && $password == goed) { $ingelogd = 1; }
extract($_GET, EXTR_SKIP);
if(isset($ingelogd)) { /* code */ }

Door nu in je URL een parameter &ingelogd=1 op te nemen, kun je dus zonder geldig userid en password-combinatie toch "inloggen". De extract() heeft echter geen bestaande variabele overschreven.

Nou is dit niet de beste manier om een inlogsysteem te programmeren, maar het gaat even om het globale idee. Met een EXTR_PREFIX_ALL en een goed gekozen prefix ben je naar mijn mening een stuk veiliger bezig.

Ik vind het alleen maar een goede les voor jezelf. Als je extract en namen als sql en query gaat gebruiken als inputnamen, dan ligt de fout al bij jezelf. Zelfde met dubbele variabelen. dat mag sowieso niet voorkomen, dus waarom zou je nu ineens 2 dingen hetzelfde gaan noemen?

Ik kan (als client) zelf ook allerlei variabelen in mijn request stoppen (met GET iets gemakkelijker dan met POST). De inhoud van request-variabelen moet je dan ook altijd wantrouwen. Je kan zelf wel "goede" namen gebruiken als input-variabelen, maar de client kan er altijd iets bij zetten. En als dat toevallig een variabele is die in je script wordt gebruikt, ga je nat. Door met een prefix te werken, ben je je er altijd van bewust dat je met potentieel onveilige data werkt.

zal binnenkort nog een mooi script posten om al jullie gezeur te stoppen ok?
fijn dank

Toevoeging:
i.p.v.:

gewoon:

@Andries:

Die shorttags staan bij sommige providers uit en kunnen problemen geven als je ook met XML gaat werken. Zou ik dus niet aanbevelen. Is nu misschien sneller, maar kan in de toekomst een boel werk opleveren.

Mitch heeft ooit de functie glob() geschreven, voor mensen die deze willen lezen: http://www.phphulp.nl/php/tutorials/4/253/

Zeker wanneer je templates gebruikt, kan het voorkomen dat iemand anders de html maakt. En wanneer deze persoon de name="naam" gebruikt, wordt zonder enige controle jouw reeds gedefinieerde $naam overschreven! En doordat dit geheel automatisch gebeurd, is dit een hele geniepige bug.

En omdat je toch per formulierveld moet controleren of de inhoud wel correct is, is het een kleine moeite om pas na de controle $_POST['naam'] om te zetten naar $sNaam. Hierbij de 's' voor een string, dan weet je ook wat er in deze variabele staat. $iNummer is dus een integer en $aHobby is een array.

extract heb je niet nodig.

Het gebruik van de error_log() functie is zeer lelijk. Dit is gewoon puur misbruik maken van de functie. Dan kun je beter zelf een functie writeFile() maken met 2 parameters (file, data).

En extract() zou ik ook niet zo blij mee zijn om die te gebruiken. 't geeft beveiligings risco's zoals hierboven al beschreven.

raad ik NIET aan om te gebruiken!
komt op het zelfde neer als register_globals, en dat staat standaard uit, vanwege beveiligingslekken!

ook met post is dit niet veilig, want post waarden is misschien iets moeilijker, maar nog steeds maar een formuliertje maken en klaar;)

beveiliging is toch wel belangrijkste van een applicatie, het kan nog zo goed werken, maar als je er dingen mee kan doen die je er niet mee hoort te doen, dan loopt je hele server gevaar;)

~huib

en $_request dan heb je ze allebei