escapen van een query string

Door Frank Nietbelangrijk op 26-10-2017 16:16 gewijzigd op 26-10-2017 16:18

3.209 views

In een ander topic is de vraag naar voren gekomen of een query string ook escaped dient te worden. Om dat topic niet helemaal te kapen en omdat deze vraag toch interessant is wil ik hier in dit topic graag verder discussiëren.

De vraag is dus: Kan ik in de output van mijn script het volgende plaatsen zonder (html) escaping:


<a href="index.php?lang=nl&aantal=12">homepage</a>

of is het beter om dit te escapen en dus het volgende als output te genereren:


<a href="index.php?lang=nl&amp;aantal=12">homepage</a>

Daarnaast:

Voor onveilige data moet ik natuurlijk htmlentities() gebruiken:
<?php echo $language; ?> vs <?php echo htmlentities($language;) ?>

Maar als een variabele veilig genoeg is (altijd een nummer of een tekst uit een whitelist) dan lijkt mij dat weer wat overkill.

Reacties zijn welkom :-)

Frank Nietbelangrijk

28-10-2017 09:57 gewijzigd op 28-10-2017 10:27

Hmm ik weet natuurlijk niet hoe goed jouw doehetzelf ding is maar ben dan toch geneigd te vragen om twig eens te proberen. Twig maakt cache bestanden aan waardoor het razendsnel wordt en wat ik persoonlijk ook erg fijn vindt aan Twig is dat je zelf twig functies kunt maken. Zo kun je bijvoorbeeld een bedrag() functie maken die een bedrag altijd netjes toont zoals je dat met number_format doet maar dan zonder al die parameters telkens.
Daarnaast zijn het gebruik van layouts en blokken in Twig echt geweldig. Maak 1x een complete html template met header, een lege content en footer en op alle andere pagina's include je die template en vervang je gewoon het blok content voor een nieuw blok met inhoud.

layout:


<!DOCTYPE>
<html>
<head>
        <meta charset="UTF-8">
        <title>{% block title %}Welkom{% endblock %}</title>
        {% block stylesheets %}{% endblock %}
</head>
<body>
        {% block content %}{% endblock %}
        {% block javascript %}{% endblock %}
</body>
</html>

homepage:


{% extends 'layout.html.twig' %}

{% block content %}
	<h1>Hi folks</h1>
{% endblock %}

- Ariën -

28-10-2017 10:04

Naast Twig bestaat er overigens ook nog Smarty die dezelfde capaciteiten heeft. Het processed de templates in PHP-bestanden voor snellere uitvoer via caching, maar kan ook bepaalde data op de manier zoals de developer wilt gaan cachen.

Maar de echte snelste template-parser blijft PHP himself. ;-)

Frank Nietbelangrijk

28-10-2017 10:14

Zoals Ariën al aangeeft zijn er een aantal template engines. Een Laravel gebruiker zal waarschijnlijk weer Blade roepen als template engine. Ik heb zelf alleen ervaring met Twig en ben daar enthousiast over. Hetzelfde geldt voor Ariën met Smarty denk ik.

- Ariën - op 28/10/2017 10:04:52

Maar de echte snelste template-parser blijft PHP himself. ;-)

Maar dat gaat dan wel weer ten koste van automatic escaping waardoor we uiteindelijk op template engines uit kwamen ;-)

Ik ben van mening dat je een template engine moet gebruiken. Redenen zijn:
- automatic escaping
- separation of concerns
- makkelijk te hanteren voor front-developers
- makkelijker werken met layouts
- toegevoegde template functies

[size=xsmall]Toevoeging op 28/10/2017 10:20:00:[/size]

[edit]
@Ariën: Klopt het dat Smarty niet automatisch escaped? Dat zou toch een behoorlijk nadeel zijn ...

Ik las dat je {$var | escape} moet schrijven in Smarty alvoor je output escaped wordt ?

R Rob Doemaarwat

28-10-2017 11:58

De voornaamste reden dat ik aan m'n doe-het-zelf ding vasthoud is ivm het switchen tussen talen (vertalingen). Meestal heb ik een template (de HTML kapstok) die voor alle talen gelijk is. De invulling (de tekst) is taalspecifiek (en soms ook nog weer klant/gebruiker specifiek = CMS, uit database). Binnen zo'n taal moet je echter ook weer naar een stukje template kunnen verwijzen, of naar andere talen (soms is een obscuur stukje content bijvoorbeeld (nog) niet beschikbaar in de gekozen taal, en dan verwijs ik van daaruit weer naar de default taal).

Ter illustratie:


//template (taal neutraal)
<div>##header##</div>
[@content] //hier wordt de taalspecifieke content ingevoegd
</div>##footer##</div>

//content (in taal gebruiker)
Hallo [naam],
[@meerContent.en] //verwijs naar meerContent in het Engels
[@banner.__] //voeg banner template in
Het is vandaag [datum|date()], enz.

//banner (taal neutraal)
<div id='banner'>
[@bannerContent] //banner tekst in taal gebruiker, enz
</div>

(de [@content] verwijzing is nu fixed, maar uiteraard kun je die ook flexibel maken (template extenden ala Twig))

Reageren

Inloggen om te reageren