Avant de développer vos CGI ...
1 - ERREURS
2 - PERL
3 - SCRIPTS CGI
4 - SECURITE
1 - ERREURS
Lorsqu'un script échoue dans son execution, on reçoit sur le browser
l'erreur :
"500 Internal Server Error - The server encountered an internal error
or misconfiguration and was unable to complete your request.-Please contact
the server administrator, root@big-bang.alian.fr and inform them of the
time the error occurred, and anything you might have done that may have
caused the error.)
Ce message n'est généralement pas très parlant, mais en gros il vous dit qu'il n'a pas pu répondre à votre requête, et il vous faut regarder les fichiers logs de la machine (access & error). Ces fichiers contiendront la sortie d'erreur des scripts CGI.
Mieux vaut faire un script qui lit le dernière erreur enregistrée, ou sous Unix tapez tail -f <nom_fichier_erreur>
Leur emplacement varie en fonction du système et de la plate-forme
:
Sous Unix, on peut avoir /var/log/httpd.access, /usr/local/httpd/log/access
, ...
Sous Windows jetez un coup d'oeil dans c:\winNT\system32\log
Attention : certains serveurs sous Windows95 n'ont pas
de fichier errorlog ....
Pour résoudre vos problèmes :
Testez le script sous le shell habituel avant de le
traiter au browser. Peut-être s'agit-il d'une erreur dans le source ?
Sous Unix, si le script répond "not found" en
faisant ./nom_du_script, deux solutions : le nom de l'interpréteur sur
la première ligne est non trouvé, sinon c'est le problème du passage de
Windows à Unix (Effectuer un dostounix sur le fichier).
Si le script se lance sans problêmes, vérifiez que vous générez
le bon entête MIME, c'est à dire que la sortie du programme doit
être :
print "Content-type: text/html\n\n":
Sinon, il s'agit sûrement d'une erreur sur les droits d'accès.
Vérifiez que votre serveur utilise les variables
d'environnement habituelles. Problème rencontré sous Windows95.
2 - PERL
Les variables qui ne sont pas déclarées en local sont par défaut
globales. Pensez donc à utiliser local() et my() qui fixent la portabilité
des variables. C'est un gain de mémoire et de temps de débuggage ! Pour
vous contraindre à l'utiliser systématiquement, utiliser
use strict;
Si l'utilisation des variables globales est faite, utilisez
une convention d'écriture pour les reconnaitre tout de suite !
ex:
$main ::GLOBAL{'NOM_VAR'}="bbbb";
ou beaucoup plus propre :
use strict; use vars qw($myvar1 $myvar2);
La fonction opendir(); n'est pas identique sous Windows et sous
Unix. Sous Windows, toutes les fonctions avancées touchant au système
d'exploitation ne fonctionne pas. (En particulier les fonctions réseaux,
fork, ...)
3 - SCRIPTS CGI
Un script CGI est par définition dynamique .... Eviter tout
de suite de coder des nom de fichiers ou d'images dans le source et proposez
une interface ou au moins un fichier pour configurer votre application
. Sinon, sa portabilité sur une autre machine va être impossible !
4 -SECURITE
La mise en place de CGI peut compromettre la sécurité du serveur Web (et par de là, le reste du réseau) sur lequel il est installé si certaines ne sont pas observée:
- Droits :
- Evitez un 777 sur les CGI ... ce serait comme laissez un shell ouvert.
- Limiter les répertoires ouverts en écriture qu'à certains fichiers ou certains répertoires bien déterminés et surveillés.
- Attention à l'espace disque disponible (le mieux mettre des quotas sur les répertoires concernés).
- Les CGI réservés aux administrateurs doivent être protégés par mot de passe, ainsi que ceux impliquant une grosse charge machine
- Variables utilisateurs ou externes :
Ne jamais faire confiance à un utilisateur :-)
Surveiller tout particulièrement tout ce qui touche aux appels systèmes (2 commandes au lieu d'une seule, buffer-overflow, ...). En Perl, un excellent moyen de contrôler ces variables est d'utiliser l'option -P. Toutes les variables externes au programmes sont rejetées si elles n'ont pas été contrôler. Cela est expliqué en détail dans perldiag
- Lire au moins une fois ce document:
