[PHP] addslashes magic_quotes_gpc etc.

[BasieP]

Heren,

Ik heb al een tijd lang een aantal websites draaien, en maak daarbij gebruik van het setten van magic quotes.
Dit doe ik door set_magic_quotes_runtime() functie in PHP. Echter nu heb ik een nieuwe wamp op mijn flaptop gegooit, en daar zit een nieuwe PHP bij. Ik zag daar dat de functie 'set_magic_quotes_runtime()' deprecated was.

Nu heb ik dus een berg code die ik voor de toekomst weer 'safe' wil maken. (sql injectie proof).

Ik kan natuurlijk checken of magic quotes aan staat en aan de hand daarvan bij elke get/post var wel of niet addslashes() doen, maar dit is nogal wat werk.

Is er een manier om op een nette en veilige manier magic quotes te setten? Het moet echter zowel bij mij lokaal, maar ook op verschillende hosting providers werken.

Zelf dacht ik nog aan een functie zoals bijvoorbeeld hieronder:

PHP:

function getPostVar($name) {
  if (!get_magic_quotes_gpc())
    return addslashes($_POST[$name]);
  else
    return $_POST[$name];
}

[ Voor 4% gewijzigd door BasieP op 25-09-2009 13:38 ]

[MueR]

Je moet dan ook niet vertrouwen op magic functions. Die zijn eerder gevaarlijk dan nuttig. Er zijn genoeg alternatieven, zoals bijvoorbeeld argumenten escapen via de mysql_real_escape familie.

edit:
:W Erkens, :W NMe

[ Voor 42% gewijzigd door MueR op 25-09-2009 14:02 ]

[Erkens]

Nu heb ik dus een berg code die ik voor de toekomst weer 'safe' wil maken. (sql injectie proof).

Dan zit je met addslashes en/of magic_quotes toch al verkeerd. De enige keer dat je moet escapen is het moment dat je de query naar je database gaat uitvoeren, voor de rest is het niet nodig.
Voor mysql gebruik je dan de functie mysql_real_escape_string.

[NMe]

Magic quotes wordt compleet uit PHP gesloopt in PHP 6 en ervan afhankelijk zijn is naast dom ook nog eens helemaal achterhaald. Sowieso zijn er betere manieren dan addslashes om je strings te escapen.

Oh, mocht het niet duidelijk zijn: het enige wat je met magic quotes moet doen is ze uitzetten!

Dank u.

[BasieP]

mm duidelijk

toch maar eens een connection manager bouwen dan....

[DexterDee]

Als je de mysqli extensie kunt gebruiken dan kun je overwegen om met prepared statements te werken:

PHP:

$db = new mysqli($host,$user,$passwd,$dbname);
$statement = $mysqli->prepare("SELECT username FROM users WHERE user_id=? AND password=?");
$statement->bind_param("ss", $_GET['username'], md5($_GET['password']));
$statement->execute();

Doordat de SQL query al geprepareerd wordt, kunnen de vraagtekens alleen nog maar als parameters gebruikt worden en kunnen geen onderdeel meer worden van de query zelf. Hiermee sluit je dus effectief sql injection uit.

Of je zoekt een framework voor DataObjects (Pear:DB:DataObjects, e.a.) of ORM (Propel, e.a.) waar dit al voor je geregeld is

[dik_voormekaar]

Gewoon zo toch ?

PHP:

function getPostVar($name) { 
    return mysql_real_escape_string($_POST[$name]); 
}

[Voutloos]

Nee, je moet bij je juiste context op de juiste manier escapen. Dergelijke functies zijn net zo stupide als magic quotes was.

Je moet dus alles escapen en daar heb je niet met Post data te maken. Bovendien is het overal en nergens de global input arrays erbij pakken ook een gruwelijke code smell.

[ Voor 41% gewijzigd door Voutloos op 25-09-2009 18:48 ]

[NMe]

Het grootste probleem met die functie is dat je nu gewoon alsnog overal alles dat je uit user input krijgt gaat escapen terwijl je dat lang niet altijd en overal nodig hebt.

[Verwijderd]

Ik werk nu met sprintf en mysql_real_escape_string omdat ik die mysqli volgens mij niet kan gebruiken.

PHP:

$sQuery = "SELECT blah FROM mekker WHERE q='%s'";
$sQuery = sprintf($sQuery,mysql_real_escape_string($_POST['w00t']));

Ik geef de mogelijkheid ter overweging.

[Cyphax]

En pdo? Daarmee kan je ook prepared statements gebruiken. Stukken beter dan sql-queries opbouwen als string, dan zelf vanalles gaan lopen escapen (waarbij je kans loopt wat te vergeten, of gaat overdrijven, of iets anders over het hoofd ziet). Pdo zit volgens php.net bij php sinds 5.1 en anders is het vrij makkelijk te installeren (waarbij ik er vanuit ga dat een provider up-to-date genoeg is om 5.1 te draaien nu 5.2 al lang en breed stable is).

http://ilia.ws/archives/1...-Prepared-Statements.html
Niet klooien met strings die je moet escapen als het niet hoeft.

[Eijkb]

Indien je geen zin hebt hele scripts door te lopen kan je bv. ook iets doen als:

code:

foreach($_POST as $key => $var) {
$_POST[$key] = mysql_real_escape_string($var);
}

Zal voor de puristen not done zijn, bij oude scripts wellicht een oplossing.

[BasieP]

Eijkb schreef op vrijdag 25 september 2009 @ 20:46:
Indien je geen zin hebt hele scripts door te lopen kan je bv. ook iets doen als:

code:

foreach($_POST as $key => $var) {
$_POST[$key] = mysql_real_escape_string($var);
}

Zal voor de puristen not done zijn, bij oude scripts wellicht een oplossing.

Ik zag op internet inderdaad dit soort dingen staan:

PHP:

$_GET = array_map('trim', $_GET);
$_POST = array_map('trim', $_POST);
$_COOKIE = array_map('trim', $_COOKIE);
$_REQUEST = array_map('trim', $_REQUEST);
if (get_magic_quotes_gpc()) {
    $_GET = array_map('stripslashes', $_GET);
    $_POST = array_map('stripslashes', $_POST);
    $_COOKIE = array_map('stripslashes', $_COOKIE);
    $_REQUEST = array_map('stripslashes', $_REQUEST);
}
$_GET = array_map('mysql_real_escape_string', $_GET);
$_POST = array_map('mysql_real_escape_string', $_POST);
$_COOKIE = array_map('mysql_real_escape_string', $_COOKIE);
$_REQUEST = array_map('mysql_real_escape_string', $_REQUEST);

Nu zeg jij dat dit 'voor de puristen not done' is, maar ik snap eigenlijk niet zo goed waarom niet.
Is dit om performance redenen? Ik weet niet hoe mysql_real_escape_string werkt, maar ik neem aan dat je neit elke keer naar de DB gaat?
Of is het om schoonheids redenen? of kan er onbewust foute data ontstaan?

[MueR]

Allereerst wil je $_REQUEST niet gebruiken. Dat is een verzamelbak, je weet niet waar je data vandaan komt. Verder wil je niet om magic_quotes_gpc heenwerken, dat wil je uit zetten. Ook daar zijn mogelijkheden voor te vinden.

Het heeft niks met purisme te maken. Je hebt die escaping driekwart van de tijd gewoon niet nodig. Dat heb je enkel nodig voor data die in je database verdwijnt, en moet je dus dan gebruiken. Niet zomaar alles blind escapen. Stel dat ik een zoekformulier heb waar jij de term (incl quotes) "foo" invult. Ik gebruik dan mysql_real_escape voor mn zoekopdracht, maar voor de weergave van je opdracht ("foo" terugzetten in je form field), wil je gewoon htmlentities met de ENT_QUOTES option gebruiken. Je moet weten wat je waar wil voorkomen en daar de juiste functie op toepassen. Met real_escape kan ik nog steeds script tags inkloppen en daarmee allerlei rotzooi uithalen.

Oftewel: The Right Tool for the Right Job!

[BasieP]

MueR schreef op vrijdag 25 september 2009 @ 21:33:
Allereerst wil je $_REQUEST niet gebruiken. Dat is een verzamelbak, je weet niet waar je data vandaan komt. Verder wil je niet om magic_quotes_gpc heenwerken, dat wil je uit zetten. Ook daar zijn mogelijkheden voor te vinden.

Het heeft niks met purisme te maken. Je hebt die escaping driekwart van de tijd gewoon niet nodig. Dat heb je enkel nodig voor data die in je database verdwijnt, en moet je dus dan gebruiken. Niet zomaar alles blind escapen. Stel dat ik een zoekformulier heb waar jij de term (incl quotes) "foo" invult. Ik gebruik dan mysql_real_escape voor mn zoekopdracht, maar voor de weergave van je opdracht ("foo" terugzetten in je form field), wil je gewoon htmlentities met de ENT_QUOTES option gebruiken. Je moet weten wat je waar wil voorkomen en daar de juiste functie op toepassen. Met real_escape kan ik nog steeds script tags inkloppen en daarmee allerlei rotzooi uithalen.

Oftewel: The Right Tool for the Right Job!

het uitzetten van magic quotes is dus binnenkort deprecated. verder gaat het mij alleen om quotes. De rest vang ik al af.
Echter heb ik best wel een berg code waarbij het vrij veel werk is om alle queries na te gaan.
je hebt het over data die in de database verdwijnt, maar bij een select statement wil je ook escapen. dus praktisch alles wat in een 'mysql_query' terecht komt wil je escapen.

Ik bron van die eerder geposte code was een comment op php.net. Ik heb daar mijn eigen versie van gemaakt (want deze werkt al niet wanneer je array's post etc.) en pas deze toe op GET en POST.

PHP:

    function mysql_real_escape($value) {
        if (is_array($value)) {
            return array_map('mysql_real_escape', $value);
        } else {
            if (get_magic_quotes_gpc())
                $value = stripslashes($value);
            $value = mysql_real_escape_string($value);
            return $value;
        }
    }

    $_POST = mysql_real_escape($_POST);
    $_GET = mysql_real_escape($_GET);

Echter is dit echt geen ei van kolumbus, want ik had al ergens dat ik data uit de database haal, hier een bewerking op doe, en het dan weer insert. Komt geen get/post aan te pas, en bij het ophalen krijg ik een woord als "foto's" terug. Bij het inserten gaat die dan al fout.

Is dan echt de enige echte goede oplossing het doorlopen van al me code en overal (waar nodig) handmatig die functie toepassen?

[ Voor 7% gewijzigd door BasieP op 25-09-2009 23:44 ]

[Erkens]

BasieP schreef op vrijdag 25 september 2009 @ 23:43:
Echter heb ik best wel een berg code waarbij het vrij veel werk is om alle queries na te gaan.
je hebt het over data die in de database verdwijnt, maar bij een select statement wil je ook escapen. dus praktisch alles wat in een 'mysql_query' terecht komt wil je escapen.

Dat klopt.

Echter is dit echt geen ei van kolumbus, want ik had al ergens dat ik data uit de database haal, hier een bewerking op doe, en het dan weer insert. Komt geen get/post aan te pas, en bij het ophalen krijg ik een woord als "foto's" terug. Bij het inserten gaat die dan al fout.

Daarom moet je alleen wat in je daadwerkelijke query komt escapen. Want wat nu als je in je $_POST een waarde hebt staan die je wilt controleren op juistheid en hieruit blijkt dat deze ongeldig is en je wilt die terug geven aan de gebruiker, dus in HTML. Staan er wel leuk slashes hier en daar, dus moet je strip_slashes gebruiken, maar dat kan dus ook "fout" gaan. Al met al niet handig.

Is dan echt de enige echte goede oplossing het doorlopen van al me code en overal (waar nodig) handmatig die functie toepassen?

Ja, helaas wel. Wellicht dat je het nu wel werkend krijgt door op deze vieze manier te werk te gaan, maar daarmee los je natuurlijk het daadwerkelijke probleem niet op. Want wat je dan eigenlijk doet is je eigen versie maken van magic_quotes terwijl dat niks meer is dan een schijnveiligheid en waarbij het meestal uitkomt op onleesbare en/of ranzige code met diverse "hacks". Dat wil je niet, dus als het even kan, fix het dan meteen goed

[NMe]

BasieP schreef op vrijdag 25 september 2009 @ 20:52:
[...]

Nu zeg jij dat dit 'voor de puristen not done' is, maar ik snap eigenlijk niet zo goed waarom niet.
Is dit om performance redenen? Ik weet niet hoe mysql_real_escape_string werkt, maar ik neem aan dat je neit elke keer naar de DB gaat?
Of is het om schoonheids redenen? of kan er onbewust foute data ontstaan?

Als ik een string post die verder niet in de database hoeft, waarom zou je er dan toch in gaan escapen? Default maar alles dat string heeft gaan escapen is gewoon achterlijk en puur ter bescherming van newbies in PHP gebouwd. Daarnaast, het "wordt niet deprecated": magic_quotes zijn al deprecated en worden vanaf PHP 6 überhaupt niet meer ondersteund voor zover ik weet. Vanaf dat moment breken ineens al je scripts...

[.oisyn]

Zoals al werd geopperd kun je ook gewoon prepared statements gebruiken, hoef je niet eens te escapen.

[BasieP]

oke danku heren,

ik ga eens serieus naar prepared statements kijken. Dit lijkt me niet alleen de veiliste, maar ook de netste oplossing.
Er is alleen 1 probleempje:
op somige systemen draait php4...

[pedorus]

BasieP schreef op zaterdag 26 september 2009 @ 00:24:
Er is alleen 1 probleempje:
op somige systemen draait php4...

Dat is net zoiets als Win98, of Office 2000: het is niet meer ondersteund, er zijn geen security updates meer, en het is tijd om het gelijk te vervangen.

[NMe]

pedorus schreef op zaterdag 26 september 2009 @ 01:02:
[...]

Dat is net zoiets als Win98, of Office 2000: het is niet meer ondersteund, er zijn geen security updates meer, en het is tijd om het gelijk te vervangen.

Jij weet natuurlijk net zo goed als ik dat het lang niet altijd een kwestie is van zomaar even vervangen.

[BasieP]

mmm..
ben nu een tijdje aan't kijken hoe ik het om moet zetten (mysql_... naar $mysqli) maar dit is nog best lastig.

Een statement kan je weer niet makkelijk iteratief door je rows heen lopen zonder al je kolommen eerst te binden.. das erg ruk.

Daarom wil ik dus zo min mogelijk gebruik maken van prepared statements, omdat ik dan een stuk code als dit:

PHP:

$res = mysql_query("SELECT * FROM `table` WHERE `var` = '$value'");
if (mysql_num_rows($res) == 0) {
  //doe A
} else {
  while ($row = mysql_fetch_object($res)) {
    //doe b
  }
}

PHP:

$statement = $mysqli->prepare("SELECT * FROM `table` WHERE `var` = ?");
$statement->bind_param($value);
$statement->execute();
if ($statement->num_rows == 0) {
  //doe A
} else {
  $statement->bind_result($col1, $col2, $col3, ..);
  while ($statement->fetch()) {
    //doe b
  }
}

waarbij ik behalve een aantal regels extra code ook een berg vars erbij heb (voor elke kolom 1, die ik specifiek moet noemen)


En omdat ik dan zo min mogelijk prepared statements wil gebruiken zal ik per query moeten kijken of een bepaalde waarde ook mogelijk sql injectie gevoelige gegevens kan bevatten.
Is het dan niet slimmer om gewoon ditzelfde te doen met mysql_real_escape_string() ?

[Gomez12]

Laat ik het zo zeggen, je programmeert verkeerd...

Een select * is bijna altijd fout, vars benoemen die je gebruikt is juist goed. Blind escapen is altijd fout.

Ik zou je aanraden om eerst eens wat te lezen over hoe je moet programmeren ( en dan zijn tuts uit 2006 niet handig ), zodat je 1 grote rewrite kan doen die gelijk de meeste problemen aanpakt ipv zoals je nu doet enkel maar op 1 punt gaan focussen en volgende week / maand een ander punt tegen te komen.

Zoals ik het nu zie je aanpak verkeerd en focus je je alleen maar op work-arounds die het minste werk veroorzaken ipv een echte oplossing.

[BasieP]

Gomez12 schreef op zaterdag 26 september 2009 @ 11:35:
Laat ik het zo zeggen, je programmeert verkeerd...

Een select * is bijna altijd fout, vars benoemen die je gebruikt is juist goed. Blind escapen is altijd fout.

Ik zou je aanraden om eerst eens wat te lezen over hoe je moet programmeren ( en dan zijn tuts uit 2006 niet handig ), zodat je 1 grote rewrite kan doen die gelijk de meeste problemen aanpakt ipv zoals je nu doet enkel maar op 1 punt gaan focussen en volgende week / maand een ander punt tegen te komen.

Zoals ik het nu zie je aanpak verkeerd en focus je je alleen maar op work-arounds die het minste werk veroorzaken ipv een echte oplossing.

Oke, dit schiet me even in het verkeerde keelgat.

Ik weet niet of jij voor hobby of voor werk programmeert, maar in een bedrijf gelden er meer dingen dan alleen maar 'the perfect solution'.
uitspraken als 'select * is bijna altijd fout' zijn gewoon niet waar. De voordelen wegen in mijn situatie op tegen de nadelen, dus is het gewoon goed.

Zoals ik hierboven heb aangegeven zoek ik een 100% veilige oplossing die zo min mogelijk tijd kost. (ook in de toekomst)

Als het omzetten van bestaande code van mysql_.. naar mysqli_.. heel veel tijd kost, en een andere manier ook 100% veiligheid bied is de keuze snel gemaakt. Hoe inperfect ook.

'je programmeert fout' vind ik nogal een uitspraak. Ik maak een kosten-baten afweging, en als jij dat fout vind mag dat natuurlijk, maar raad ik je aan in loondienst te gaan/blijven, en iemand anders het denkwerk te laten doen.

[ Voor 6% gewijzigd door BasieP op 26-09-2009 11:46 ]

[NMe]

Als jij het uitschrijven van * naar een volle lijst met veldnamen een kosten-batenafweging vindt, en als je niet inziet waarom magic_quotes geen 100% veilige oplossing is maar een valkuil die je in de toekomst gaat opbreken, dan denk ik eigenlijk juist dat Gomez12 gelijk heeft en je beter eens wat tijd kan gaan steken in fatsoenlijk leren waar je nu eigenlijk mee bezig bent. Dat klinkt lullig en zo komt het vast ook over, maar dat is de enige tip die je op de lange duur gaat helpen. Take it or leave it.

[Verwijderd]

Jammer BasieP dat je de adviezen van Gomez in de wind slaat. Maar vooral "select *" gebruiken

Als de informatiestructuur veranderd (met wensen) of zelfs verdwijnt, zal je vanuit de code nooit meer de database-structuur kunnen herbouwen.

nu mag jij (een) argument(en) noemen waarom jij het inderdaad beter weet dan (getuige de critische reacties) ieder andere programmeur.

Ik tik liever iets meer dan dat je afhankelijk moet zijn van "predefined behaviour". Als je code niet meer werkt op een ander systeem (php versie, server) heeft dat te maken met de kwaliteit van de code. ook al is cross-compatibility niet een vereist doel.

[BasieP]

heren, ik wil er geen flamewar van maken en eigenlijk ook geen discussie over wat nou beter programmeren is dus zal het kort houden.

ivm leesbaarheid en gemak kies ik voor select * (en nee niet in alle gevallen)
Het argument van database opbouwen vanuit code heb ik nog nooit gehoord, en ook nog nooit meegemaakt. Verder is dat ook niet waar, want je mist bij select col1,col2 ook velden die misschien wel in de DB staan, en je kan bij select * ook aan de hand van de later gebruikte colommen je DB opbouwen. Dus ik denk dat dit een non-argument is.

Verder ben ik al lang overtuigd van het feit dat magic quotes slecht is, ik spreek dat ook niet tegen.

Wat ik wel vroeg was of het gebruik van mysqli_.. (met hier en daar prepared statements) beter is dan het gebruik van mysql_.. (met hier en daar mysql_real_escape_string)

Ik weet daar gewoon niet zo veel over. (En volgens mij is dat niet 'advies in de wind slaan', maar is het horizon breed houden en informatie winnen)

[Confusion]

BasieP schreef op zaterdag 26 september 2009 @ 11:44:
uitspraken als 'select * is bijna altijd fout' zijn gewoon niet waar.

Zeker wel. Als je een kolom (tussen)toevoegt, dan komt er opeens iets anders uit die query en zal er van alles stuk gaan, omdat je daar geen rekening mee gehouden hebt. Als je opsomt welke gegevens je nodig hebt, dan blijft het ook werken als je een kolom toevoegt en hoef je bij een databasewijziging niet op -tig plaatsen je query afhandeling aan te gaan passen. En als je nu eens eerlijk naar het verleden kijkt: hoe vaak heb je die situatie al niet meegemaakt?

Ik had maar 1 praktijkgeval (en bovenstaande reactie van een collega, met nog een aantal andere voordelen) nodig om overtuigd te raken; hoeveel heb jij er nodig?

De reactie van Gomez12 is qua vorm weinig constructief, maar negeer de vorm en het kleinerende advies en haal het waardevolle advies er uit.

[ Voor 10% gewijzigd door Confusion op 26-09-2009 13:35 ]

[Gomez12]

BasieP schreef op zaterdag 26 september 2009 @ 13:12:
heren, ik wil er geen flamewar van maken en eigenlijk ook geen discussie over wat nou beter programmeren is dus zal het kort houden.

Ok, houd ik het ook kort

Het argument van database opbouwen vanuit code heb ik nog nooit gehoord, en ook nog nooit meegemaakt.

Dit argument is imho ook complete bullshit. Ik wil (bijna altijd ) juist geen db kunnen opbouwen vanuit code, de code pakt enkel de data die het nodig heeft uit de dbase, is er andere data nodig dan andere query.
Maar een select * veroorzaakt gewoon onnodig veel verkeer ( plak eens een paar blobs in een tabel en je ziet wat ik bedoel als je enkel met de id's wil werken ) en maakt je code afhankelijk van je dbase ( je code redeneert vanuit 6 kolommen, vanwege een heel ander oogpunt heb je een 7e kolom in je db nodig en je mag je code voor 6 kolommen uitbreiden naar 7 kolommen omdat je select * doet )

Verder ben ik al lang overtuigd van het feit dat magic quotes slecht is, ik spreek dat ook niet tegen.

Wat ik wel vroeg was of het gebruik van mysqli_.. (met hier en daar prepared statements) beter is dan het gebruik van mysql_.. (met hier en daar mysql_real_escape_string)

Tja, imho kies je voor een goede manier die nu misschien een investering betekent maar je in de toekomst flexibeler / sneller maakt. Ipv hier en daar prepared statements ( waarbij je dus in de toekomst er misschien meer zal moeten omzetten, en bij elke nieuwe aanvulling moet je weer gaan nadenken en waarbij je er nu enkele kan vergeten wat weer tot een lek kan leiden met daardoor weer meer devtijd ) zou ik gewoon voor een totaal oplossing gaan...

Argumenten met hier en daar / zoafentoe etc vind ik persoonlijk nooit goed. Als je er 1 vergeet heb je diepe shit.

Mysql_real_escape_string is gewoon iets totaal anders als prepared statements.
het is niet mysqli en hier en daar prepared statements of mysql en hier en daar mysql_real_escape_string imho is het of prepared statements ( overal ) of hier en daar mysql_real_escape_string ( waar van toepassing )

BasieP schreef op zaterdag 26 september 2009 @ 11:44:
[...]
uitspraken als 'select * is bijna altijd fout' zijn gewoon niet waar. De voordelen wegen in mijn situatie op tegen de nadelen, dus is het gewoon goed.

Sorry, maar select * hoort wmb gewoon thuis in hetzelfde rijtje als waar goto etc staat.
Mits 100% juist gebruikt is het niet niet altijd fout en soms zelfs handig, maar 99,99999% van het gebruik is gewoon fout.

Zoals ik hierboven heb aangegeven zoek ik een 100% veilige oplossing die zo min mogelijk tijd kost. (ook in de toekomst)

Als het omzetten van bestaande code van mysql_.. naar mysqli_.. heel veel tijd kost, en een andere manier ook 100% veiligheid bied is de keuze snel gemaakt. Hoe inperfect ook.

Het punt wat ik probeerde te maken is meer dat je juist naar de toekomst moet kijken, wat je nu lijkt te doen is enkel kijken naar wat nu het minste tijd kost. Je lost niets structureel op.

Straks gaat er ergens iets fout met jouw huidige quick-fix ( je vergeet hem ergens / je gebruikt hem ergens teveel ) dan moet je dan wederom op zoek naar weer een nieuwe quick-fix ( want je klanten zijn misschien wel bereid om voor 1x een fix te betalen, maar 2x dezelfde fix alleen nu goed uitgevoerd daar krijg ik geen geld voor binnen en al helemaal niet als ik de 2e keer een goede rewrite wil doen )

'je programmeert fout' vind ik nogal een uitspraak. Ik maak een kosten-baten afweging, en als jij dat fout vind mag dat natuurlijk, maar raad ik je aan in loondienst te gaan/blijven, en iemand anders het denkwerk te laten doen.

Imho is deze kosten/baten afweging compleet geldig voor projecten waar je 1/2 jaar bij betrokken bent ( het kost nu weinig geld ) maar als je klanten over de langere termijn wilt houden dan verandert wmb de kosten-baten afweging meer naar eenmalig xx uur investeren zodat ik de komende 5 jaar er niet meer naar om hoef te kijken ipv x uur investeren met het risico dat ik volgend jaar weer x uur moet investeren ( en daarna, en daarna... )

[ Voor 32% gewijzigd door Gomez12 op 26-09-2009 13:51 ]

[.oisyn]

Confusion schreef op zaterdag 26 september 2009 @ 13:31:
[...]

Zeker wel. Als je een kolom (tussen)toevoegt, dan komt er opeens iets anders uit die query en zal er van alles stuk gaan, omdat je daar geen rekening mee gehouden hebt.

Ik moet zeggen dat ik het wel érg vreemd vind dat er ineens dingen stuk zougen gaan als er een kolom bij komt. Tenzij je de kolommen indexeert met een int natuurlijk, maar dan is je code gewoon onleesbaarder (en niet sneller, mocht iemand dat soms denken - int indices in PHP worden namelijk gewoon eerst omgezet naar string en daarna gehashed)

[Verwijderd]

Gomez12 schreef op zaterdag 26 september 2009 @ 13:32:
Dit argument is imho ook complete bullshit. Ik wil (bijna altijd ) juist geen db kunnen opbouwen vanuit code, de code pakt enkel de data die het nodig heeft uit de dbase, is er andere data nodig dan andere query.
Maar een select * veroorzaakt gewoon onnodig veel verkeer ( plak eens een paar blobs in een tabel en je ziet wat ik bedoel als je enkel met de id's wil werken ) en maakt je code afhankelijk van je dbase ( je code redeneert vanuit 6 kolommen, vanwege een heel ander oogpunt heb je een 7e kolom in je db nodig en je mag je code voor 6 kolommen uitbreiden naar 7 kolommen omdat je select * doet )

Ik ben het helemaal eens met een groot gedeelte van de post, maar bij dit gedeelte heb ik toch nog wat vraagtekens..

"Je code redeneert vanuit 6 kolommen".. wat!? Als je een "select *" doet, krijg je alle velden terug, maar je code weet niet hoeveel hij er moet verwachten. In sommige situaties, als je alle velden nodig hebt, kan het best handig zijn om "select *" te gebruiken. Als er dan een veld bij komt, kan je die gewoon gelijk gebruiken in je code.

Zou een beetje raar zijn als je toch alle velden gebruikt, om dan "select veld1, veld2, ..." te doen, terwijl dat exact hetzelfde oplevert dan dat je "select *" doet. En als je dan een veld toevoegt, hoef je de query ook niet meer aan te passen.

edit:
en wat hij zegt.. ^^

[Gomez12]

Verwijderd schreef op zaterdag 26 september 2009 @ 14:15:
[...]

Ik ben het helemaal eens met een groot gedeelte van de post, maar bij dit gedeelte heb ik toch nog wat vraagtekens..

"Je code redeneert vanuit 6 kolommen".. wat!? Als je een "select *" doet, krijg je alle velden terug, maar je code weet niet hoeveel hij er moet verwachten. In sommige situaties, als je alle velden nodig hebt, kan het best handig zijn om "select *" te gebruiken. Als er dan een veld bij komt, kan je die gewoon gelijk gebruiken in je code.

Het probleem met select * is veelal dat mensen in het eindresultaat wel weten wat ze willen en dat hierop de code geschreven wordt...

Als jij een rapport met 6 mooi uitgelijnde en precies vormgegeven resultaten hebt, dan zit je niet te wachten op een extra kolom die je weer handmatig mag wegmoffelen.

Een select * geeft idd alle velden terug, dus als jij een report bouwt op deze output is je report stuk ( als je met kolomindexen werkt ipv associated names ) / error-prone / overmatige overhead etc.

Het probleem met select * is dat 99,99999% van de programmeurs precies weten welke velden ze in code / report gaan gebruiken / beschikbaar willen stellen en dat ze enkel te beroerd zijn om een * uit te schrijven naar wat ze willen waardoor het bij dbase veranderingen funcky errors kan geven ( helemaal met zoiets als mysql wat in combinatie met wat group by "errors" en wat subquerys tot een totaal ander resultaat kan leiden )

[MueR]

BasieP schreef op zaterdag 26 september 2009 @ 00:24:
Er is alleen 1 probleempje:
op somige systemen draait php4...

Dit is ongeveer regel 1 in code die wij binnen ons bedrijf gebruiken voor websites. (bedrijfsgeheim enzo )

PHP:

    // Version and configuration sanity checks 
    $requiredPHP = '5.2';
    if(version_compare(PHP_VERSION, '5', '>') == 0)
        die('FATAL ERROR: PHP 4 and older are <a href="http://www.php.net/archive/2007.php#2007-07-13-1">end of life</a>, please upgrade'); 
    if(version_compare(PHP_VERSION, $requiredPHP, '<') == 1)
        die("FATAL ERROR: PHP $requiredPHP is required, current version is ".PHP_VERSION.' - please upgrade');

Je mag best eisen stellen hoor. Je ondersteunt waarschijnlijk toch ook geen IE5.5? Waarom dan wel PHP4?

[pedorus]

BasieP schreef op zaterdag 26 september 2009 @ 11:14:

PHP:

$res = mysql_query("SELECT * FROM `table` WHERE `var` = '$value'");
if (mysql_num_rows($res) == 0) {
  //doe A
} else {
  while ($row = mysql_fetch_object($res)) {
    //doe b
  }
}

En de vraag is hoe vertaal je dat zo makkelijk mogelijk naar prepared statements. De combinatie tussen select * en bind_result is zeer beroerd (verander het aantal kolommen, of de volgorde, en de code is stuk; daarnaast moet je gaan bepalen welke kolommen het nu zijn). Ik zou, als je zoveel mogelijk op die manier wilt programmeren, eens naar PDO kijken, daar heb je wel fetchObject en veilige prepared statements.

Mocht de boel nou niet zo snel gaan, zorg er dan toch voor dat je select * zoveel mogelijk vermijdt. Je haalt meestal te veel data op.

[Gomez12]

pedorus schreef op zaterdag 26 september 2009 @ 14:59:
[...]

En de vraag is hoe vertaal je dat zo makkelijk mogelijk naar prepared statements. De combinatie tussen select * en bind_result is zeer beroerd (verander het aantal kolommen, of de volgorde, en de code is stuk; daarnaast moet je gaan bepalen welke kolommen het nu zijn). Ik zou, als je zoveel mogelijk op die manier wilt programmeren, eens naar PDO kijken, daar heb je wel fetchObject en veilige prepared statements.

Mocht de boel nou niet zo snel gaan, zorg er dan toch voor dat je select * zoveel mogelijk vermijdt. Je haalt meestal te veel data op.

Imho is de echte vraag toch meer, hoe krijg je dit nou echt werkend?

PDO gebruiken enkel omdat je dan je select * niet hoeft om te schrijven is gewoon wederom een lapmiddel.
Nogmaals, select * is bijna altijd fout je gaat toch vroeger of later weer problemen krijgen met je select * ( je hebt het dan nu met PDO veiliger gemaakt maar niet future proof ).

Als je toch een rewrite moet doen, doe dan gelijk een goede ipv enkel lapmiddelen erbij writen...

[Confusion]

.oisyn schreef op zaterdag 26 september 2009 @ 14:10:
Ik moet zeggen dat ik het wel érg vreemd vind dat er ineens dingen stuk zougen gaan als er een kolom bij komt. Tenzij je de kolommen indexeert met een int natuurlijk, maar dan is je code gewoon onleesbaarder

Maar als je ze niet bij naam noemt in de select statement, dan lees je ze meestal ook niet bij naam uit de resultset: die fouten maak je tegelijkertijd.

Daarnaast gaat het overhevelen uit de resultset naar andere datastructuren bijvoorbeeld weleens fout, omdat er stiekem toch ergens een structuur zit die bijvoorbeeld 5 velden verwacht en er opeens 6 krijgt. Door ze expliciet te noemen en geen lusjes over het aantal kolommen te hoeven maken, heb je dat soort dingen ook automatisch niet.

[Cyphax]

.oisyn schreef op zaterdag 26 september 2009 @ 14:10:
[...]

Ik moet zeggen dat ik het wel érg vreemd vind dat er ineens dingen stuk zougen gaan als er een kolom bij komt.

Ja dat zie ik ook nog niet zo heel snel een groot probleem worden. Ik kan me wel voorstellen dat, wanneer het datatype van een kolom verandert je nog in de knoei zou kunnen komen (hoewel dat misschien helemaal niet geldt voor PHP omdat het niet strongly-typed is), maar dat zal ook niet snel voorkomen en dat los je ook niet op door ipv * alle kolomnamen/aliases op te sommen. Ik denk dat het meer gaat om een goede gewoonte die je aanhoudt.

NMe schreef op zaterdag 26 september 2009 @ 01:17:
[...]

Jij weet natuurlijk net zo goed als ik dat het lang niet altijd een kwestie is van zomaar even vervangen.

Hangt af van hoeveel servers je hebt waar het voor geldt. Ik zou, als het merendeel draait op PHP5.1+ toch maar prepared statements standaard gebruiken en dan voor die servers die nog PHP4 draaien iets anders verzinnen (liefst upgraden, wel zo verstandig). Anders ben je net zoiets aan het doen als een site optimaliseren voor IE6 en dan lapmiddelen toepassen om het in andere browsers werkend te krijgen ipv andersom..

[gvanh]

Je mag best eisen stellen hoor. Je ondersteunt waarschijnlijk toch ook geen IE5.5? Waarom dan wel PHP4?

Tsja ... dat ligt natuurlijk helemaal aan wat je aan het bouwen bent en voor wie. Als het gaat om een systeem dat als grondslag wordt gebruikt voor - bijvoorbeeld - veel websites, dan ben je in sommige gevallen simpelweg niet degene die bepaalt wat voor versie PHP er op een server draait. Als je voor een klant een website bouwt waarbij de klant heeft bepaalt dat de hosting ondergebracht dient te worden bij hoster X en hoster X is laks met z'n PHP upgrades, dan zul je toch voor werkende code moeten zorgen, ook al is dat misschien niet de code zoals je hem optimaal zou willen hebben.

Verder heb ik het ook nog wel meegemaakt dat ik voor het voldongen feit werd gesteld dat een ontwikkelde website moest gaan draaien op een server die magic_quotes aan had staan (!). Vreselijk vervelend, want dan krijg je dus ineens het probleem dat mysql_real_escape string dubbelop gaat werken. Ik was blij dat uiteindelijk vrijwel al mijn database functies gecentraliseerd zijn, zodat ik daar een controle kon doen op magic_quotes, en alleen ging escapen wanneer de magic_quotes niet aan staan. Maar gut ... daar moet je dan dus óók weer rekening meehouden. Inmiddels hebben we gelukkig een aantal eigen servers draaien, waar we zélf kunnen bepalen welke PHP versie draait en met welke instellingen.

Enfin ... mijn punt is dat je helaas lang niet altijd zelf kunt bepalen hoe de server is ingericht. En bij gebruik van een (eigen) framework, is het dus prettig om toch rekening te houden met verschillende scenario's, zodat je niet voor verrassingen komt te staan op het moment dat je de productieserver gaat inrichten.

[Voutloos]

gvanh schreef op zaterdag 26 september 2009 @ 21:01:
Verder heb ik het ook nog wel meegemaakt dat ik voor het voldongen feit werd gesteld dat een ontwikkelde website moest gaan draaien op een server die magic_quotes aan had staan (!). Vreselijk vervelend, want dan krijg je dus ineens het probleem dat mysql_real_escape string dubbelop gaat werken. Ik was blij dat uiteindelijk vrijwel al mijn database functies gecentraliseerd zijn, zodat ik daar een controle kon doen op magic_quotes, en alleen ging escapen wanneer de magic_quotes niet aan staan

En die implementatie is fout, want de magic variant escapet *niet* alles.

En bovendien doe je bepaalde logica op de verkeerde plek. Als je met magic gpc rekening moet houden, is het puur het ongedaan maken van de feature in de 1e paar regels van je code. En vervolgens heb je er in de rest van je code geen last meer van cq. kan je ervan uitgaan dat het uit is.

[Dutchmega]

Een mogelijkheid is om een soort database wrapper te schrijven dat in PHP5 PDO prepared statements gebruikt en in PHP4 het domweg simuleert.

Hou er in ieder geval rekening mee dat SQL injection nog mogelijk is als je alleen magic_quotes hebt en dat je in feite een security leak hebt.

[pedorus]

Dutchmega schreef op zaterdag 26 september 2009 @ 21:08:
Een mogelijkheid is om een soort database wrapper te schrijven dat in PHP5 PDO prepared statements gebruikt en in PHP4 het domweg simuleert.

Dit lijkt me geen serieus voorstel. Dat is zoiets als rekening gaan houden met Windows 98. Zelfs de meest gekke organisaties kun je er wel van overtuigen dat het niet handig is om ongesupporte software te gebruiken (desnoods met keywords als audit, Sarbanes-Oxley en compliance). Als het om een externe hoster gaat, dan is weggaan bij die hoster sowieso aan te bevelen, aangezien er dan met zekerheid hosters zijn die beter scoren op betrouwbaarheid, kwaliteit en waarschijnlijk zelfs prijs.

Hou er in ieder geval rekening mee dat SQL injection nog mogelijk is als je alleen magic_quotes hebt en dat je in feite een security leak hebt.

Hangt af van de character set. Maar het beste bij magic quotes is dus gelijk op de goede manier ongedaan maken.

[Gomez12]

gvanh schreef op zaterdag 26 september 2009 @ 21:01:
[...]
Als je voor een klant een website bouwt waarbij de klant heeft bepaalt dat de hosting ondergebracht dient te worden bij hoster X en hoster X is laks met z'n PHP upgrades, dan zul je toch voor werkende code moeten zorgen, ook al is dat misschien niet de code zoals je hem optimaal zou willen hebben.

Sorry hoor, maar misschien dat dit opgaat als je aan het hobby'en bent. Maar als je gewoon zakelijk bezig bent kan je gewoon eisen stellen aan je klant. Wil je klant toch bij die 10 euro per jaar hoster ( want dat is het over het algemeen afaik ) blijven dan kan je hem gewoon je product / code niet verkopen...

Ik ga in ieder geval niet driedubbel krom liggen en me in de meest onmogelijke bochten wringen omdat een klant gewoon een verouderd / niet ondersteund hostingpakket heeft. Wij hebben gewoon een framework, dat heeft minimum eisen en daarbinnen wordt gewerkt / dat wordt uitgebreid, wij gaan niet een heel framework aan de kant gooien als de klant toch code wil hebben.

Verder heb ik het ook nog wel meegemaakt dat ik voor het voldongen feit werd gesteld dat een ontwikkelde website moest gaan draaien op een server die magic_quotes aan had staan (!). Vreselijk vervelend, want dan krijg je dus ineens het probleem dat mysql_real_escape string dubbelop gaat werken. Ik was blij dat uiteindelijk vrijwel al mijn database functies gecentraliseerd zijn, zodat ik daar een controle kon doen op magic_quotes, en alleen ging escapen wanneer de magic_quotes niet aan staan. Maar gut ... daar moet je dan dus óók weer rekening meehouden.

Tja, dit vind ik dan weer een opzetfout. Als je een product niet op je eigen servers hebt draaien moet je rekening houden met alle instelmogelijkheden die er zo ongeveer in de manual staan. Lijkt me standaard error-handling.

Enfin ... mijn punt is dat je helaas lang niet altijd zelf kunt bepalen hoe de server is ingericht. En bij gebruik van een (eigen) framework, is het dus prettig om toch rekening te houden met verschillende scenario's, zodat je niet voor verrassingen komt te staan op het moment dat je de productieserver gaat inrichten.

Rekening houden met verschillende scenario's ok, maar unsupported versies zijn imho toch echt een compleet ander verhaal.

[.oisyn]

Confusion schreef op zaterdag 26 september 2009 @ 16:06:
[...]

Maar als je ze niet bij naam noemt in de select statement, dan lees je ze meestal ook niet bij naam uit de resultset: die fouten maak je tegelijkertijd.

Sorry, maar nee, dat lijkt me onzin. Heb je daar praktische voorbeelden van? Ik heb het idee (en ja, dat is een "gut feeling") dat iedereen sowieso kolomnamen bij naam noemt, en niet bij index. Of ze nou select * gebruiken of niet.

[pedorus]

.oisyn schreef op zondag 27 september 2009 @ 00:22:
[...]

Sorry, maar nee, dat lijkt me onzin. Heb je daar praktische voorbeelden van? Ik heb het idee (en ja, dat is een "gut feeling") dat iedereen sowieso kolomnamen bij naam noemt, en niet bij index. Of ze nou select * gebruiken of niet.

Ja, onderaan BasieP in "[PHP] addslashes magic_quotes_gpc etc."; aan bind_result geef je geen namen mee, dus de volgorde in de tabel zelf is dan opeens zeer belangrijk als je select * doet.

[cariolive23]

pedorus schreef op zaterdag 26 september 2009 @ 21:31:
(desnoods met keywords als audit, Sarbanes-Oxley en compliance)

offtopic:
En dan wel MySQL gebruiken?

Bij het gebruik van MySQLi heb ik nog nooit begrepen waarom een prepared statements ook het resultaat moet gaan binden aan variabelen en niet alleen de input voor de variabele. Het is niet moeilijk en de variabelen heb je toch nodig, maar het is toch weer extra werk. Met PDO heb je dit niet nodig en kun je met fetch_all een complete resultset in één keer in een array gooien. De rest van je code kan dan verder gaan werken met een array, het databaseverhaal is dan al klaar.

Met PostgreSQL ben ik ook niet anders gewend, pg_query_params() om een query met placeholders en de parameters naar de database te sturen en pg_fetch_all() om een array aan te maken met alle resultaten. Hele simpele en eenvoudige code die ook nog eens veilig is. Slechts 3 regeltjes code voor het maken van de connectie, uitvoeren van de query en het maken van de array.

KISS: Keep It Short and Simple!

[MueR]

gvanh schreef op zaterdag 26 september 2009 @ 21:01:
Tsja ... dat ligt natuurlijk helemaal aan wat je aan het bouwen bent en voor wie. Als het gaat om een systeem dat als grondslag wordt gebruikt voor - bijvoorbeeld - veel websites, dan ben je in sommige gevallen simpelweg niet degene die bepaalt wat voor versie PHP er op een server draait. Als je voor een klant een website bouwt waarbij de klant heeft bepaalt dat de hosting ondergebracht dient te worden bij hoster X en hoster X is laks met z'n PHP upgrades, dan zul je toch voor werkende code moeten zorgen, ook al is dat misschien niet de code zoals je hem optimaal zou willen hebben.

Ik weiger pertinent om oude PHP versies te ondersteunen, zeker versies die al bijna 3 jaar uit de gratie zijn en al 2 jaar deprecated zijn. Iedere hostingboer die nog PHP4 draait (tenzij op een specifiek daarvoor ingerichte server, met een heel specifiek doel) is een schande voor de branche, want dan zijn het gewoon luie donders. Hetzelfde geld voor server settings. Staat register_globals aan, dan gaat ons systeem gewoon op zn muil met de melding dat register_globals uit moet. Rekening houden met dat soort dingen is geen "compatibility", dat is jezelf in je voet schieten met een howitzer.

Verder heb ik het ook nog wel meegemaakt dat ik voor het voldongen feit werd gesteld dat een ontwikkelde website moest gaan draaien op een server die magic_quotes aan had staan (!).

Dan zeg je dus tegen de klant dat hij met zijn hoster moet regelen dat die instelling uit gaat. Desnoods alleen in die hosting voor je klant. Lapmiddeltjes zijn leuk, maar nutteloos. Je bent alleen maar meer failure points in je software aan het bouwen.

Enfin ... mijn punt is dat je helaas lang niet altijd zelf kunt bepalen hoe de server is ingericht. En bij gebruik van een (eigen) framework, is het dus prettig om toch rekening te houden met verschillende scenario's, zodat je niet voor verrassingen komt te staan op het moment dat je de productieserver gaat inrichten.

Ik wel. Het gros van de websites die wij afleveren blijft op onze eigen servers, maar de enkeling die toch extern wil hosten krijgt van ons gewoon een lijst met eisen. Hier gaat je hoster aan voldoen, zo niet, kunnen wij een goede werking van de software niet garanderen. Je bent een bedrijf, je mag best minimum eisen aan je produkt stellen hoor. Dat doet elke software toko. Microsoft gaat ook geen rekening houden met oude processors, die zeggen vrolijk: dit heb je nodig, zo niet, pech gehad.

[Verwijderd]

Hoewel je helemaal gelijk hebt MueR, weet ik wel dat er helaas ook veel bedrijven zijn die niet zomaar even alles kunnen ombouwen. Dat kost ook geld. Het komt genoeg voor dat websites/-applicaties nog altijd niet met PHP5 werken. Meestal omdat de klant niet van plan is ervoor te betalen.

Dat neemt niet weg dat een hostingpartij waarbij je niet kunt vragen om een combinatie van bepaalde instellingen niet erg serieus genomen kan worden. Meestal gaat het juist weer om de kleinere webdesign-toko's die alles zelf hebben ontwikkeld en die per se PHP4 nodig hebben omdat dat nu eenmaal hun basis was.

Hetzelfde zul je overigens nog zien met MySQL. Vanaf 2010 wordt alles voor 5.0 niet meer bijgehouden en horen mensen dus afscheid te nemen van MySQL 4.x. Dat zie ik ook voorlopig nog niet gebeuren.

[Voutloos]

Blijft jammer dat de adoptie echt jaren duurt. Je zou nu hoogstens nog gekibbel over wanneer je PHP 5.3 gaat gebruiken moeten hebben, en alles dat voor 5.2 zit al vergeten moeten zijn.

Maar dan moet je maar ook geen klant hebben met RedHat inc povere 5.1

Om weer iets meer ontopic te komen: Dan kan je nu ook al voorspellen dat je nog 5 jaar met magic quotes zit, aangezien 6 uberhaupt nog moet uitkomen en vervolgens ongetwijfeld ook als een met PHP 5 vergelijkbare drempel gezien wordt.

[.oisyn]

pedorus schreef op zondag 27 september 2009 @ 00:32:
[...]

Ja, onderaan BasieP in "[PHP] addslashes magic_quotes_gpc etc."; aan bind_result geef je geen namen mee, dus de volgorde in de tabel zelf is dan opeens zeer belangrijk als je select * doet.

Pfff wat een idiote interface

[BasieP]

nou mensen ik ben blij dat ik wanneer ik select * doe nooit de kolommen op nummer opzoek.
Ik werk eigenlijk altijd met zoiets

PHP:

$res = mysql_query("select * from table");
while ($row = mysql_fetch_object($res)) {
  echo "naam: " . $row->naam" . "<br>";
  echo "achternaam: " . $row->achternaam" . "<br>";
  //etc.
}

Als het tussenvoegen van kolommen het grote argument tegen select * is, denk ik dat ik qua code wel safe zit. Of zijn er verder nog dingen die echt een groot nadeel zijn van select *?

[Gomez12]

De data die extra meekomt is extra belasting

Voor mij persoonlijk de onduidelijkheid wat er nou getoond gaat worden, maar dit ligt denk ik meer aan mijn gemiddelde query's van 200 regels of groter... Paar subquery's / joins en ik zie niet zo duidelijk meer wat die * voorstelt... Voor simpele query's maakt het niet zoveel uit, maar als je ook grotere query's hebt wil ik toch 1 standaard hanteren...

Maar eigenlijk wacht ik meer op een echt goed argument voor select *, is dat echt alleen maar die paar toetsaanslagen minder? Ik gok dat bij mij al het minder tikken bij een select * compleet teniet gedaan wordt door het extra commentaar om te vertellen wat er uit die query gaat komen...

[.oisyn]

Gomez12 schreef op zondag 27 september 2009 @ 19:51:
Maar eigenlijk wacht ik meer op een echt goed argument voor select *

Als je business layer niet weet welke data de presentation layer wilt weergeven.

[Gomez12]

.oisyn schreef op zondag 27 september 2009 @ 23:37:
[...]

Als je business layer niet weet welke data de presentation layer wilt weergeven.

En dat moet dan maar onder het motto van : ik weet het niet, ik dump alles maar?

Zelfs onder dit motto is je presentation layer nog steeds gebonden aan je tabelstructuur ( of je hebt echt alles in 1 tabel staan ), een normale interface met afspraken wat er wel / niet inzit lijkt me niet onlogisch...

[.oisyn]

Gomez12 schreef op maandag 28 september 2009 @ 00:03:
[...]

En dat moet dan maar onder het motto van : ik weet het niet, ik dump alles maar?

Ja, 't is verdomd handig dat bijv. een forumsysteem al de data gewoon door kan schuiven naar de templates, die delen van die informatie al dan niet gaan gebruiken. Het is vooral handig dat een site extra informatie in de database op kan nemen die via de templates geexposed wordt, zonder dat de business layer van het forum zelf daar weet van hoeft te hebben.

Zelfs onder dit motto is je presentation layer nog steeds gebonden aan je tabelstructuur ( of je hebt echt alles in 1 tabel staan )

Nee, het is gebonden aan data type objects waar automatisch alle relevante informatie in staat.

[Kalentum]

.oisyn schreef op maandag 28 september 2009 @ 00:10:
[...]

Ja, 't is verdomd handig dat bijv. een forumsysteem al de data gewoon door kan schuiven naar de templates, die delen van die informatie al dan niet gaan gebruiken. Het is vooral handig dat een site extra informatie in de database op kan nemen die via de templates geexposed wordt, zonder dat de business layer van het forum zelf daar weet van hoeft te hebben.


[...]

Nee, het is gebonden aan data type objects waar automatisch alle relevante informatie in staat.

Dan nog zou ik kiezen voor alleen de relevante velden in een select en niet voor alles.

[.oisyn]

Mijn punt was dat een user de database kan wijzigen maar niet de code hoeft te wijzigen.

[caoim]

Zelf doe ik ook nooit aan select *, op een gegeven moment weet je niet meer welke velden je nu juist allemaal oproept / effectief gebruikt en .. Plus lijkt het mij ook dat een select * trager zal zijn, aangezien er eerst nog moet gekeken worden welke velden allemaal meegenomen dienen te worden. Al kan dit mss verwaarloosbaar zijn (of helemaal niet correct), nog niet getest.

Wat de initiële vraag betreft, ik gebruik altijd PDO en prepared statements. Gewoon zo handig, zou het niet meer kunnen missen Zelf gebruik ik altijd een zelfgeschreven functie om data die ik binnenkrijg via een formulier of dergelijke te ontdoen van eventuele slashes.

PHP:

function undoMagicQuotes($string) {
    if (get_magic_quotes_gpc()) {
        $string = stripslashes($string);
    }
    
    return $string;
}

[.oisyn]

caoim schreef op maandag 28 september 2009 @ 14:42:
Plus lijkt het mij ook dat een select * trager zal zijn, aangezien er eerst nog moet gekeken worden welke velden allemaal meegenomen dienen te worden. Al kan dit mss verwaarloosbaar zijn (of helemaal niet correct), nog niet getest.

Ah ja, als we dan toch dit onzinnige argument aanhouden, denk je dan niet dat het tegelijkertijd ook langzamer kan zijn omdat je query string nou eenmaal langer is en er meer geparsed moet worden?

[cariolive23]

Het grappig van een * is dat er geen problemen optreden bij dubbele namen. Wanneer je gaat fetchen naar een associatieve array, dus de onbekende kolomnamen gaat gebruiken, kan er ineens data verdwijnen...

SELECT
t1.naam,
t2.naam
FROM
t1 JOIN t2 ON t1.id = t2.id_master;

[Erkens]

cariolive23 schreef op maandag 28 september 2009 @ 15:37:
Het grappig van een * is dat er geen problemen optreden bij dubbele namen. Wanneer je gaat fetchen naar een associatieve array, dus de onbekende kolomnamen gaat gebruiken, kan er ineens data verdwijnen...

SELECT
t1.naam,
t2.naam
FROM
t1 JOIN t2 ON t1.id = t2.id_master;

Met zo'n query ben je ook al niet slim bezig natuurlijk

[Gomez12]

.oisyn schreef op maandag 28 september 2009 @ 15:18:
[...]

Ah ja, als we dan toch dit onzinnige argument aanhouden, denk je dan niet dat het tegelijkertijd ook langzamer kan zijn omdat je query string nou eenmaal langer is en er meer geparsed moet worden?

Ah, dus feitelijk hangt het er van af hoeveel kolommen je hebt en wat je kolomnamen zijn of een select * of het uitschrijven sneller is

[.oisyn]

Nee, feitelijk is het een onzinnig argument zoals ik al zei. Het daadwerkelijke verschil zal verwaarloosbaar zijn.

[Remus]

.oisyn schreef op maandag 28 september 2009 @ 16:24:
Nee, feitelijk is het een onzinnig argument zoals ik al zei. Het daadwerkelijke verschil zal verwaarloosbaar zijn.

Ligt ook wel een beetje aan het wireprotocol van je database. Als je onnodig veel kolommen toevoegt en die kolommen zijn (grote) varchars dan kan dat - zeker bij grotere resultsets - schelen in de hoeveelheid te verzenden data (en daar mee dus ook op de network throughput van je database server).

[Voutloos]

Dat dat een verschil kan zijn ontkent niemand. Maar het gekeuvel over query parse tijden gaat gewoon nergens over.

[.oisyn]

Remus schreef op maandag 28 september 2009 @ 17:00:
[...]

Ligt ook wel een beetje aan het wireprotocol van je database.

Volgens mij ging het om alle kolommen handmatig selecteren of een * gebruiken, waarbij de geretourneerde resultset dus identiek is.

[Gomez12]

.oisyn schreef op maandag 28 september 2009 @ 17:09:
[...]

Volgens mij ging het om alle kolommen handmatig selecteren of een * gebruiken, waarbij de geretourneerde resultset dus identiek is.

Ho wacht, alhoewel mijn laatste opmerking een geintje was heb ik het al de hele tijd perse niet over eenzelfde resultset, mijn resultset met kolommen is kleiner.

[cariolive23]

Erkens schreef op maandag 28 september 2009 @ 15:55:
[...]

Met zo'n query ben je ook al niet slim bezig natuurlijk

En laat dit nu precies de essentie van het * zijn... Daarmee ga je dus hele fraaie bugs aanmaken, het is aan de testers om deze fouten er weer uit te halen. Gelukkig kost testen en debuggen niets, zelfs geen tijd .

Een * kun je gebruiken voor views en stored procedures/functions, die mogen nooit van vorm veranderen en geven één complete dataset retour. Met tabellen weet je honderd procent zeker dat deze (ooit) van vorm veranderen, worden gejoined op andere tabellen met mogelijk dezelfde namen, etc. etc. Queries netjes en vooral compleet uitschrijven voorkomen dan bugs, uitschrijven levert je uiteindelijk zelfs veel tijdwinst op.

Het gebruik van * geeft vaak dan al een aardige indicatie van het niveau van de gebruikte SQL en de hoeveelheid bugs die je zult aantreffen. Een beetje vergelijkbaar met het gebruik van @ om iedere foutmelding in PHP maar te onderdrukken zonder er iets mee te doen.

[.oisyn]

Wat een gezever. Voor de duidelijkheid, ik had het er niet over dat je net zo goed altijd SELECT * kon gebruiken. Iemand vroeg een voorbeeld van wanneer je SELECT * wilde gebruiken. Daar sta ik nog steeds achter. En nee, dat zegt compleet *niets* over het niveau van die statements.

[Confusion]

.oisyn schreef op zondag 27 september 2009 @ 00:22:
Ik heb het idee (en ja, dat is een "gut feeling") dat iedereen sowieso kolomnamen bij naam noemt, en niet bij index.

Was het maar zo'n feest. Het meestvoorkomende probleem is trouwens inderdaad dat hogere indices opeens naar andere types data verwijzen en het daarop stukloopt. Maar ook daar geldt dat mensen impliciet verderop aannames over de data maken.

[Gomez12]

.oisyn schreef op maandag 28 september 2009 @ 20:49:
Wat een gezever. Voor de duidelijkheid, ik had het er niet over dat je net zo goed altijd SELECT * kon gebruiken. Iemand vroeg een voorbeeld van wanneer je SELECT * wilde gebruiken. Daar sta ik nog steeds achter. En nee, dat zegt compleet *niets* over het niveau van die statements.

Imho komt dit een beetje over als goto gaan verdedigen op beginnersweb.
Ja, goto heeft een bestaansrecht en is nuttig, maar wordt heel vaak misbruikt

En op beginnersweb zou ik iedereen die goto aandraagt dan ook bijna per definitie (spreekwoordelijk) standrechtelijk executeren.

Voor zo iemand als TS zie ik het niet echt als good practice om select * aan te raden, maar theoretisch heb je gelijk.

[Verwijderd]

Gomez12 schreef op maandag 28 september 2009 @ 22:06:
[...]

Imho komt dit een beetje over als goto gaan verdedigen op beginnersweb.
Ja, goto heeft een bestaansrecht en is nuttig, maar wordt heel vaak misbruikt

En op beginnersweb zou ik iedereen die goto aandraagt dan ook bijna per definitie (spreekwoordelijk) standrechtelijk executeren.

Voor zo iemand als TS zie ik het niet echt als good practice om select * aan te raden, maar theoretisch heb je gelijk.

Kan dat toontje niet wat minder? Nogal een beetje denigrerend hoe je praat over de TS. En .oisyn min of meer uitmaken voor een beginner? Seriously?

En daarbij is er, als je alle velden gebruikt, niks mis met "select *". Tenzij je op indexes kijkt, maar dan zit daar je probleem? En dat doet "iemand als TS" toch niet.

offtopic:
.oisyn, 23k posts

[Gomez12]

Verwijderd schreef op maandag 28 september 2009 @ 23:39:
[...]

Kan dat toontje niet wat minder? Nogal een beetje denigrerend hoe je praat over de TS.

Tja, sorry hoor, maar als iemand gewoon goed advies in dit topic blijft negeren en enkel maar zoekt naar quickfixes...

En .oisyn min of meer uitmaken voor een beginner? Seriously?
...

offtopic:
.oisyn, 23k posts

Ik zie niet waar ik .oisyn uitmaak voor beginner, heb hem een heel stuk hoger zitten maar dan niet vanwege postcounts, maar meer vanwege getoonde kennis etc.

[Verwijderd]

Gomez12 schreef op maandag 28 september 2009 @ 23:58:
[...]

Tja, sorry hoor, maar als iemand gewoon goed advies in dit topic blijft negeren en enkel maar zoekt naar quickfixes...

"select *" altijd fout is géén goed advies, er zijn ook voorbeelden waar het wél goed kan. Verder over het magic quote gebeuren, tja... Daar gaat het inmiddels al niet meer over?

[...]

Ik zie niet waar ik .oisyn uitmaak voor beginner, heb hem een heel stuk hoger zitten maar dan niet vanwege postcounts, maar meer vanwege getoonde kennis etc.

Hmm, nu ik het nog maal terug lees, denk ik dat ik het toch een beetje verkeerd gelezen heb. Vergelijken met een post op beginnersweb, beginners web is voor beginners. Toch niet echt uitmaken voor beginner, mijn fout.

[Guillome]

.oisyn schreef op zaterdag 26 september 2009 @ 14:10:
[...]

Ik moet zeggen dat ik het wel érg vreemd vind dat er ineens dingen stuk zougen gaan als er een kolom bij komt. Tenzij je de kolommen indexeert met een int natuurlijk, maar dan is je code gewoon onleesbaarder (en niet sneller, mocht iemand dat soms denken - int indices in PHP worden namelijk gewoon eerst omgezet naar string en daarna gehashed)

Oh jawel hoor, dat heb ik ook een paar keer gehad nu.
Als je GROUP BY gebruikt bijvoorbeeld

[drm]

Grappig om te lezen dat je features als SELECT * zou moeten vermijden omdat er mogelijk mensen mee aan het werk zouden gaan die niet weten waar ze mee bezig zijn ...? Misschien heb je dan eigenlijk wel een veel groter probleem dan je SELECT *....

[Guillome]

Verwijderd schreef op dinsdag 29 september 2009 @ 00:11:
[...]

"select *" altijd fout is géén goed advies, er zijn ook voorbeelden waar het wél goed kan. Verder over het magic quote gebeuren, tja... Daar gaat het inmiddels al niet meer over?

Hij zei ook "bijna altijd". Niet gaan verdraaien he

[Gomez12]

Guillome schreef op dinsdag 29 september 2009 @ 00:13:
[...]

Oh jawel hoor, dat heb ik ook een paar keer gehad nu.
Als je GROUP BY gebruikt bijvoorbeeld

Vrees voor de kracht van mysql, een group by over een select * met een veranderde tabelstructuur werkt gewoon nog ( zolang het enkel toevoegingen zijn )

Verwijderd schreef op dinsdag 29 september 2009 @ 00:11:
[...]

"select *" altijd fout is géén goed advies, er zijn ook voorbeelden waar het wél goed kan.

Zie mijn post waar je zo tegen ageerde, goto kent ook voorbeelden waar het wel goed kan, ondertussen is er imho in de meeste programmeertalen geen syntax meer te vinden die geen voorbeelden kent waar het wel goed kan.

Maar toch zijn er een heleboel dingen die het grootste gedeelte van de programmeurs gewoon niet meer moet doen

drm schreef op dinsdag 29 september 2009 @ 00:20:
Grappig om te lezen dat je features als SELECT * zou moeten vermijden omdat er mogelijk mensen mee aan het werk zouden gaan die niet weten waar ze mee bezig zijn ...? Misschien heb je dan eigenlijk wel een veel groter probleem dan je SELECT *....

Ach, dat grotere probleem verdwijnt ooit vanzelf wel zolang de mensen de moeite nemen om dingen bij te leren, en op een gegeven moment zien ze vanzelf ook wel weer in dat de oude regels ( select * mag niet ) ook uitzonderingen kennen

[ Voor 24% gewijzigd door Gomez12 op 29-09-2009 00:29 ]

[Verwijderd]

Guillome schreef op dinsdag 29 september 2009 @ 00:22:
[...]


Hij zei ook "bijna altijd". Niet gaan verdraaien he

Ik had de "99,99999%" even afgerond. Aangezien het vaker dan 0,00001% van de keren voor komt dat je alle velden nodig hebt....

Gomez12 schreef op dinsdag 29 september 2009 @ 00:23:

[...]

Zie mijn post waar je zo tegen ageerde, goto kent ook voorbeelden waar het wel goed kan, ondertussen is er imho in de meeste programmeertalen geen syntax meer te vinden die geen voorbeelden kent waar het wel goed kan.

Maar toch zijn er een heleboel dingen die het grootste gedeelte van de programmeurs gewoon niet meer moet doen

Goto en "select *" vind ik niet met elkaar te vergelijken. Hoe vaak komt het voor dat je alle velden uit een database moet hebben? Hier best vaak, en verwacht dat dat bij vele andere niet anders zal zijn.

Maar goto daarentegen, daar ben ik persoonlijk nog nooit een goede reden voor tegen gekomen, maar dat kan ook aan mij liggen. Maar toch denk ik dat hier de meerderheid dit ook maar zeer zelden tegen komt.

Gomez12 schreef op dinsdag 29 september 2009 @ 00:23:
[...]

Ach, dat grotere probleem verdwijnt ooit vanzelf wel zolang de mensen de moeite nemen om dingen bij te leren, en op een gegeven moment zien ze vanzelf ook wel weer in dat de oude regels ( select * mag niet ) ook uitzonderingen kennen

Ik weet niet sinds wanneer "select * mag niet" een oude regel is, misschien van voor mijn tijd? Ik heb er nog nooit zoveel over gehoord als in dit topic. En in het begin, als je met hobby dingen bezig bent of met kleine websites voor de slager op de hoek, dan boeit het echt niet of je "select *" gebruikt ipv "select" gevolgd door 20 kolomnamen.

Als je eenmaal verder bent dan snap je het ook wel dat het niet slim is om overal * te gebruiken. Denk ook dat 't verschil in performance redelijk te verwaarlozen is, tenzij je een resultset van 100k rows hebt met allemaal bestanden er in (BLOB), maar dan moet je je even achter het oor krabben of de select dan je grootste probleem is.

[ Voor 30% gewijzigd door Verwijderd op 29-09-2009 00:39 ]

[Gomez12]

Verwijderd schreef op dinsdag 29 september 2009 @ 00:31:
[...]
Hoe vaak komt het voor dat je alle velden uit een database moet hebben? Hier best vaak, en verwacht dat dat bij vele andere niet anders zal zijn.

Mwah, hier komt het bijna nooit voor, bijna altijd liggen er relaties tussen tabellen waarbij sowieso de foreign keys al bijna nooit nodig zijn.

[...]
Ik weet niet sinds wanneer "select * mag niet" een oude regel is, misschien van voor mijn tijd?

Eerst aanleren dat select * niet mag en later met inzicht inzien dat het soms wel kan werken is volgens mij een betere volgorde dan het eerst fout doen om daarna fout gedrag af te moeten leren ( en redelijk wat oude software te moeten rewriten )

Ik dacht dat we hier elkaar probeerden te helpen naar een hoger niveau te komen ipv iedereen eerst het slechte aan te leren en dan van de mensen zelf te verwachten dat ze later zelf inzien waar ze de fout ingingen ( waarna je iedereen weer het slechte kan aanleren, want iedereen moet natuurlijk met slechte code beginnen )

[.oisyn]

Gomez12 schreef op maandag 28 september 2009 @ 22:06:
[...]

Imho komt dit een beetje over als goto gaan verdedigen op beginnersweb.
Ja, goto heeft een bestaansrecht en is nuttig, maar wordt heel vaak misbruikt

A) We zijn niet op beginnersweb, en B) jij bent degene die vroeg om een argument vóór SELECT *. Als je vraagt om een goed argument voor goto kan ik die ook best geven. Dat wil uiteraard nog niet zeggen dat het in de gemiddelde case de beste keuze is, en dat heb ik van SELECT * ook nooit beweerd.

[ Voor 22% gewijzigd door .oisyn op 29-09-2009 01:43 ]

[DeepFreeze.NL]

Ik maakte eigenlijk altijd al gebruik van de volgende methode welke ik zo'n 2 jaar geleden op het internet vond:

PHP:

if(get_magic_quotes_gpc()) {
        $voorletters    = stripslashes($_POST['voorletters']);
        $achternaam = stripslashes($_POST['achternaam']);
} else {
        $voorletters    = $_POST['voorletters'];
        $achternaam = $_POST['achternaam'];
}   
$voorletters        = mysql_real_escape_string($voorletters);
$achternaam     = mysql_real_escape_string($achternaam);

Ik maak gebruik van PHP versie 5.2.5 en magic_quotes_gpc staat aan op de server.

Als ik het dus goed begrijp is het verstandig om magic_quotes_gpc uit te zetten en is het gebruik van alleen de mysql_real_escape_string meer dan voldoende en veilig genoeg?!

[ Voor 4% gewijzigd door DeepFreeze.NL op 30-09-2009 10:07 ]

[mithras]

Ik snap sowieso het hele probleem niet van het aan hebben van magic quotes GPC. Het is changable PHP_INI_PERDIR dus je kan met je .htaccess, ini_set of waar dan ook het zelf uitschakelen. Nergens meer code nodig om het handmatig te omzeilen, je kan het namelijk negeren. Dus vanwaar alle paniek

[BasieP]

mithras schreef op woensdag 30 september 2009 @ 10:08:
Ik snap sowieso het hele probleem niet van het aan hebben van magic quotes GPC. Het is changable PHP_INI_PERDIR dus je kan met je .htaccess, ini_set of waar dan ook het zelf uitschakelen. Nergens meer code nodig om het handmatig te omzeilen, je kan het namelijk negeren. Dus vanwaar alle paniek

volgens mij is er geen paniek, maar als je apache in safemode draait weet ik niet of je dat ding ook uit kan zetten. Verder gaat het topic daar inmiddels lang niet meer over

[Erkens]

mithras schreef op woensdag 30 september 2009 @ 10:08:
Ik snap sowieso het hele probleem niet van het aan hebben van magic quotes GPC. Het is changable PHP_INI_PERDIR dus je kan met je .htaccess, ini_set of waar dan ook het zelf uitschakelen. Nergens meer code nodig om het handmatig te omzeilen, je kan het namelijk negeren. Dus vanwaar alle paniek

Tot je straks naar PHP6 gaat

[mithras]

Ja, dat weet ik wel, maar a) in eerste instantie was dat wel een onderdeel van jouw probleem en b) haalt DeepFreeze.NL het weer lekker op

En eigenlijk vind ik het SELECT * redelijk ondergeschikt geneuzel Er staat bij mij standaard ook alles selecteren, zonder expliciet te vermelden wat precies. Die performancewinst is nihil en in het "gevaar" zie ik eigenlijk ook niet zoveel Mja, dat is mijn humble opinion

Erkens schreef op woensdag 30 september 2009 @ 10:23:
[...]

Tot je straks naar PHP6 gaat

Juist niet toch Je zet magic_quotes_gpc uit en werkt dus *zonder*. Bij php6 haal je rule uit je htaccess en dan ben je meteen klaar. Even voor de duidelijkheid, bij mij staat het niet aan, maar als dat zo zou zijn, zou ik het liever op die manier oplossen. Het je er nu geen last van *en* ben je voorbereid op de "toekomst".

[ Voor 36% gewijzigd door mithras op 30-09-2009 10:26 ]

[Erkens]

mithras schreef op woensdag 30 september 2009 @ 10:25:
Juist niet toch Je zet magic_quotes_gpc uit en werkt dus *zonder*. Bij php6 haal je rule uit je htaccess en dan ben je meteen klaar. Even voor de duidelijkheid, bij mij staat het niet aan, maar als dat zo zou zijn, zou ik het liever op die manier oplossen. Het je er nu geen last van *en* ben je voorbereid op de "toekomst".

Dat was nu juist het punt, er moest code veranderd worden om te kunnen werken _zonder_ die magic quotes.

[jbdeiman]

Het voordeel van zelf de kolommen selecteren komt vooral naar buiten bij een query over meerdere tabellen. In beide tabellen staat vaak een id, er staat ook in beide tabellen een kolom die "description" heet. Hoe ga je daar dan mee om?
Juist door zelf de kolommen te selecteren kan je ook snel zien hoe je array (of object) eruit komt te zien en welke array key je moet gebruiken voor een kolom.
Dit komt je werk zeker ten goede. Misschien kost het wat meer tijd om in te tikken, maar je haalt er later wel snelheidswinst uit.
Weet jij bijvoorbeeld uit je hoofd "Hoeveel? Welke?" kolommen een tabel heeft? Ik niet altijd, zeker niet als je met grote projecten met vele tabellen bezig bent. Met een * moet je altijd weer teruggrijpen naar je database om te bepalen hoe een bepaalde kolom heet. Wanneer je handige/ duidelijke namen gebruikt en dit in de query noteert, kan je prima alleen met de informatie uit de query (dus de query zelf!!) uit de voeten, zonder steeds te moeten schakelen.

Natuurlijk zijn er momenten waarop een * gewenst is, maar ik gebruik deze zelden. Vooral omdat de id's in vele gevallen niet nodig zijn en ik eigenlijk nooit met 1 tabel werk. In bijna alle gevallen zitten er wel twee of meer tabellen vast aan een query.

[.oisyn]

mithras schreef op woensdag 30 september 2009 @ 10:08:
Het is changable PHP_INI_PERDIR dus je kan met je .htaccess, ini_set of waar dan ook het zelf uitschakelen.

ini_set()? Think again

Nergens meer code nodig om het handmatig te omzeilen, je kan het namelijk negeren. Dus vanwaar alle paniek

Nou ja, van die paniek weet ik niets, maar ik vind het wel fijn om in code alsnog die check te doen. Overigens niet waar je de variabelen uit de superglobals trekt, maar gewoon aan het begin van je script (typisch in een file die je overal include) waar je even de check doet en indien nodig alle superglobals van hun slashes ontdoet.

Mocht je dan een keer code naar een andere server moven (en dan vooral naar een ander type webserver, bijv. IIS -> Apache of andersom) dan blijft het onder alle omstandigheden gewoon werken.

[MueR]

DeepFreeze.NL schreef op woensdag 30 september 2009 @ 10:04:

PHP:

if(get_magic_quotes_gpc()) {
        $voorletters    = stripslashes($_POST['voorletters']);
        $achternaam = stripslashes($_POST['achternaam']);
} else {
        $voorletters    = $_POST['voorletters'];
        $achternaam = $_POST['achternaam'];
}   
$voorletters        = mysql_real_escape_string($voorletters);
$achternaam     = mysql_real_escape_string($achternaam);

