[PHP] Het aantal GET's verminderen

[RSD]

Op een pagina gebruik ik een flink aantal GET's om gegevens op te halen, soms wel tot 10 GET's. Nu wil ik dit aantal verminderen door de variabelen voor de GET's plus inhoud in 1 GET te stoppen. Ik heb al gezocht naar encoders en decoders, maar het wil nog niet echt flotten.

De bedoeling is dus om:

var1=...&var2=...&var3=... etc

om te zetten naar:

q=abde9dfe8ad9e...

in de url.

Op de pagina moet ik dan q=... weer omzetten naar var1=... etc.

Nu had ik 2 functies gevonden:

PHP:

function myenc($string) {
    for ($i = 0; $i < strlen($string); $i++) {
        $return[] = ord($string[$i]) + 2;
    }
    return implode(".",$return);
}

function mydec($string) {
    $string = explode(".",$string);
    for ($i = 0; $i < count($string); $i++) {
        $string[$i] = chr($string[$i] - 2);
    }
    return implode("",$string);
}

Deze werken wel goed, maar dan heb ik allemaal getallen en punten. Het zou mooi zijn als de punten eruit kunnen.

[RobIII]

RSD schreef op woensdag 04 maart 2009 @ 10:09:
Deze werken wel goed, maar dan heb ik allemaal getallen en punten. Het zou mooi zijn als de punten eruit kunnen.

Dan maak je er komma's van Pipe's ( | ) ?? Of het - teken? Of...

Waar wil je anders je parameters op gaan scheiden? En je beseft dat je daarmee meteen vast zit aan de volgorde van die parameters? Tenzij al je parameters een vaste lengte hebben zul je toch ergens onderscheid moeten maken tussen parameter A en parameter B

Je zou de meuk nog kunnen base64 encoden ofzo maar wie hou je dan voor de gek? Daarbij vervalt meteen elke $_GET die je gebruikt en moet je overal die variabelen handmatig uit je querystring gaan peuteren. Lekker handig

En dan de grote vraag voor de hoogfdprijs: waarom wil je überhaupt zoiets?

[ Voor 36% gewijzigd door RobIII op 04-03-2009 10:16 ]

[Little Penguin]

Ik dacht eerst dat je het aantal request wilde verlagen, maar het gaat om het aantal parameters.

Wat is het voordeel echter? Uiteindelijk zul je toch de variabelen moeten vullen en wat is er mis met het gebruik van de $_GET super global array?

[MBV]

Je zou ook het &-teken kunnen gebruiken om je variabelen te scheiden, dan kan je er direct de naam voor zetten zodat je weet waar het getal voor is

Vaak is een hele lijst van variabelen niet nodig: je moet er alleen in zetten wat je écht nodig hebt om de pagina weer te geven, bijv het artikelnummer. De artikelgroep, artikelnaam etc moet je dan weer uit de database halen. Dingen die voor de gebruiker specifiek zijn zet je in de sessie (want dat is afhankelijk van de sessie), en zoekopdrachten met veel parameter gooi je in $_POST (o.a. omdat er een maximumlengte zit aan $_GET).

Of wil je een soort van tinyurl maken? Dan zou ik eerder een aparte pagina www.example.com/tiny.php?p=481 (of www.example.com/tiny/481 via rewriting) maken, waarbij je de echte url uit de database haalt en redirect.

[ Voor 25% gewijzigd door MBV op 04-03-2009 10:45 ]

[BlackHawkDesign]

EDIT: serialize functie doet ook niet wat je wilt, had niet goed gecheckt van te voren..

[ Voor 88% gewijzigd door BlackHawkDesign op 04-03-2009 10:48 ]

[Voutloos]

Leuk, maar van serialize gaat het bepaald niet korter worden, als dat uberhaupt het doel is.

De echt vraag is toch 'Waarom wil je dat?'. Het opnoemen van een van honderd mogelijke PHP functies heeft echt weinig nut.

[ Voor 40% gewijzigd door Voutloos op 04-03-2009 10:49 ]

[RSD]

De redenen:
- geen lelijke urls
- mensen kunnen geen parameters in de url wijzigen
- het aantal GET's te verlagen (dit scheelt toch ook voor de performance, dus als je 1 grote variabele in de url meestuurt of 20 kleinere) Als ik livehttpheaders in ff gebruik dan zie ik namelijk een vrij lange header

Die base64_encode lijkt wel een leuke optie. Nu is mijn vraag. Is dat een zware functie of valt het wel mee? En eindigt een base64 encode altijd op 2 =-tekens? Zo ja, dan zouden deze er dus ook afkunnen of niet?

[ Voor 26% gewijzigd door RSD op 04-03-2009 12:50 ]

[Voutloos]

RSD schreef op woensdag 04 maart 2009 @ 12:48:
De redenen:
- geen lelijke urls

Echt veel mooier wordt het niet.

- mensen kunnen geen parameters in de url wijzigen

Onwaar, slechts security through obscurity in het beste geval

- het aantal GET's te verlagen (dit scheelt toch ook voor de performance, dus als je 1 grote variabele in de url meestuurt of 20 kleinere)

Maakt geen drol uit.

[ACM]

Voutloos schreef op woensdag 04 maart 2009 @ 12:51:
Maakt geen drol uit.

Dat moet je toch echt nuanceren. Juist de uploadsnelheid is doorgaans nog beperkt, dus als je kan voorkomen dat je request lang is, dan is dat alleen maar gunstig. Zeker als je bedenkt dat de request-uri ook vaak nog in de Referer meegegeven wordt en dus niet 1x maar meerdere keren opgestuurd kan worden.

Maar je moet het dan wel over significante verschillen in lengte hebben uiteraard, het wordt pas echt "erg" als door zo'n lange string de headers over de 1 tcppacket gaan.

[RobIII]

ACM schreef op woensdag 04 maart 2009 @ 12:57:
[...]

Dat moet je toch echt nuanceren. Juist de uploadsnelheid is doorgaans nog beperkt, dus als je kan voorkomen dat je request lang is, dan is dat alleen maar gunstig. Zeker als je bedenkt dat de request-uri ook vaak nog in de Referer meegegeven wordt en dus niet 1x maar meerdere keren opgestuurd kan worden.

Maar je moet het dan wel over significante verschillen in lengte hebben uiteraard, het wordt pas echt "erg" als door zo'n lange string de headers over de 1 tcppacket gaan.

IMHO gewoon microoptimalisaties en voor de TS gewoon totaal useless (en for all the wrong reasons wat ik zo uit het topic haal).

RSD schreef op woensdag 04 maart 2009 @ 12:48:
Die base64_encode lijkt wel een leuke optie. Nu is mijn vraag. Is dat een zware functie of valt het wel mee?

Echt, dude... wat ben je aan 't doen dat je op dit niveau zit te 'optimaliseren'?

RSD schreef op woensdag 04 maart 2009 @ 12:48:
En eindigt een base64 encode altijd op 2 =-tekens?

Nee, dat is een padding... verdiep je gewoon eens in de materie voor je vragen stelt...

[ Voor 34% gewijzigd door RobIII op 04-03-2009 13:01 ]

[Verwijderd]

Gebruik mod_rewrite. Dan krijg je in plaats van "www.mijnsite.nl/index.php?pagina=home&taal=en" -> "www.mijnsite.nl/en/home"
Vind google ook wel leuk.

Formulieren etc die post je gewoon.

[ Voor 8% gewijzigd door Verwijderd op 04-03-2009 13:01 ]

[Voutloos]

ACM schreef op woensdag 04 maart 2009 @ 12:57:
[...]
Dat moet je toch echt nuanceren

Die nuance zit al in de context, ik zie hier nog niet een compressie van het niveau Jan Sloot over de GET variabelen gehaald worden.

Je hele post is een waarheid als een koe, maar het lijkt me zeer onwaarschijnlijk dat ts netjes geprofiled heeft en hier een probleem gemeten heeft en daarom met deze 'optimalisaties' bezig is.

En in dit topic staat even zo goed geen reden om de werking van HTTP te ondermijnen en lekker het verschil tussen GET en POST te negeren...

[ Voor 13% gewijzigd door Voutloos op 04-03-2009 13:11 ]

[CyBeRSPiN]

Is POST geen optie dan?

[!null]

CyBeRSPiN schreef op woensdag 04 maart 2009 @ 13:05:
Is POST geen optie dan?

Ook mijn idee. Wil je mooie URL's die niet zomaar door de gemiddelde gebruiker te wijzigen zijn, gewoon POST.

[MBV]

RSD schreef op woensdag 04 maart 2009 @ 12:48:
De redenen:
- geen lelijke urls

Base64 encoded is echt veel lelijker. Zeg nou zelf, wat ziet er mooier uit? www.example.com/index.php?pageid=58 of www.example.com/index.php?P3BhZ2VpZD01OA==
Zoals je ziet wordt het met Base64 encoding zelfs langer dan het origineel

- mensen kunnen geen parameters in de url wijzigen

Maar 1 passende smiley: . Nou ok, deze passen eigenlijk ook wel:
base64 encode is GEEN encryptie, je kan het zelfs met 1 regel PHP en/decrypten Dus als het veiliger moet worden daardoor: forget it, dan doe ik gewoon een decode en encode.

- het aantal GET's te verlagen (dit scheelt toch ook voor de performance, dus als je 1 grote variabele in de url meestuurt of 20 kleinere) Als ik livehttpheaders in ff gebruik dan zie ik namelijk een vrij lange header

Zoals je al kan zien is base64 encoding daarvoor geen optie. Als je url www.example.com?123456789012345678901 is, geeft dat net zoveel overhead in het http-protocol als www.example.com?x=1&y=2&z=3&ab=1&ac=2. Die interpretatie wordt door php gedaan, voor de browser heeft het geen speciale betekenis (behalve dan in formulieren).

Die base64_encode lijkt wel een leuke optie. Nu is mijn vraag. Is dat een zware functie of valt het wel mee? En eindigt een base64 encode altijd op 2 =-tekens? Zo ja, dan zouden deze er dus ook afkunnen of niet?

Dat heb ik hierboven al beantwoord: het helpt niks. Ga eens kijken naar url rewriting, dan kan je van die nette urls krijgen als hier op tweakers.net.

POST is IMHO geen optie als je gegevens wilt opvragen. Als iemand een pagina wilt doorsturen via de mail, moet hij gewoon de URL kunnen copy/pasten, waarna een andere bezoeker dezelfde pagina (maar dan niet gepersonaliseerd) te zien krijgt.

[ Voor 6% gewijzigd door MBV op 04-03-2009 13:15 ]

[RSD]

Nee, POST is onmogelijk, omdat de urls verspreid worden. Aan de hand van de GET moeten gegevens opgehaald worden. Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

[Kettrick]

RSD schreef op woensdag 04 maart 2009 @ 13:19:
Nee, POST is onmogelijk, omdat de urls verspreid worden. Aan de hand van de GET moeten gegevens opgehaald worden. Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

De URL Rewriting optie die meerdere malen voorbij is gekomen maakt de URL een stuk korter en netter, hier zou ik zeker eens naar kijken!

[RobIII]

RSD schreef op woensdag 04 maart 2009 @ 13:19:
Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

Welke verschillen had je verwacht dan? Je dacht toch niet werkelijk dat het meetbaar*, laat staan merkbaar zou zijn?

* Tuurlijk wel, maar met een nihil verschil uiteraard.

[ Voor 8% gewijzigd door RobIII op 04-03-2009 13:33 ]

[YopY]

RSD schreef op woensdag 04 maart 2009 @ 13:19:
Nee, POST is onmogelijk, omdat de urls verspreid worden. Aan de hand van de GET moeten gegevens opgehaald worden. Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

Het zou misschien handig zijn om eens te kijken (of te posten) welke gegevens je precies doorstuurt via een GET-methode, en of deze hoeveelheid te verlagen valt. Ook is het handig om te kijken of het altijd 10 params is of in het extreemste geval (bijvoorbeeld met allerlei sorteeropties voor gegevens).

[MBV]

RSD schreef op woensdag 04 maart 2009 @ 13:19:
Nee, POST is onmogelijk, omdat de urls verspreid worden. Aan de hand van de GET moeten gegevens opgehaald worden. Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

Wat dacht je dan van mijn idee om een speciale korte link in de database op te slaan, soort van tiny-url?
Of van het idee om URL rewrites te doen? Dat scheelt vaak al heel veel, van:
gathering.tweakers.net/index.php?action=quote_message&id=31588107&something=0
naar:
http://gathering.tweakers.net/forum/quote_message/31588107/0

[_Sunnyboy_]

Url rewrites levert inderdaad mooiere url's op, maar is ook (marginaal) langzamer, aangezien de server de mooie url moet omzetten in de lelijke originele url alvorens hem naar php door te geven.

Voor de performance (of security) niet doen dus. Als het gaat om mooie urls, zeker iets om naar te kijken.

[link0007]

_Sunnyboy_ schreef op woensdag 04 maart 2009 @ 17:09:
Url rewrites levert inderdaad mooiere url's op, maar is ook (marginaal) langzamer, aangezien de server de mooie url moet omzetten in de lelijke originele url alvorens hem naar php door te geven.

Voor de performance (of security) niet doen dus. Als het gaat om mooie urls, zeker iets om naar te kijken.

weer een optimalisatie die helemaal niet gemaakt moet worden. Voor je server is het weinig moeite, waarschijnlijk <1% van de tijd die het php script snoept.

Dus laat je niet gek maken en besteed eens een paar uurtjes aan mod_rewrite syntax

[doeternietoe]

RSD schreef op woensdag 04 maart 2009 @ 12:48:
- mensen kunnen geen parameters in de url wijzigen

De URL is imho juist bedoeld om door mensen veranderd te kunnen worden. Nu zullen veel URL's unieke id's bevatten die veel mensen niet zullen begrijpen, maar het mag niet zo zijn dat er dingen fout gaan bij je webapplicatie als gebruikers aan de URL gaan sleutelen. En de beveiliging mag er al helemaal niet vanaf hangen, maar dat is haast vanzelfsprekend. Gebruik zoals gezegd mod_rewrite om mooie URL's te maken en controleer de invoer in de URL goed, zodat je op iedere mogelijke (foute) URL bent voorbereid en de gebruikers de juiste melding toont. (eventueel inclusief header, zoals 404 Not Found)

[!null]

@doeternietoe. Je hebt gelijk dat je totaal geen beveiliging op URL's moet baseren, en dat je mensen geen dingen stuk moet kunnen laten maken als ze met die URL's gaan klooien. Je moet een degelijk systeem maken, ben ik met je eens.
Maar aan de andere kant, ik ga nooit een applicatie schrijven waarin ik meeneem dat m'n URL's gaat zitten aan te passen. Als men foute dingen invult bij het zelf aan de URL klooien wat niet via een link of form binnen zou kunnen komen dan ga ik daar echt niet veel rekening mee houden. Bij degelijke inputcontrole hou je toch al het meeste tegen, en voor de overige zaken is het zonde van je tijd die je er in steekt. Mensen moeten het gebruiken zoals het bedoelt is.

Verder is de optimalisatie bij het verkleinen van de link niet erg nuttig denk ik, tenzij je van die ouderwetse marktplaats links heb (niet de nieuwe). De optimalisatie is iig niet sneller aan de serverkant, want die moet toch weer wat handelingen verrichten om weer bij het origineel uit te komen.

[RobIII]

GreenSky schreef op woensdag 04 maart 2009 @ 21:40:
Als men foute dingen invult bij het zelf aan de URL klooien wat niet via een link of form binnen zou kunnen komen

Assumptions are the mother of all f*ckups
Je beseft dat ik een POST (van een form) nét zo makkelijk kan vernachelen als ik daar zin in heb? GET of POST is in dat opzicht echt 0,0 boeiend.

Je moet gewoon al-tijd, no exceptions, ever, ever, everever, zaken die van de client komen, be it via GET of via POST, checken/controleren/sanitizen/whatever.

GreenSky schreef op woensdag 04 maart 2009 @ 21:40:
Bij degelijke inputcontrole hou je toch al het meeste tegen

Ik hoop dat je server-side controle bedoelt en geen 'javascript beveiliging' ofzo

GreenSky schreef op woensdag 04 maart 2009 @ 21:40:
en voor de overige zaken is het zonde van je tijd die je er in steekt.

True; ik kan bij Google ook de "q=" parameter veranderen naar iets willekeurig anders; ik krijg dan gewoon andere resultaten. Of ik dat nou invul via dat tekstveldje op google.com of via mijn adresbalk. Boeie.

GreenSky schreef op woensdag 04 maart 2009 @ 21:40:
Mensen moeten het gebruiken zoals het bedoelt is.

Uiteraard; maar daar zal een hacker lak aan hebben

[ Voor 58% gewijzigd door RobIII op 04-03-2009 21:57 ]

[Confusion]

RSD schreef op woensdag 04 maart 2009 @ 13:19:
Nee, POST is onmogelijk, omdat de urls verspreid worden. Aan de hand van de GET moeten gegevens opgehaald worden. Maar goed, ik kan het beter laten zoals het is denk ik, als er geen grote verschillen zijn.

Je tweede reden is er wel eentje die aandacht behoeft: als er problemen optreden wanneer mensen GET parameters aanpassen, doordat ze dan bijvoorbeeld het account van een ander kunnen zien of ingelogged kunnen zijn als administrator, dan heb je een veiligheidsprobleem dat je op moet lossen.

[RobIII]

Confusion schreef op woensdag 04 maart 2009 @ 22:08:
[...]

Je tweede reden is er wel eentje die aandacht behoeft: als er problemen optreden wanneer mensen GET parameters aanpassen, doordat ze dan bijvoorbeeld het account van een ander kunnen zien of ingelogged kunnen zijn als administrator, dan heb je een veiligheidsprobleem dat je op moet lossen.

GET/POST is niet relevant

[!null]

@RobIII, je hebt me niet goed begrepen denk ik. Zoals ik al zei dient je applicatie veilig te zijn tegen geklooi met de input. Het maakt idd niks uit of het POST of GET is, het is allemaal net zo makkelijk aan te passen. Dus je applicatie moet er tegen kunnen. Dat bedoel ik ook met input controle, waarmee ik uiteraard serverside bedoelde.

Maar een voorbeeld, als je nou een input veldje hebt, text type, welke voor een 1 of andere reden een max heeft van 10 karakters. En je zou het geheel via GET submitten. Ga jij dan controleren of de input wel max 10 lang is? Het gaat er niet stuk van (afhankelijk van je onderliggende DB server natuurlijk, maar MySQL bijvoorbeeld), alles wat er na komt wordt weggegooid. Ik ga daar niet op controleren hoor.
Er zijn wel andere voorbeelden, waarbij je bijvoorbeeld een hele uitgebreide foutmelding zou kunnen gaan maken voor een situatie die alleen via aanpassen van de parameters kan voorkomen. Laat het dan maar crashen denk ik dan. (met een simpele foutmelding en een terug mogelijkheid uiteraard)
GET is m.i. alleen maar omdat je je parameters, bepaalde informatie, onderdeel wilt laten zijn van de URL, zodat er naar te linken valt etc. Niet als UI.

En ik ken de uitrdrukking AITMOAF wel hoor

[Cartman!]

Als iets max. 10 karakters lang mag zijn dan moet je dat natuurlijk controleren. Een gebruiker moet gewoon een melding krijgen dat wat ie heeft ingevoerd niet voldoet aan de voorwaarden.

Kwam laatst in CommuniGate webmailclient ook iets moois tegen. Stond bij de instellingen een veld op disabled maar die wilde ik wel aanpassen. Met firebug de disabled eruit gehaald, veranderd en op Save gedrukt en tot mn grote verbazing werkte het nog ook. Altijd.alles.checken!

[RobIII]

GreenSky schreef op woensdag 04 maart 2009 @ 22:25:
Ga jij dan controleren of de input wel max 10 lang is?

Euh, ja Never, ever, trust user-input.

GreenSky schreef op woensdag 04 maart 2009 @ 22:25:
Ik ga daar niet op controleren hoor.

Jij niet; ik wel. Ik ben misschien meer paranoia dan jij, maar als ik een maxlen van 10 zet dat is er ook een maxlen van 10. En dus tolereer ik geen 11 of meer karakters. Simpel. Anders had ik net zo goed die maxlen weg kunnen laten. En het gaat vast ook bij jou goed en zal heus niet alles in het water vallen en vaak kom je er ook mee weg ook. Het is gewoon pure gewoonte bij mij en (IMHO) gewoon consequent zijn; dan vergeet je 't ook minder snel als 't een keer wél gecontroleerd moet worden. Beetje een zelf-opgelegde best-practice zeg maar (en nee, ik garandeer niet dat ik het in 100% van de gevallen doe; ik ben ook maar een mens en maak, sad but true, ook fouten ).

GreenSky schreef op woensdag 04 maart 2009 @ 22:25:
Er zijn wel andere voorbeelden, waarbij je bijvoorbeeld een hele uitgebreide foutmelding zou kunnen gaan maken voor een situatie die alleen via aanpassen van de parameters kan voorkomen.

Hoe je het afhandelt is een tweede. Alles na het 10e teken wegmikkeren of 6 pagina's helptekst uitpoepen... tja, dat is afhankelijk van je applicatie (en gebruikerstype )

[ Voor 17% gewijzigd door RobIII op 04-03-2009 22:40 ]

[!null]

@RobIII, ik tolereer ook niet meer dan 10 karakters in dat geval. Maar mijn DB laag flikkert toch alles wat te veel is weg, met een veldje van 10 breed in een MySQL DB (om even een voorbeeld te schetsen). Dan ga ik geen tijd stoppen in een foutmelding waarbij ik meld dat het te lang is en dingen worden weggegooid, wanneer mijn input veldje een maximale lengte heeft van 10, volgens de HTML standaard. De enige mogelijkheid om dan langere input te krijgen is geklooi met de GET/POST data, waar ik geen tijd aan ga besteden (aangezien je applicatie als het goed is al beschermt wordt tegen foute input met dingen als mysql_real_escape_string etc)

[RobIII]

GreenSky schreef op woensdag 04 maart 2009 @ 22:51:
@RobIII, ik tolereer ook niet meer dan 10 karakters in dat geval. Maar mijn DB laag flikkert toch alles wat te veel is weg, met een veldje van 10 breed in een MySQL DB (om even een voorbeeld te schetsen).

MSSQL geeft daar, terecht overigens, een "String or binary data would be truncated...blabla" op (in geval van ANSI_WARNINGS ON). Ik meen, maar pin me d'r niet op vast, dat dit bij SQL2000 uit stond en sinds SQL2005 en dus ook bij SQL2008 by default aan. *POEF* daar gaat je applicatie na een upgrade
En wie weet pakt MySQL 't vandaag of morgen ook niet meer zonder te mekkeren.

Het is geen ramp en de wereld zal heus niet vergaan; maar ik zie het wel als best-practice (of mijn eigen perfectionisme/mierenneukerij) om dat soort zaken gewoon voor te zijn

[ Voor 33% gewijzigd door RobIII op 04-03-2009 22:56 ]

[!null]

Daar moet ik je dan uiteraard weer gelijk in geven, helaas kan het gedrag van zulke applicaties wel eens veranderen. (ook wel eens goed als ik bijvoorbeeld aan PHP en register_globals denk )

[Verwijderd]

RobIII schreef op woensdag 04 maart 2009 @ 22:53:
MSSQL geeft daar, terecht overigens, een "String or binary data would be truncated...blabla" op (in geval van ANSI_WARNINGS ON). Ik meen, maar pin me d'r niet op vast, dat dit bij SQL2000 uit stond en sinds SQL2005 en dus ook bij SQL2008 by default aan.

Bij SQL2000 stond dat default gewoon (en m.i. terecht) aan, en voor zover ik me kan herinneren bij SQL 7 ook al.

[Janoz]

AFAIK was MySQL de enige die zonder ook maar enige vorm van waarschuwing delen van je data negeerde wanneer het niet in het veld past.

[Voutloos]

En dat doet mysql enkel met de default SQL_MODE. Nu is het hele backwards compatability concept SQL_MODE van mysql fundamenteel fout geimplementeerd, het is toch wel leuk als je applicatie ook op de strictere modes kan draaien. Juist iets als de 'mijn database gooit het wel weg'-houding zorgt ervoor dat ze bij mysql maar niet default stricter gedrag durven af te dwingen.

Lees: de dag dat mysql _altijd_ strict is mbt dit soort fouten, oftewel de dag dat jouw applicatie in vlammen op gaat, vier ik feest.

[ Voor 15% gewijzigd door Voutloos op 05-03-2009 09:24 ]

[!null]

Nou ja, ze kunnen altijd een warning geven natuurlijk. Maar nu ik me een half jaar met totaal andere dingen heb bezig gehouden weet ik eigenlijk niet of MySQL wel aan warnings doet. Lijkt me een goede tussen oplossing, want warnings kun je negeren (ook al is dat doorgaans niet verstandig).

Edit: Mijn applicatie gaat dan niet "in vlammen op", tenzij iemand zelf met GET of POST gaat lopen klooien. Dan crasht ie alleen maar met een database query error. Daar ga ik dus geen tijd in stoppen.
Maar verder is stricter altijd beter ja.

[ Voor 30% gewijzigd door !null op 05-03-2009 09:30 ]

[japaveh]

Persoonlijk controleer ik altijd de gebruikersinput op bijvoorbeeld een maxlength of andere eisen, om situatues van een veranderende DB-laag te voorkomen. Ik doe dat door een nette melding te genereren en terug te keren naar het formulier.

Wanneer er problemen ontstaan in een applicatie omdat een gebruiker een URL verandert, of een formulier via een clienside applicatie (firebug, web developer toolbar, etc) doelbewust aanpast dan genereer ik een error en schrijf die ook weg in een log om eventueel misbruik gemakkelijk te kunnen detecteren.

Het komt maar al te vaak voor, Cartman! geeft daarvan een goed voorbeeld, dat gebruikers bij informatie proberen te komen door een getalletje in de URL aan te passen.