Je me suis souvent cassé la tête sur des erreurs de droit en utilisant un projet WebDev. Tout marchait bien sur mon poste en test et en déploiement, j’avais des erreurs de droits.

Toutes ces difficultés viennent de la gestion de la sécurité des serveurs Web. C’est un domaine très sensible et relativement complexe. Je vais donc résumer le fonctionnement d’un projet WebDev.

Le clic sur un bouton d’une page WebDev, se décompose comme suit :

-          Exécution du code Navigateur, c’est du code JavaScript et c’est le navigateur (IE ou Firefox) qui l’exécute. L’exécution est donc faite sur le poste de l’internaute.

-          Envoi de la page et du contenu des champs vers le serveur WEB (IIS ou Appache),

-          Le serveur WEB reçoit une demande WebDev (AWP), il lance le moteur WebDev (WD100AWP.EXE) dans une session « Invité Internet » et lui transmet la demande.

-          La moteur WebDev exécute le code WLangage, crée la page HTML résultat et la transmet en réponse au serveur WEB (IIS ou Appache).

-          Le Serveur Web qui était en attente de cette réponse, la transmet au Navigateur qui l’affiche sur le poste de l’internaute.

Les difficultés que l’on puisse rencontrer ont principalement 3 causes :

-          Le code Serveur ne s’exécute pas sur la même machine que le code Navigateur :

C’est la première difficulté, par exemple, un fichier vu en code navigateur n’existe pas en code serveur et vis versa, les disques ne sont pas les mêmes, etc….

Un bon exemple : Si je fais un LanceAppliAssociée(‘’doc.pdf’’) en code Navigateur, je lance Acrobate sur le poste de l’Internaute alors si je l’exécute en code Serveur, je le lance sur le serveur ce qui ne sert à rien (il y a souvent personne devant l’écran du serveur !).

-          Les données du poste client ne sont pas accessibles depuis un Navigateur :

Dans un code Serveur, il est impossible d’accéder à un fichier du poste de l’internaute et bien heureusement (Imaginez un site Internet capable de copier vos fichiers perso sur son propre disque ! ). Il faut donc passer par un champ UPLOAD qui oblige l’internaute à donner l’accès à son fichier. C’est lui qui choisit le fichier qui va donner au serveur et doit valider son choix. Cela s’appelle de la protection de donnée ou de la sécurité.

Pour comparer avec un exemple de vie courante, imaginez une caissière se servir toute seule dans votre porte feuille pour prendre votre carte bleue.

-          Le code serveur est exécuté par le moteur WebDev sur le serveur avec les droits de l’utilisateur « Invité Internet » :

Là encore c’est une contrainte importante et nécessaire à la sécurité du serveur. Cela limite l’accès au serveur à la partie « Publique » du serveur. Comparez cela à un magasin, le client n’a pas accès à la réserve ou aux bureaux.

Le développeur du site doit définir avec l’administrateur du serveur Web un plan d’action du site et déduire les droits de cet utilisateur.

Ce qui peut perturber le développeur dans ces trois cas, c’est que lors du test de son site en mode développement, la machine de l’Internaute est la même que le serveur. Du coup, les codes Navigateur et Serveur s’exécutent sur la même machine (Point 1), les données sont les mêmes (Point 2) et le serveur Web voyant qu’il s’agit d’une demande interne (localhost) utilise la session en cours et non l’Invité Internet.