Oke, als je dan toch met magic_quotes werkt, is dit wel een heel omslachtige manier. Dan kan je beter gewoon zoiets doen

PHP:

if (get_magic_quotes_gpc())
    $post = array_map('stripslashes', $_POST);
else
    $post = $_POST;
$voornaam = $post['voorletters'];
//etc

[Voutloos]

Kap eens met slechte voorbeelden posten als de goede oplossingen al eens gelinkt staan.

Bovenstaande gaat fout met arrays, en de code daarboven staat grandioos op de verkeerde plek. Zie post .oisyn en zoek maar naar de goede link.

[.oisyn]

Overigens wil je dat wel recursief doen, want nu strip je arrays niet goed. Daarnaast zou ik de info gewoon weer in $_POST opslaan ipv een eigen array. Ergo: array_walk_recursive()

.edit: wat Voutloos zegt dus

[ Voor 17% gewijzigd door .oisyn op 30-09-2009 11:18 ]

[MueR]

Voutloos schreef op woensdag 30 september 2009 @ 11:13:
Kap eens met slechte voorbeelden posten als de goede oplossingen al eens gelinkt staan.

De goede oplossing is in reactie 1 al gegeven: zet magic quotes uit. Maar aangezien iedereen doorgaat..

Bovenstaande gaat fout met arrays, en de code daarboven staat grandioos op de verkeerde plek. Zie post .oisyn en zoek maar naar de goede link.

True, ik wist de recursieve tegenhanger zo even niet uit het hoofd en had geen zin om deze te zoeken. Daar ben ik dan ook niet voor.

[Voutloos]

Dus je wist dat je een slecht voorbeeld gaf?

[MueR]

Niet perse slecht, eerder incompleet Voor complete code moet ik facturen schrijven van de baas.

[XWB]

Oeh, het bekende addslashes verhaal. Dat blijft ook maar terug komen. Ik heb er al lang geen ervaring met mee, ik regel altijd een server waar het uit staat, of waar ik zelf kan uitzetten.

In elk geval, ik meen me te herinneren dat bovenstaande voorbeelden niet altijd goed waren. Meen mij te herinneren dat je beter zoiets kon doen:

PHP:

function _stripslashes ()
{
    if ( get_magic_quotes_gpc () )
    {
        $stripData = array ( & $_GET, & $_POST );

        while ( list ( $k, $v ) = each ( $stripData ) )
        {
            foreach ( $v as $key => $value )
            {
                if ( ! is_array ( $value ) )
                {
                    $stripData[$k][$key] = stripslashes ( $value );
                    continue;
                }
                
                $stripData[] =& $stripData[$k][$key];
            }
        }
    }
}

[.oisyn]

.edit: ok, onderstaande code dus niet gebruiken wegens PHP brakheid

---

Zal ik dan maar?

PHP:

if (get_magic_quotes_gpc())
{
    function stripslashes_helper(&$v, $k) { $v = stripslashes($v); }
    array_walk_recursive($v = array(&$_GET, &$_POST, &$_COOKIE, &$_REQUEST), "stripslashes_helper");
}

Lijkt me toch een stuk duidelijker

Wel suf dat er geen array_map_recursive() bestaat trouwens. En een lambda had hier ook mooier geweest, maar om nou create_function() te gebruiken...

[ Voor 52% gewijzigd door .oisyn op 02-10-2009 00:39 ]

[XWB]

Zoals ik al zei, ik gebruik het al lang niet meer. Bovenstaand stukje kwam uit een vijf jaar begraven site.

Lijkt me toch een stuk duidelijker

Uiteraard

[ Voor 23% gewijzigd door XWB op 01-10-2009 23:40 ]

[pedorus]

Post ik vele posts geleden een link naar een goed scriptje hiervoor, zie ik vervolgens een scriptje dat pas vanaf 5.3.0 goed werkt en ongemodificeerd een fatal error gooit opeens 'als beste' uit de discussie komen

[.oisyn]

Die bug is anders al in januari 2008 gefixed (en werkt gewoon prima hier onder 5.2.10). Wel suf dat die functie niet iteratief is geïmplementeerd trouwens. Maar ja, er is wel meer suf aan PHP

[ Voor 77% gewijzigd door .oisyn op 02-10-2009 00:36 ]

[drm]

.oisyn:
En een lambda had hier ook mooier geweest, maar om nou create_function() te gebruiken...

Dat is toch hetzelfde