20 octobre 2009
publié par 
Il n'est pas rare dans les différentes phases d'un développement d'obtenir des déclenchements du mécanisme de sécurité WLangage, avec en message système "accès refusé".

La seule certitude dans pareil cas, est que le système d'exploitation lui-même refuse l'accès et vous retourne pour seul compte rendu : "accès refusé".

Voici la méthode à appliquer pour rapidement détecter la raison de cet échec d'accès, et quelques exemples de cas qui ne sont forcément évidents au premier abord ...

Où ?
Qui suis-je ?
A qui est-ce ?

Il s'agit des 3 questions à se poser dans pareil cas.

Où : où se trouve le fichier en question ?
Le mécanisme de sécurité du WLangage indique l'emplacement complet qui a été utilisé pour tenter d'accéder au fichier. Il est certain que l'emplacement est valide, dans la négative le retour système serait "le chemin spécifié est introuvable". Mais ...

Qui suis-je : Windows se sert de quel utilisateur pour exécuter le traitement ?
En effet, suivant le processus qui réalise l'accès au fichier, l'utilisateur Windows pris en compte n'est pas forcément celui auquel on s'attend. En effet, si le traitement s'exécute depuis :
  • un service Windows (ou une tâche planifiée), il utilise le "compte système local" aux droits limités. Il peut donc ne pas avoir les droits requis sur le fichier. Dans ce cas, il faut intervenir dans les propriétés du service, pour changer l'utilisateur, ou ses droits.
  • le code serveur d'une page en mode AWP d'un site WEBDEV, ou depuis un site dynamique WEBDEV, là également l'utilisateur est celui pris par le serveur Web du poste, et non pas celui qui a ouvert la session sous Windows. Par défaut, il se nomme "IUSR_POSTE", il peut ne pas avoir les droits sur le fichier. Dans ce cas il faut intervenir sur l'utilisateur pris par le serveur web afin d'étendre ses possibilités.
  • le code navigateur d'une page d'une site WEBDEV, Windows via le serveur Web peut bloquer des accès suivant les url, le domaine appelant et le domaine appelé. Dans ce cas il faut solliciter l'administrateur du serveur, une redirection peut bloquer des accès.
  • un exécutable WINDEV, il utilise le compte qui a ouvert la session sous Windows. Il peut donc ne pas avoir les droits sur l'emplacement spécifié.
  • le test de projet de WINDEV, il utilise le compte qui a ouvert la session sous Windows, ou le compte donné par le menu "Projet ... Mode test ... Paramétrer le mode test". Dans le cas d'un emplacement réseau, l'utilisateur peut simplement manquer de droits. Si on pense avoir les droits, surtout dans le cas d'un emplacement local, en dernier recours la dernière question ...

A qui est-ce : qui a créé le fichier pour lequel l'accès est refusé ?
En fonction du programme à l'origine de la création du fichier, les permissions nécessaires à son utilisation peuvent varier, même dans le cas d'un accès à un fichier situé en local. Par exemple sous Vista si un fichier est créé dans un emplacement autorisé "\ProgramData" par un utilisateur administrateur (ou un utilisateur du domaine du réseau), le même fichier ne pourra pas être modifié par un utilisateur local standard, sous peine de se voir rejeter avec le retour "accès refusé".

En cas de doute ou de persistance d'un "accès refusé", n'hésitez pas à contacter le Support Technique Gratuit via le menu "? ... Requête au Support Technique". Précisez dans ce cas le traitement, et les réponses aux 3 questions !

< Retour