Locale

"Dus je accepteert zelf ook een ongeldige datum als input zolang daar maar een geldige datum uit af te leiden is. ;-) "

Ik moet hier even over nadenken.
...
...
..
O, op die wijze.
Nee, ik ken het simpele algoritme om op die manier een datum te berekenen.
Dat is geen verkeerde invoer. Dat is de correcte invoer die nodig is om met dat algoritme de juiste datum te berekenen.

:-)

@Paul
toch moet je niet blind uitgaan van "het komt van een jquery plugin en is dus goed".

Als je dat strikt doorvoert, zou je ook kunnen veronderstellen dat er *dus* ook geen ' of ander vervelend teken in voor kan komen.
En *dus* mag je het escapen achterwege laten.
Maar het is eenvoudig om zelf de waarden te kiezen om in te voeren in een POST request. Je hebt namelijk geen zekerheid dat een postend formulier ook werkelijk op jouw site stond.

Je stelt je kwestbaar op in zo'n geval, terwijl een controle in php niet heel moeilijk is.

@Ivo (hé, ik begin al geroutineerd te raken...)

Het dateert nog uit de tijd dat er geen rekenmachines, alleen telmachines, waren en rentekosten per dag werden gerekend. Negentig dagen krediet, dus de vervaldag is 90+21 juni is 111 juni is...etc.
Ik denk dat deze techniek na de Mammoetwet uit het curriculum is verdwenen.
Net als de tafel van 12 (dozijn, gros) :-)

[size=xsmall]Toevoeging op 21/06/2017 15:36:52:[/size]

@Ivo,

Blind vertrouwen zul je bij mij niet aantreffen.
Evenmin als strikte/rigide afregeling. :-) (wie mij kent schiet hier in de lach...)

Maar enig vertrouwen, vooral in onderdelen die erg veel gebruikt worden, heb ik wel.
Zo reken ik nooit op voorrang als ik van rechts kom.
Er wordt veel tegen gezondigd.
Maar ik houd niet echt rekening met de mogelijkheid dat iemand besluit links te gaan rijden.
Een mogelijk die wel degelijk voorkomt.

Kortom, ik vertrouw het veelgebruikte datumpikkertje van JQuery wel.
Evenals het gros van de PHP bibliotheek.
Maar als ik de werking niet begrijp, of als het erg ingewikkelde parameter overdrachten zijn zoals die met het doorgeven van het 'datumformat' voor een datuminterpretatie, dan word ik argwanend.

Het 'escapen' is inderdaad draak van een implementatieprobleem.
Dat de onderdelen van het PHPconglomeraat eigen eisen stellen, het doet pijn aan het brein.
Mr het moet. Vandaar die preMySQL()....

Dat van die dat postend formulier die niet om mijn webpagina staat vind ik wel intrigrerend.
Is dat mogelijk? Hoe werkt dat? (nieuwe draad?)

vrij simpel:

Ga naar een pagina op je website met een formulier.
Kijk in je browser naar de bron van de pagina. (in mijn browsers middels ctrl-U)

Sla dat op op je lokale pc. onder form.html (html, niet php)

Pas dan in die file <form action=""> aan naar <form action="http://site.nl/contact.php">
of waar het oorspronkele form ook maar naar verwees.

Dat is stap 1 (als er veel middels javacript gerommeld wordt, kan het zijn dat het niet direct werkt)

stap 2 is om van een input iets nieuws te maken.

Bijvoorbeeld
<select name="aantal">
<option value="1">1</option>
<option value="2">2</option>
</select>
En je wilt er 5 bestellen?

Voeg toe:
<select name="aantal">
<option value="1">1</option>
<option value="2">2</option>
<option value="5">5</option>
</select>

Of voeg toe:
<option value="ABC">xyz</option>

Wat nu? er staat ineens een string en geen getal....
Kan de php code daar tegen?

En wat als het "AB'C" is?

In plaats van de hele pagina kun je ook de htmlcode beperken tot alleen het formulier.
Alternatief: er zijn ook tooltjes die dat kunnen regelen.

Ik heb op mijn desktop een Advanced REST client staan.
Bedoeld om webservices te testen, maar daarmee zou je ook een ander formulier in kunnen vullen.

--
goed, er zijn manieren om te controleren of een formulier van jouw site komt. Bijvoorbeeld middels een extra token in een hidden input waarbij je bijhoudt of form recent is gedownload, evt. in combi met sessions.

Maar waar het mi. vooral om gaat: ga er niet vanuit dat je weet wat er gepost kan worden, omdat iets uit een <select> of een radiobutton oid. komt