Le retour ERR_NO_APPLICATION survient lorsque l'utilisateur Windows utilisé par le serveur web pour exécuter la session n'a pas les autorisations nécessaires pour lire la clé de registre du serveur d'application WEBDEV.

Rappelons que pour exécuter un site ou un webservice :

• une URL est donnée dans la barre d'adresse d'un navigateur, par exemple :
  https://<domaine-serveur>/NOMSITE
  ou https://<domaine-serveur>/WD300AWP/WD300AWP.EXE/CONNECT/NOMSITE
• le serveur Web IIS qui répond à <domaine-serveur> :
  • reçoit la demande (au passage il l'ajoute dans son log),
  • récupère dans sa configuration l'utilisateur indiqué pour les authentifications anonymes,
  • lance avec cet utilisateur le processus WD300AWP.EXE du serveur d'application de WEBDEV (cet exécutable est dans le répertoire virtuel WD300AWP),
• le processus WD300AWP.EXE lance un nouveau processus WD300SESSION.EXE (ou utilise une session pré-lancée s'il y en a), en lui transmettant le nom du site à exécuter,

Dans ce "cheminement" de processus, la configuration des droits d'exécution est donc déterminante. Voici le rappel des étapes de configuration des droits d'exécutions pour les sites et webservices hébergés par un serveur d'application de WEBDEV, dans toutes ses versions.

• Dans le centre de contrôle d'hébergement du serveur web :
  • des groupes sont sélectionnés pour l'installation et l'exécution des sites. Rien n'empêche de créer des groupes spécifiques pour une gestion très fine des droits, mais il s'agit généralement des groupes :
    • "Administrateur" pour l'installation, au moins tous les droits sont disponibles,
    • "IUSR" pour l'exécution, au moins à l'inverse il n'y a aucun droit par défaut, il faut les données explicitement.
  • puis un utilisateur WEBDEV est créé, et va donc créer deux utilisateurs Windows qui héritent des groupes sélectionnés. C'est cet utilisateur WEBDEV qui est donné sur le poste de développement, pour déployer les sites et webservices.
    Dans le volet "Compte OS" de cet utilisateur, on peut voir les noms des utilisateurs Windows qui servent donc aux installations, et à l'exécution des sites et webservices. Dans cet exemple on a un utilisateur "WWCLOUD" qui sert à lancer les installations, et un utilisateur "IUSR_WWCLOUD" qui sert donc à exécuter les sites :
    
    
    
    
• le site virtuel du serveur web dans lequel le serveur d'application de WEBDEV est configuré, utilise donc l'utilisateur "IUSR_WWCLOUD" pour l'authentification anonyme :
  
  
  
  Ainsi tous les traitements lancés par le code serveur d'un site ou un webservice déployé, disposent des droits limités de cet invité internet IUSR.
• cet utilisateur, ou le groupe auquel cet utilisateur appartient, doit donc avoir les droits de lecture sur la clé de registre de WEBDEV :
  \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PC SOFT\WEBDEV\<version>.0
  Cela permet au lancement d'une session, de récupérer toutes les informations relatives au site, ou au webservice :
  
  
  
  Ce droit sur la clé de registre est donné automatiquement sur un serveur standard sur lequel le centre de contrôle d'hébergement est utilisé comme décrit ci-dessus. Mais si pour une raison quelconque les droits n'arrivent pas à s'appliquer, ou sont supprimés par erreur, le lancement du site échoue avec le retour ERR_NO_APPLICATION.

Rappelons qu'une solution couramment utilisée pour éviter de gérer la configuration et la sécurité des serveurs web, consiste à utiliser une plateforme PCSCLOUD pour les applications !

A lire sur le même sujet :

https://blogs.pcsoft.fr/fr/acces-refuse-donnees-site-webdev-droits-deux-ordinateurs/349/read.awp

https://blogs.pcsoft.fr/fr/point-code-fermeture-projet-webdev-liberation-sessions-sites-web-dynamiques/191/read.awp