Les mystères du &cHash
Par kasper[YEAR]@typo3.com
Le paramètre &cHash des plugins frontend a dû dérouter un certain nombre de développeurs, cependant, cet article va expliquer comment cela fonctionne et ce qu'il faut éviter afin de développer des plugins TYPO3 performants et fiables.
Public visé
Les développeurs de plugins frontend TYPO3 et toutes les personnes qui pensent que le hash est quelque chose qui se fume.
Les principes du caching
Le principe de base du caching consiste à passer du temps pour générer le contenu d'une page une seule fois et ensuite, fournir cette même réponse à la même requête les fois suivantes.
Pour les sites web cela signifie que l'on utilise les ressources serveur une seule fois et qu'ensuite on fournit le résultat d'une page à chaque fois qu'un internaute visualise cette page avec les mêmes paramètres.
Caching de base des pages dans TYPO3
Lorsqu'une page est appelée dans TYPO3, le paramètre &id est utilisé pour identifier la page. TYPO3 va commencer un process qui va générer le contenu de la page à partir de tous les éléments qui la composent. Ce process prend des ressources au serveur web. Lorsqu'un nouvel utilisateur appelle cette même page, pourquoi ne pas afficher le résultat de son dernier affichage? C'est ce que nous faisons lorsque nous mettons en cache les pages avec TYPO3, ceci préserve les ressources du serveur et accélère le temps de génération des pages. Les pages générées sont stockées temporairement dans la base de données, dans la table “cache_pages”.
Cependant, TYPO3 permet à un même id de page de générer différents résultats basés sur plus de paramètres que le seul id de la page. Par exemple, le paramètre “&type” est directement supporté par TYPO3 dans ce but (habituellement pour générer des sites avec frames). Alors le mécanisme de cache doit stocker deux pages différentes quand “?id=123” ou “?id=123&type=1” est appelée. En d'autres termes, une page mise en cache doit être identifiée par une combinaison de variables.
“Snakes in paradise”
Une solution facile pour la mise en cache serait d'identifier simplement une page par son url. Alors, quand quelqu'un demanderait “?id=123” ou “?id=123&type=1” nous ferions un cache md5 de ces urls et utiliserions ceci pour retrouver la page les fois suivantes.
Ceci offrirait les bases pour une attaque DoS majeure. Qu'arriverait-il si quelqu'un requêtait un million d'url avec des paramètres aléatoires comme “?id=123&USELESS_PARAMETER=[nombre aléatoire]” - cela spammerait notre base de données avec des gigabits d'instance de la même page !
Emprisonner les démons...
La solution à ce problème est de mettre en cache uniquement lorsque les paramètres envoyés sont valides. Donc, dans la réalité, TYPO3 va mettre en cache la page “?id=123&USELESS_PARAMETER=[nombre aléatoire]” sous la même identification que la page “?id=123” parce que le paramètre USELESS_PARAMETER n'est pas connu par TYPO3 et le contenu de la page est le même. La raison pour laquelle “?id=123” and “?id=123&type=1” seront mise en cache en tant que page différentes est que TYPO3 est hard codé pour reconnaître le paramètre“&type” comme générant des pages différentes. De plus, la valeur de “&type” est vérifiée – la paramétrer à “&type=987654321” ne spammera pas la table des caches tant qu'aucune valeur “typeNum” ne concordera avec le gabarit Typoscript.
... mais pas vous
Cependant des développeurs veulent utiliser des variables GET dans leurs plugins qui ne seront pas ignorées par le mecanisme de caching TYPO3. Par exemple, un plugin trouvé sur la page 566 peut vouloir utiliser le paramètre “?id=566&tx_myext[uid]=44” afin d'afficher la vue fiche de l'article n°44 alors que la page “?id=566” affiche par défaut la liste complète. Mais parce que la variable GET “tx_myext[uid]” est inconnue du core TYPO3, la page sera mise en cache uniquement sur la base de l'id de page – ce qui n'est pas suffisant si vous avez plus d'un article d'actualité !
Il y a trois solutions à ce problème :
&no_cache=1 (basse): Chaque lien invoquant plus de paramètres que l'id de page doit contenir “&no_cache=1” en supplément, cela désactive la mise en cache de la totalité de la page. Dans ce cas il est facile de créer des contenus personnalisés basés sur des variables GET cependant les performances sont médiocres car la mise en cache n'est pas appliquée.Exemples:
USER_INT (moyenne): Donner le type USER_INT à son plugin. Dans ce cas la page est mise en cache une seule fois avec une zone d'attente qui est substituée par le contenu du plugin qui, lui, est généré dynamiquement à chaque requête. Ceci met en cache les parties statiques de la page mais continue d'appeler le process du plugin.
Avec ces solutions “?id=566” sera utilisée pour la mise en cache par le système pendant que “&tx_myext[uid]=44” sera utilisé dynamiquement dans le plugin ceci prenant effet dans le rendu final.
Cette solution est beaucoup plus flexible parque vous n'avez pas à vous inquiéter de la mise en cache et des paramètres. Elle est recommandée pour les fonctionnalités en temps réel et les contenus de type plugins de recherche, formulaires de réservation, pages de paramétrage utilisateurs...
Exemples:&cHash (haute): Chaque lien invoquant plus de paramètres que l'id de page doit contenir Exemples:
