Contrôle ActiveX ne pas accéder au système de fichiers lorsque la page est générée par programme

Question

Nous travaillons sur l'utilisation du contrôle ActiveX d'une tierce partie dans une page Web. Notre page comprend JavaScript pour accéder et manipuler le contrôle. Une partie des fonctionnalités du contrôle l'oblige à accéder aux fichiers sur le système de fichiers local.

Si nous générons la page par programmation, cette fonctionnalité échoue - le contrôle ActiveX semble incapable d'accéder au système de fichiers. Si nous prenons la source de la page générée, la copions dans un fichier statique, et servons ce fichier depuis le même serveur web, tout fonctionne comme prévu - le contrôle ActiveX obtient les informations dont il a besoin du système de fichiers, et nous allons joyeusement.

J'ai utilisé un débogueur JavaScript pour parcourir les deux pages différentes et vérifié que les appels au contrôle ActiveX ont des paramètres identiques. J'ai vérifié que la page statique et la page dynamique sont répertoriées dans la «zone intranet locale» dans IE afin qu'elles aient les mêmes contraintes de sécurité.

J'ai utilisé ProcessMonitor de SysInternals pour voir ce que fait le contrôle ActiveX dans le système, et ce qui diffère. Fait intéressant, lorsque les appels au contrôle aboutissent, il existe des traces ProcessMonitor montrant où le contrôle interroge le registre pour les noms de fichiers et accède au système de fichiers. Lorsque le processus échoue, ce n'est pas le cas si des échecs accèdent au système de fichiers, mais plutôt que le contrôle interroge le registre pour trouver le nom de fichier et n'essaie jamais de toucher le système de fichiers.

Le fournisseur de ce contrôle est mystifié, et je n'ai plus d'idées sur ce qu'il faut essayer. Y a-t-il quelque chose que je devrais vérifier? Une différence entre les pages générées dynamiquement et les pages statiques que IE ou un contrôle ActiveX pourrait détecter, entraînerait des changements de comportement? L'URI est différente, la page statique a une extension ".html" ... Il n'y a pas grand-chose d'autre, pour autant que je sache.

Toutes les idées sont les bienvenues ....

Answer 1

Nous avons compris ce qui était faux, et effectivement découvert un bogue dans le contrôle ActiveX du 3ème partie.

Ils ont une fonctionnalité où ils peuvent éventuellement valider l'URL de la page sur laquelle le contrôle est chargé, ou ils peuvent configurer le contrôle avec un caractère générique supposé pour correspondre à n'importe quelle URL. Le fournisseur avait travaillé avec nous et configuré le contrôle avec le caractère générique, et nous a assuré que cela ne pouvait pas être le problème.

Lorsque nous avons remplacé l'URL générique dans la configuration du contrôle par notre URL réelle, le contrôle a commencé à fonctionner. Autant que nous puissions le dire, nous nous sommes battus toute la journée d'hier contre un bug dans la gestion des caractères génériques du contrôle.