Les erreurs à éviter dans une application web PHP – partie 10

Dans l’article n°1 nous avons vus la liste des erreurs de développement les plus communes rencontrées dans les applications webs PHP.

Dans les articles suivants nous allons revenir sur chacune d’entre elles avec un peu de détails quand celà est nécessaire.

9) Utiliser ‘exec’ à mauvais escient

Un jour vous petit développeur découvrez Unix et sa variante gratuite Linux. Et là c’est le début de l’émerveillement : « Oh comme c’est bien fait, vache c’est pratique … ». Le danger vient du développeur fainéant qui va considérer le système dessous lui comme un magnifique couteau suisse à tout faire et à surtout à gagner du temps.

C’est vrai que coder une librairie qui liste les fichiers d’un répertoire et les tri par date de dernière modification ça prend un peu de temps. Alors c’est tellement plus facile de faire ça :

Et encore ça c’est la bonne forme. On la trouve souvent sans le ‘die’ ou sans le chemin complet vers ‘ls’ 🙂

Et alors ? Le dev à été fait dans les temps et puis ‘ça marche’ non ? mouais …. Je reviendrai dans un autre article sur le ‘ça marche’. Mais sachez que :

  • C’est un trou béant de sécurité
  • C’est une grave atteinte aux performances de votre application
  • Mais surtout c’est in-maintenable !

La sécurité car on peut passer n’importe quoi à $dir par exemple ‘ /tmp; cat /etc/passwd’ et ooops !!! On peut aussi remplacer ‘ls’ par un binaire qui fait autre chose que ce qui est prévu (c’est heureusement limité par les droits de l’utilisateur qui fait tourner votre serveur web).

Les performances car vous créer un processus supplémentaire qui va dupliquer tout l’environnement et le contexte de son père et consommer des ressources pour rien qui seraient mieux ailleurs. Aussi car derrière vous devrez parser le retour sous forme de texte ce qui va vous prendre au final plus de ressources que si vous l’aviez fait nativement.

C’est in-maintenable car le format de sortie de la commande peux changer, la langue du serveur ou de l’utilisateur peux changer et son comportement être différent selon différents critères. Il faut aussi penser à parser le canal d’erreur pour être sur que les résultats sont ceux attendus.

Bref vous l’avez compris il vaut mieux au final coder un simple lib qui fait toute les vérifications d’usage que de sombrer dans la paresse et utiliser ‘exec’ dans tous les sens.

Le plus souvent quelqu’un l’a déjà codé pour vous et vous n’avez pas besoin de ré-inventer la roue. Exemple.

Quelques exemples sympas de ce qu’il ne faut pas faire :

  • exec(‘tail -f mylog.txt | grep pattern’)
  • exec(‘php -f « my-php-lib.inc »)
  • exec(‘while true; do ls -1; done’)
  • exec(‘xlogo’)

Ces exemples sont tirés d’histoires vrais 🙂

Frederic pour webofmars

No comments

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.