Les messages d'erreurs stockés dans des fichiers, syslog, mail ou autre, contiennent le message d'erreur lui même, mais aussi les traces de la pile d'appel, et d'autres informations utiles. Vous pouvez indiquer ce que doit contenir le message exactement et de quel manière.

L'option messageLogFormat dans la section [error_handling] de la configuration indique le formatage du message d'erreur. Le formatage supporte des mots clés spéciaux : %date%, %ip%, %typeerror%, %code%, %msg%, %url%, %file%, %line%, %params%, %http_error%, \t et \n.

%params% indique d'afficher tous les paramètres de la requête HTTP. Cependant cela peut poser des problèmes de confidentialité, voire de sécurité, car certains paramètres peuvent être indésirables dans les logs, comme les mots de passes.

Pour l'éviter, vous pouvez retirer ce tag %params% de messageLogFormat.

Ou alors, vous pouvez indiquer quels paramètres il ne faut pas afficher, soit d'une manière général, dans la configuration, soit d'une manière particulière dans les contrôleurs.

Pour l'indiquer dans la configuration, indiquer la liste des noms des paramètres à obfusquer dans VsensitiveParameters@@ de la section error_handling. Par défaut :

[error_handling]
sensitiveParameters = "password,passwd,pwd"

Dans un contrôleur, vous indiquerez la liste dans une propriété $sensitiveParameters :

class passwordCtrl extends jController {

    public $sensitiveParameters = array('pwd', 'pwd_confirm');

    //...
}

Quand vous utilisez jForms, ce dernier informe automatiquement les paramètres correspondant aux champs <secret>.

Les détails des messages d'erreurs ne sont pas affichés dans le navigateur (sauf dans la debugbar si vous l'activez). Quand une erreur survient, Jelix affiche une page d'erreur générique avec le code HTTP 500.

Par défaut, il affiche la page lib/jelix/core/response/error.en_US.php. Vous pouvez fournir votre propre page d'erreur en copiant ce fichier dans app/responses/, et en le modifiant en adaptant le design à votre goût.

Notez que error.en_US.php est un simple script PHP. Vous pouvez donc écrire n'importe quel instruction PHP, "à l'ancienne". Cependant, ne faites pas appel aux objets Jelix, ils peuvent ne pas être présent, ou mal initialisé etc. Et ne cherchez pas à afficher le véritable message d'erreur, pour des raisons évidentes de sécurité et de convivialité. En fait, cette page doit être quasi statique. Gardez simplement les instructions echo déjà présente.

Les variables $HEADTOOP, $HEADBOTTOM et $BODYTOP ne sont pour le moment pas utilisées. $BODYBOTTOM contient un message d'erreur "tronqué" : il ne contient pas les détails. Une variable $BASEPATH est disponible, contenant le chemin de base de l'application pour les feuilles de styles etc. Notez que cette variable peut être vide en fonction de la nature de l'erreur (une erreur qui survient avant ou pendant la lecture de la configuration).

La page d'erreur peut ne pas être utilisée dans certains cas :

• quand une erreur fatale PHP survient
• quand une erreur survient pendant l'initialisation du framework
• quand le navigateur n'attend pas du HTML

Dans ce dernier cas, Jelix retourne un simple message texte, qui est configuré dans l'option errorMessage dans la section [error_handling] de la configuration.