Formulier per regel verwerken

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2

Thomas van den Heuvel

Thomas van den Heuvel

03/11/2015 17:10:25
Quote Anchor link
Quote:
Dat zou best kunnen want het *is* niet voldoende, ook niet "in principe". De redenen daarvoor heb ik zojuist uitgelegd en die redenen zijn blijkbaar ook bekend bij de stackoverflow community en als ik deze reactie van jou lees dan weet jij het ook dondersgoed.

Deze stelling staat of valt met wat jij verstaat onder jouw "validatie". Als ik het heb over "input filtering" met als doel iets opslaan in een database, dan zorg ik natuurlijk dat de data ook geldig is voor dat doel. Als iets niet voldoet aan het format, ga ik niet eens een query uitvoeren.

Voorbeeld: als dit een query was waarbij je enkel gehele getallen in je database wilt zetten. Je komt niet succesvol door je filterroutine heen omdat er niet-numerieke waarden tussen zitten. Dan ben je klaar. Kom je hier wel doorheen, heb je dan escaping nodig (even los van of het verstandig is of niet)? Nee, dat is niet nodig.

Natuurlijk dienen "validatie" en "escaping" twee compleet verschillende doelen, dat bestrijd ik ook niet, maar dat is ook niet wat ik beweer.

Ik bedoel precies dit gedoe. Iemand doet een stelling en meteen rukt een leger moraalridders uit om deze neer te sabelen, zonder dat ook maar getracht wordt te doorgronden wat iemand bedoelt te zeggen.

Ik zeg nergens dat je deze aanpak (enkel filteren) moet gebruiken.
Ik predik nergens deze aanpak zelf.
Het geeft alleen aan wat het belang is van (wat je enkel met) input filtering (kunt bereiken).

Beschouw mijn stelling als troll bait.

Hook, line and sinker?

EDIT: Daarbij zie ik ook niet hoe het aantal mensen wat mij "corrigeert" er toe doet als ze allebei niet lijken te begrijpen wat ik probeer over te brengen.
Gewijzigd op 03/11/2015 17:17:58 door Thomas van den Heuvel
 
PHP hulp

PHP hulp

25/12/2024 06:57:33
 
Pg Vincent

Pg Vincent

03/11/2015 20:59:08
Quote Anchor link
Quote:
als dit een query was waarbij je enkel gehele getallen in je database wilt zetten. Je komt niet succesvol door je filterroutine heen omdat er niet-numerieke waarden tussen zitten. Dan ben je klaar. Kom je hier wel doorheen, heb je dan escaping nodig (even los van of het verstandig is of niet)? Nee, dat is niet nodig.


Ah, dus "in principe" betekent "als het gaat om integers die je ook echt direct in een query zet"?

Strict genomen is dat natuurlijk waar; een waarde die niet ge-escapet hoeft te worden die hoeft niet ge-escapet worden. In de praktijk heb je niets aan die wijsheid want je hebt geen manier om te garanderen dat de waarde na de validatie niet meer zal veranderen, laat staan dat je de juiste waarden in de query zet.

Je zou de kost moeten geven aan de programmeurs die het "sommige waarden hoef je niet te escapen" idee zo letterlijk hebben genomen dat ze in hun database classes aparte validaties hebben ingebouwd om waarden te analyseren op inhoud om te zien of ze wel of niet ge-escapet hoefden te worden.

Quote:
Ik bedoel precies dit gedoe. Iemand doet een stelling en meteen rukt een leger moraalridders uit om deze neer te sabelen, zonder dat ook maar getracht wordt te doorgronden wat iemand bedoelt te zeggen.

EDIT: Daarbij zie ik ook niet hoe het aantal mensen wat mij "corrigeert" er toe doet als ze allebei niet lijken te begrijpen wat ik probeer over te brengen.


Dus als twee mensen jouw "stelling" verkeerd interpreteren dan vind jij dat geen aanleiding om wat toelichting te geven? Dan gaan we nog een hoop van deze discussies hebben vrees ik. :-)
 
Peter K

Peter K

04/11/2015 07:41:38
Quote Anchor link
Pg Vincent op 03/11/2015 20:59:08:
Je zou de kost moeten geven aan de programmeurs die het "sommige waarden hoef je niet te escapen" idee zo letterlijk hebben genomen dat ze in hun database classes aparte validaties hebben ingebouwd om waarden te analyseren op inhoud om te zien of ze wel of niet ge-escapet hoefden te worden.


Dit lijkt me meer te vallen onder de categorie onkunde.

Een goede programmeur kan zelf bepalen voor zijn/haar script of er escaping dient te worden toegepast.
 
Pg Vincent

Pg Vincent

04/11/2015 10:59:57
Quote Anchor link
Quote:
Een goede programmeur kan zelf bepalen voor zijn/haar script of er escaping dient te worden toegepast.


Een goede programmeur *heeft geleerd* hoe dat moet, van andere programmeurs. Als die andere programmeurs onduidelijke, incomplete of zelfs foute adviezen geven dan leert de aankomend programmeur ook het verkeerde. Dat heeft niets te maken met kunde of onkunde van de leerling, maar met wat hem verteld is. Hij weet niet beter.
 
Peter K

Peter K

04/11/2015 11:51:20
Quote Anchor link
Pg Vincent op 04/11/2015 10:59:57:
Quote:
Een goede programmeur kan zelf bepalen voor zijn/haar script of er escaping dient te worden toegepast.


Een goede programmeur *heeft geleerd* hoe dat moet, van andere programmeurs. Als die andere programmeurs onduidelijke, incomplete of zelfs foute adviezen geven dan leert de aankomend programmeur ook het verkeerde. Dat heeft niets te maken met kunde of onkunde van de leerling, maar met wat hem verteld is. Hij weet niet beter.


Met onkunde duidde ik op: "iets niet kunnen, iets niet weten, onwetendheid".
https://nl.wiktionary.org/wiki/onkunde

Waar dit door komt is weer een heel ander verhaal.

Overigens wil ik voorstellen terug on-topic te gaan :)

Conclusie is dus:
Het is belangrijk om zowel server side als client side dergelijke problemen af te vangen.
 
Thomas van den Heuvel

Thomas van den Heuvel

04/11/2015 14:26:20
Quote Anchor link
Het nuanceverschil tussen "sommige waarden hoef je niet te escapen" en "sommige waarden hoeven in principe niet geescaped te worden" (omdat er niets te escapen valt) ontgaat je nog steeds.

Quote:
Een goede programmeur *heeft geleerd* hoe dat moet, van andere programmeurs

Hier zweeft een ongeschreven "die het beter weten" achter?

Het domste wat je kunt doen is dingen klakkeloos overnemen.

Quote:
Als die andere programmeurs onduidelijke, incomplete of zelfs foute adviezen geven dan leert de aankomend programmeur ook het verkeerde. Dat heeft niets te maken met kunde of onkunde van de leerling, maar met wat hem verteld is. Hij weet niet beter.

Je blijft maar hameren dat er (ik?) het verkeerde advies gegeven wordt, maar daarmee quote je alleen het deel van mijn reactie wat jou niet zint.

Vervolgens zeg ik namelijk:
Quote:
Ik zou het altijd beide / allemaal doen.

Daarbij bestaat er bij mij in ieder geval geen enkel mogelijk vreselijk misverstand over wat ik bedoel waarmee ik potentieel beginnende programmeurs het verkeerde pad opstuur, waarmee trouwens meteen bewezen zou zijn dat jouw strategie funest is.

Het is de verantwoordelijkheid van de programmeur om zelf dit soort afwegingen te maken, mogelijk geholpen door meer ervaren programmeurs die zouden kunnen helpen met argumenten voor en tegen. Ik kan je wel vertellen, het helpt meer als je zelf tot een zekere overtuiging komt dan dat deze je wordt opgelegd.
 
Ward van der Put
Moderator

Ward van der Put

04/11/2015 15:35:48
Quote Anchor link
Het gevaar van een welles-nietesdiscussie is dat die wordt geëxtrapoleerd tot een tegenstelling van twee tegengestelde uitersten. Daarvan is hier naar mijn smaak geen sprake. Het draait namelijk niet om de vraag óf iets moet gebeuren, maar vooral om de manier waarop:

• Het spreekt voor zich dat je input filtert en valideert. De vraag is alleen: hoe?

• Het spreekt voor zich dat je geen onveilige SQL-query uitvoert. De vraag is alleen: hoe?

Dan wordt duidelijker dat er meerdere wegen naar Rome leiden. Ervan uitgaan dat er maar één manier is om iets op te lossen, is waarschijnlijk de grootste fout die je als programmeur kunt maken. Het sluit namelijk betere, nog onbekende oplossingen bij voorbaat uit. Het beperkt je verder waarschijnlijk ook in de groei en ontwikkeling die alle goede ontwikkelaars doormaken: “Dat zou ik tegenwoordig heel anders doen...”

Toevoeging op 04/11/2015 16:30:36:

Ward:
Twee opmerkingen die op de persoon spelen, zijn verwijderd.
En die willen we liever niet nog een keer zien.
Graag nu weer inhoudelijk en beter nog on topic reageren.
Gewijzigd op 04/11/2015 15:40:14 door Ward van der Put
 

Pagina: « vorige 1 2



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.