Erreurs courantes

Introduction

Certaines erreurs reviennent très fréquements sur les forums, et sont liées a une mauvaise utilisation de la syntaxe, ou a une incompréhension de certains mécanisimes. J’ai donc regroupé ici quelques unes de ces « erreurs » les plus fréquentes.

echo "$MaVar"

Pour l’affichage du contenu d’une variable, certains codent de la manière suivante :
echo "$MaVar"

Ce qui n’a fondamentalement aucun sens (même si cela fonctionne), la syntaxe correcte étant :
echo $MaVar

Lorsque l’on utilise la première syntaxe, avec les guillemets, on oblige l’interpréteur php a effectuer une analyse de la chaîne, pour trouver la variable qu’elle contient. C’est une opération supplémentaire, qui n’apporte rien dans le cas ou l’on souhaite n’afficher qu’une variable. En revanche, il peut être utile d’écrire : echo "Mon nom est $Nom".

echo "<table width='100%'>"

Ici aussi, le choix des ' et des " est mal venu, pour deux raisons :

on génére du code html avec des ‘, alors que seuls les "" sont autorisés en html, les ‘ n’étant que tolérés
on oblige l’interpreteur a analyser le contenu placé entre "" , alors qu’il ne contient aucune variable php

La syntaxe correcte serait : echo '<table width="100%">'

Non-utilisation de $HTTP_POST_VARS

Php permet de récuperer les valeurs soumises par un formulaire html de deux manières :

directement, en utilisant le nom du champs : echo $NomChamps ;
en utilisant $HTTP_POST_VARS : echo $HTTP_POST_VARS[‘NomChamps’];

L’utilisation directe du nom du champs présente plusieurs problèmes :

elle ne permet pas, dans le code, de distinguer facilement les valeurs qui ont été déclarées au fil du script des valeurs qui proviennent d’un post utilisateur. En utilisant $HTTP_POST_VARS systématiquement, on voit clairement a quel niveau sont utilisés les valeurs soumises par l’utilisateur
la possiblité de les utiliser depend d’un paramètre du php.ini. Pour des raisons de sécurité, ce paramètre qui était auparavant a "on" est depuis quelques versions de php positioné a "off". On peut donc considérer qu’a moyen terme, les hébergeurs passeront a "off", il ne sera plus possible d’utiliser directement les noms

Utiliser les varvar

Les varvar sont une particularité de php qui permettent d’utiliser la syntaxe suivante :

$MaVar1 = "Toto";
$MaVar2 = "Titi";
$VarVar = 'MaVar1';
echo $$VarVar // Affiche "toto"
for($I=1 ;$I<3 ;$I++)
{
$VarVar = 'MaVar' . $I ;
echo $$VarVar // Affiche successivement "Toto" puis "Titi"
}

Php se comporte donc comme s’il commençait par faire un « eval » de $VarVar, il trouve 'MaVar1', puis il fait un $'MaVar1', ce qui revient a $MaVar. La boucle permet de faire défiler $MaVar1 et $MaVar2.

Si cela peut a priori sembler une bonne idée, cela possède l’énorme inconvénient de rendre le code très très peu lisible, dans le cas ou sa complexité dépasse le petit exemple cité.

Il convient donc toujours, quand on a une problèmatique du type « stockage de différentes variables » d’utiliser les tableaux php :

$Tab[1] = "toto"
$Tab[2] = "Titi"
echo $Tab[1] ;
for($I=1 ;$I<=count($Tab) ;$I++)
{
echo $Tab[$I]
}

Outre le fait que le code devient plus lisible, on remarque aussi l’avantage de pouvoir utiliser la fonction count(), qui permet, si l’on ajoute un élément dans le tableau, qu’il soit automatiquement affiché par la suite.

Faire des redirections javascript

Il est possible d’effectuer des redirections d’au moins 2 manières :

en utilisant javascript : <script>window.location=NvPage.php</script>
en utilisant les header : header(‘location :NvPage.php’);

L’utilisation d’une redirection javascript présente l’énorme inconvénient de neutraliser définitivement la fonction « back » du navigateur. Il n’est plus possible de revenir en arrière a l’aide des fonctions standard de navigation. C’est un problème très génant, dans la mesure ou cette fonction est fréquemment utilisée.

En général, on en arrive a utiliser une redirection javascript lorsque l’on n’a pas réussi a utiliser la fonction header, l’erreur étant généralement : "Warning: Cannot add header information - headers already sent by ...". Cette erreur signifie simplement que l’on a placé la fonction header après avoir envoyer du texte au navigateur (un espace ou un retour chariot, même dans un fichier inclut, suffit a provoquer cette erreur)

Coder les chemins d’accès en « dur »

Le langage HTML permet de coder les chemin d’accès (liens hypertexte, images) de plusieurs manières :

En absolu complet : <img src=http://mawel.free.fr/images/logo.gif>, l’adresse est complétement indiquée
En relatif par rapport au serveur : <img src=/images/logo.gif>, le navigateur tente de trouver l’image dans le dossier images de la racine du serveur courant
En relatif par rapport a la page courante : <img src=images/logo.gif>, le navigateur tente de trouver l’image dans le repertoire images situé dans le répertoire courant

La premiere méthode est a proscrire ! si le site change de nom de domaine, ou si l’on passe tout simplement du serveur de développement au serveur d’hébergement, tous les liens et les images sont cassés. Cette méthode ne doit être utiliser que si l’on fait un lien vers une ressource externe (un autre site web, ou une image se trouvant sur un autre site web).

La seconde méthode ne doit être utilisée que pour accèder a des ressources que l’on sait partagées sur l’ensemble du serveur. Par exemple, sur un intranet, si on utilise le logo de la societe sur toutes les pages, autant le stocker sous la forme : « /images/logo.gif ».

Enfin, la troisième méthode doit être utilisée a chaque fois que c’est possible, c’est la plus souple, elle permet de déplacer des répertoires entiers sans avoir a se soucier de leur emplacement dans le reste du site. A noter que cette methode permet une navigation complete dans les répertoire, par exemple pour la structure suivantes :
Intranet\Articles // Les articles, dans des pages html
Intranet\Images // Les images des articles
Dans une page du fichier Articles, on utilise : <img src=../Images/MonImage.gif> pour accèder a une image, et <a href=Article2.html> pour effectuer un lien vers un autre article.

Passer au client des informations que l’on souhaite récuperer

Une question revient souvent sur les forums : la possibilité de crypter de manière réversible des informations. Dans la quasi totalité des cas, cette demande est effectuée pour « proteger » des données que l’on souhaite transmettre au navigateur web, pour ensuite les récupérer.

Ce type de problématique reflète d’une incompréhension des processus fondamentaux du fonctionnement du couple Serveur Web/Navigateur web.

Dans ce couple, il convient de rappeler deux principes :

on contrôle intégralement le serveur et les données qui s’y trouvent
on ne contrôle en rien le navigateur et les données qui s’y trouvent

En clair, toute donnée en provenance du navigateur web est non controlable et donc potentiellement suspecte. Ni javascript, ni un cryptage quelconque ne permet d’assurer leur integrité.

Ce problème peut être particulièrement grave dans certains cas. Sur certains sites marchand, on voit des url du type :
http://www.sitemarchant.com/AjouterPanier.php?CodeProduit=157&Qtt=10&Prix=1500

Ce type d’url présente un danger majeur s’il est traité directement ! N’importe qui peut très bien modifier l’url en :
http://www.sitemarchant.com/AjouterPanier.php?CodeProduit=157&Qtt=10&Prix=15

Le prix unitaire de 1500€ devient alors 15€. Si ces données sont ensuite utilisées directement pour éditer le bon de commande, l’utilisateur peut commander n’importe quel article a n’importe quel prix.

- Il faut donc retenir que :

Les données envoyées au navigateur ne doivent être utilisées que pour l’affichage dans le navigateur. Dans le cas précédent, il faudrait utiliser : http://www.sitemarchant.com/AjouterPanier.php?CodeProduit=157&Qtt=10, puis ensuite rechercher le prix du produit pour générer le bon de commande
Les données reçues du client doivent toujours être testées pour déterminer leur validité avant de les utiliser dans des traitements

Placer des « @ » dans ses fonctions

Le « @ » placé dans une fonction permet d’indiquer à php qu’il ne faut pas afficher de message d’erreur si la fonction en provoque un.

Bien utilisé, le « @ » permet d’éviter l’affichage de messages sur certaines fonction ou php est un peu trop pointilleux. Ce cas est extrenement rare.

Mal utilisé, il masque les erreurs contenues dans la page, et empêche de trouver l’origine d’un problème.

Le fait de placer un « @ » devant une fonction implique systématiquement de traiter manuellement l’erreur, pour savoir ce qui se produit.