01 juillet 2010
publié par 
Malgré une ouverture de session Windows en administrateur, il n'est pas rare lors de l'élaboration d'un site Web dynamique, d'être confronté au retour système "accès refusé" lorsque l'on tente de lire, ou d'écrire, une donnée dans un fichier HFSQL (ou une base de données utilisée par un accès natif ou un provider Ole db).

C'est notamment le cas lors du test :
  • d'une page en mode AWP,
  • d'un site dynamique à partir de l'administrateur de WEBDEV : WD150ADMIN.EXE,
  • du test du site via le navigateur avec l'url "http://localhost/Mon_Projet/",
  • du site après son déploiement sur le serveur de production.

Comme souvent, l'explication est simple, une fois que l'on connait la solution, et le principe de sécurité du Web en cause.

Pour éviter toute source d'erreur, le plus simple est de considérer qu'il y a deux ordinateurs dans un :

1. Celui utilisé par le développeur lorsqu'il est dans son environnement WEBDEV, ou sous Windows. Il dispose de droit d'accès complets grâce à la session ouverte. Un test depuis WEBDEV est lancé avec cet utilisateur, tous les droits sont donc disponibles pour accéder aux données. Dans ce cas, aucun "accès refusé" ne peut remonter.

2. Celui utilisé par le serveur Web lorsqu'il est sollicité pour afficher une page d'un site. En effet, le serveur Web utilise un utilisateur bien précis aux droits restreints, qui font que les traitements lancés via le serveur Web n'ont pas accès aux données.
On peut se rendre compte de ce mécanisme par un affichage du résultat de la fonction "RéseauUtilisateur" dans une page de test d'un site lancé depuis :
  • WEBDEV, la page dynamique indiquera le nom de l'utilisateur qui a ouvert la session Windows.
  • un l'administrateur de WEBDEV, donc depuis le serveur Web, là l'utilisateur sera par défaut "IUSR...".


Cet utilisateur et visible, et paramétrable dans la configuration du serveur Web :



Pour supprimer un retour "accès refusé", il faut donc intervenir sur les permissions des répertoires afin d'attribuer des droits à cet utilisateur. Sur un poste de développement, il est possible pour simplifier de remplacer cet utilisateur, par l'utilisateur Windows pris pour ouvrir la session au démarrage du poste.

Il faut noter que ce principe de limitation des accès s'applique intégralement sur un serveur Web (Windows 2003/2008 serveur) lors d'un déploiement effectif d'un site, avec le serveur d'application de WEBDEV. L'attribution des droits est alors très importantes, et doit être faite en accord avec la stratégie de sécurité en place.

Attention le serveur IIS utilise un simple utilisateur du poste jusqu'à sa version 7. A partir de la version 7.5 de IIS et sous Windows Seven et 2008r2, un nouveau mécanisme est en place. Le site Web s'exécute avec le "ApplicationPoolIdentity". Ce changement est visible par le gestionnaire de processus Windows en regardant le processus w3wp.exe (worker process). Pour résoudre dans ce cas une difficulté de droit, il est possible de forcer l'exécution avec le "NETWORK SERVICE" comme c'est le cas sous Vista ou Windows 2008. Voici une illustration du réglage à effectuer :



Vérifiez ensuite que le site Web dans lequel se trouve le répertoire virtuel WD150AWP utilise bien l'identité du pool d'applications :



Ces points de configurations peuvent paraître compliqués, surtout de part les différences d'un serveur Web à un autre, ou entre deux versions d'un même serveur Web. Mais la sécurité du Web tout entier repose sur ces principes, il est donc compréhensible et nécessaire qu'il y ait des évolutions permanentes.


< Retour

Publier un commentaire : 
Votre adresse email ne sera pas publiée


© 2019 PC SOFT. Tous droits réservés. Réalisé  avec WEBDEV