Ik ben aan het proberen geweest om een soortgelijke regex te maken om user input op te schonen voor output. het lukt alleen niet echt en heb al verschillende dingen geprobeerd. Na een paar uur hacken ben ik bang dat ik me er een beetje blind op staar....de reeks van geprobeerde dingen is eindeloos maar hier een paar die redelijk lijken.
Wat wil je uiteindelijk met de output doen? Waar wordt deze voor gebruikt? En met welk doel voer je bovenstaande controle(s) uit?
Is dit bijvoorbeeld om ervoor te zorgen dat berichten in een soort van gastenboek geen HTML of andere ongein bevatten? In dat geval zou je de output ook op andere manieren onschadelijk kunnen maken binnen de "HTML context" zonder eisen te stellen aan de invoer.
Je kunt je invoer onschadelijk maken bij het weergeven door deze door de functie htmlspecialchars() heen te halen. Personen die een profiel invullen hoeven niet zelf regelovergangen te gaan typen als <br />. Nadat je htmlspecialchars() op de invoer hebt toegepast zou je de functie nl2br() (newline-to-break) kunnen toepassen op het resultaat, die effectief voorkomens van (\r)\n omzet in linebreaks (<br />).
Op deze manier leg je geen restricties op aan wat mensen kunnen invoeren, wat eigenlijk wel zo fijn is.
Oftewel: in plaats van het stellen van allemaal eisen aan de invoer, maak simpelweg de uitvoer onschadelijk.
Eigenlijk wil ik dat wel voor ik het op sla in de DB zodat ik me daarna niet al te druk hoef te maken om de output.... Daarom zet ik alle regelovergangen om in <br>. Verder hoeven gebruikers niks anders te gebruiken dan reguliere tekst en cijfers, punt, komma, dash en singlequote.
Het nadeel daarvan is dat je dit mogelijk weer terug moet veranderen als iemand deze informatie bij wil werken.
Het beste is meestal om de informatie zoveel mogelijk in zijn oorspronkelijke/rauwe toestand op te slaan en de wijzigingen die nodig zijn voor weergave zo laat mogelijk door te voeren, bijvoorbeeld pas op het moment dat je de gegevens op het scherm toont.
>> waarom zou ik dingen opslaan die ik niet gebruik?
Misschien omdat je later een ander systeem implementeert, waardoor je wél de originele input nodig hebt, of misschien wel om te kunnen constateren dat iemand bezig is geweest om je systeem te hacken.
>> en misschien kunnen we even terug naar de topic Thomas...;) De regex?
Die heb je dus wellicht niet (in die vorm) nodig. Dat is wat Thomas je probeer uit te leggen.
Mja dat probeerde ik je dus een beetje voor te spiegelen: de gekozen oplossing is niet erg praktisch omdat je je gebruikers een stramien oplegt over wat toegestaan is als invoer. Het is makkelijker om de uitvoer gewoon onschadelijk te maken...
Om terug te komen op je regexp: deze "werkt" waarschijnlijk niet omdat je niet heel je invoer matcht. Je kijkt enkel of er toegestane karakters in voorkomen. Om af te dwingen dat de gehele invoer bestaat uit jouw karakter-whitelist (wat mij dus nog steeds geen goed idee lijkt) moet je de gehele invoer matchen. Dit doe je door dat in je patroon aan te geven middels <delimiter>[color=#ff0000]^[/color]<je patroon>[color=#ff0000]$[/color]<delimiter>.
^ wil zeggen: match patroon vanaf het begin van de invoer
$ wil zeggen: match patroon tot het eind van de invoer
Ook zou ik mensen geen breaks laten typen. Dit is een weergave probleem wat ondervangen kan worden door nl2br(). Daarnaast zou je de expressie case-insensitive kunnen maken met de i-switch (toevoegen na je <delimiter>).
Maar je begeeft je al snel op een hellend vlak met zo'n beperkt karakter-repertoir. Karakters met accenten vallen al buiten de boot, dubbele punten en puntkomma's staan er niet tussen. Ga je dan elke keer karakters toevoegen als blijkt dat het toch handig is om deze toe te staan? Het is gewoon niet praktisch.
Een profiel: dus daarin gaat iemand waarschijnlijk zijn naam zetten.
Bij mij in het gezin zijn 3 namen met een accent op een letter.
Daarnaast zou iemand mogelijk iets met een bedrag willen noemen. Een Euro-teken zou dus zo maar kunnen.
En heel raar zijn de volgende tekens niet: de dubbele punt, de puntkomma. En een emailadres mag kennelijk ook niet opgeslagen worden?
Kortom: je sluit een heel stel tekens uit die volkomen onschuldig zijn, maar wel heel goed in een tekst kunnen staan.
Je verzint nu een beveiliging op de verkeerde plek.
De data die de bezoeker intikt, wil je zo rauw mogelijk in je database hebben. Bijvoorbeeld die Enter: als je daar direct een <br> van maakt, dan zit je dus met het probleem dat als hij de tekst nog eens wil bewerken, je de invoer vervuild hebt en dus die <br> weer naar een enter terug moet zetten.
Ook als je een email wilt maken van deze tekst, of een pdf of misschien wel een Excel-sheet, zit je met die <br> in je maag.
Kortom: je beperkt je nogal. terwijl braaf overal in combinatie met echo htmlspecialchars() gebruiken je probleem ook oplost.
