Vous entendez souvent parler de "register_globals" ou de "safe_mode" dès que vous commencez à utiliser certains modules. Ces thermes peuvent vous sembler incompréhensibles voir carrément obscurs. Ils sont en fait liés à la programmation des modules ainsi qu'à php. Php étant le "programme" qui côté serveur execute les scripts qui composent Xoops. Vous pourriez rapidement vous dire que ca ne regarde que les programmeurs mais ca n'est malheureusement pas uniquement leur "problème". Tout le monde est concerné, les programmeurs, les utilisateurs et les hébergeurs.

Pour comprendre les choses, il va falloir expliquer d'autres "choses".
Tout d'abord, dans un système dynamique tel que Xoops agissant en relation avec l'utilisateur, il est nécessaire que Xoops (ou ses modules) "communiquent" avec l'utilisateur. Pour communiquer, ou plus tot pour échanger des informations
avec l'utilisateur, il y a deux façons de procéder :

1) Utiliser des formulaires (lorsque vous postez une question sur un forum par exemple, vous utilisez un formulaire). Auquel cas toutes les zones de saisie que vous remplissez sont nommées.

2) Passer des informations sur l'URL. L'URL étant l'adresse du script avec des paramètres. Prenons le cas de l'adresse suivante :
http://www.xoopsfr-forum.net/userinfo.php?uid=2368

Elle contient plusieurs informations :
1) Le type de "protocole" (http) utlisé afin qu'un dialogue s'établisse entre votre navigateur et le serveur que vous appelez.
2) L'adresse du site que vous souhaitez joindre ainsi que la manière dont les informations doivent être transmises. En l'occurence vous souhaitez joindre le forum de Xoops France et récupérer des pages au format html (www).
3) L'URL contient aussi le nom d'un script, userinfo.php suivit de ?uid=2368
Cette dernière information permet de passer un paramètre au script, en l'occurence, vous lui passez une information nommée uid (pour User Id, ou Identifiant d'utilisateur) suivi de la valeur de cette information à savoir 2368

Jusqu'à une certaine version de Php, ces informations passées aux scripts étaient directement visibles, lisibles, crées et utilisables à l'intérieur des scripts. Pour reprendre l'exemple de cette adresse :
http://www.xoopsfr-forum.net/userinfo.php?uid=2368
Le script userinfo.php dès sa création en mémoire avait "conscience" d'une variable qui s'appelle uid et qui contenait la valeur 2368.

Une variable n'est autre qu'un emplacement de la mémoire de votre ordinateur disposant d'un nom. Ces variables permettent de stocker temporairement de l'information.

Pour prendre une analogie, c'est comme si vous étiez tranquillement assis chez vous et que votre facteur vous apporte votre courrier et qu'en plus, il vous le lise. Vous évitant à la fois d'aller le chercher dans la boite aux lettres et de l'ouvrir pour le lire.

Cette possibilité offrait aux programmeurs, et contrairement à d'autres languages, une très grande souplesse de programmation, il n'y avait en effet rien de particulier à faire pour récupérer les informations passées par l'utilisateur. Elles étaient là et existaient directement !

Le problème est que ce type de procédé peut entrainer des failles de sécurité importantes. Toujours pour garder mon analogie avec le facteur, en plus d'être au courant de vos petites affaires, il peut vous raconter n'importe quoi, et c'est là le point le plus important.

Afin d'éviter ce genre de problèmes, il a été décidé par l'équipe de Php que cette facilité d'utilisation et de programmation serait abandonnée. A la place, c'était maintenant au programmeur (et donc au script) d'aller chercher les variables transmises par l'utilisateur dont il avait besoin. Non seulement le script doit aller les chercher mais il doit aussi les nommer lorsqu'il va les chercher.

Sans trop rentrer dans tous les détails, il y a deux manières différentes de récupérer les informations passées par l'utlisateur, selon qu'elles sont passées par les formulaires (méthode Post) ou passées par les URL (méthode Get)

De ce fait, en plus de devoir aller chercher les variables tout en indiquant leur nom, les scripts doivent aussi spécifier si ce sont des variables provenant d'un formulaire ou provenant de l'adresse du script. Donc par exemple, pour récupérer la variable uid (de mon précédent exemple) et passée dans l'URL, il faut faire : $_GET['uid']
Par contre, si cette information avait été passée par l'intermédiaire d'un formulaire, il aurait fallu utiliser : $_POST['uid']

Cette nouvelle manière de procéder est très efficace pour les problèmes de sécurité mais se posait le problème des scrips qui avaient été développés et qui tournaient déjà depuis longtemps. La question simple que tout le monde se posait était "Comment faire pour que ces scripts fonctionnent toujours ?" La solution a été rapidement et simplement trouvée.

Php, comme pas mal d'autres logiciels, dispose d'options. Ces options permettent d'agir sur le comportement du logiciel, de changer sa manière de fonctionner. Dans le cas de php, les options sont modifiables dans un fichier qui s'appelle php.ini
Ensuite, pour activer ou désactiver ce "nouveau" comportement de php, il faut agir sur l'option (ou la directive) qui s'appelle register_globals. Si cette option est positionnée sur On, register_globals=on, votre serveur travaille alors, à "l'ancienne", les scripts n'ont rien à faire pour connaitre les informations des utlisateurs. Par contre, si cette valeur est sur Off, soit register_globals=off, le script doit aller les chercher avec la méthode que j'ai expliqué précédemment.

Nous avons parlé des programmeurs, des programmes et des utilisateurs, parlons maintenant des hébergeurs. Ces derniers, par mesure de sécurité (et c'est tout à fait compréhensible), désactivent parfois cette option. C'est pourquoi, parfois, certains scripts ne fonctionnent pas alors "qu'ils marchaient avant".

L'équipe de développement de Xoops à décidé de prendre comme règle que tous les scrips doivent être en mesure de fonctionner avec la directive register_globals=Off. Permettant ainsi une compatibilité avec les hébergeurs les plus rigoureux et autorisant ainsi un niveau de sécurité plus élevé.


Après avoir levé ce premier "mystère", et maintenant que nous avons levé le voile sur certaines "parties" de php, nous allons maintenant parler de la directive safe_mode
Rassurez vous, comme certaines bases ont été posées, les choses iront plus vite.

Un script php, a la possibliité d'agir sur le serveur. Il peut par exemple créer, supprimer ou renommer des fichiers. Le problème est que si vous arrivez à détourner un script php, vous pouvez alors faire n'importe quoi sur le serveur qui l'héberge. Cela peut se traduire par une prise de controle quasi complète du serveur ou, comme nous l'avons déjà vu dans le passé, par des sites dont les pages ont été supprimées ou modifiées. L'une des manières de limiter les dégats potentiels, est d'agir sur une autre directive de php, celle ci s'appelle safe_mode. Elle accepte elle aussi deux paramètre, On ou Off.

Lorsque safe_mode est sur On, le script php en cours d'execution ne peut "agir" que sur le répertoire dans lequel il se situe.

C'est un peu comme si vous aviez un chien à la maison et qu'il devienne subitement fou. Soit vous lui laissez la possibilité d'aller dans toutes les pièces de la maison afin qu'il puisse tout détruire (safe_mode=off), soit vous lui limitez l'accès de la maison au garage uniquement (safe_mode=on)....

Cette directive ne fait par contre, et à ma connaissance, preuve pour l'instant d'aucune recommandation de la part de l'équipe de développement de Xoops. Mais vous devez bien vous douter qu'il est bien préferrable qu'une telle directive ne pose pas de problèmes à un script.

Hervé