SEC7117 Erreur lors de la tentative de chargement d'un fichier javascript dans MS Edge
J'obtiens cette erreur lorsque j'essaie de charger un fichier javascript à partir d'un autre serveur lors de l'utilisation de Microsoft Edge. J'ai le sentiment que c'est lié au serveur étant http au lieu de https, mais je ne suis pas sûr. Cela fonctionne dans IE (après avoir autorisé le contenu non sécurisé), mais je ne trouve pas d'option dans Edge pour autoriser le contenu non sécurisé.
Voici l'erreur que je reçois:
SEC7117: Network request to http://servername/whatever.js did not succeed. This Internet Explorer instance does not have the following capabilities: privateNetworkClientServer
Merci d'avance pour votre aide!
Cela peut avoir quelque chose à voir avec le mélange des zones Internet/Intranet plutôt que http/https.
Voir ici: Comprendre le mode protégé amélioré
Ressources du réseau privé
Parce qu'EPM ne déclare pas la capacité privateNetworkClientServer, vos ressources Intranet sont protégées contre de nombreux types d'attaques interzones (généralement appelées "Cross-Site-Request-Forgery (CSRF)" et "Intranet Port Scanning".) Les pages Internet ne sont pas en mesure pour encadrer des pages Intranet, en charger des images ou des ressources, leur envoyer des requêtes CORS XHR, etc.
Je sais qu'il s'agit d'un ancien article, mais les informations semblent toujours pertinentes car le site Microsoft MSDN y fait toujours référence en ce qui concerne IE11 (par exemple ici: Enhanced Protected Mode on desktop IE ). Je sais également que IE11 n'est pas Edge, mais ces informations peuvent également s'appliquer aux applications de style métro.
[ [~ # ~] mise à jour [~ # ~] ]
Dans ma configuration, Edge n'a pas réussi à charger ma page dans un iframe. Lorsque j'ai essayé de charger la page dans un onglet Edge distinct, elle s'est bien chargée.
Il s'avère qu'Edge ne parvient pas à charger une page SSL sécurisée privée/locale (iframe) lors du chargement d'une page publique sécurisée. Les deux sites sont sécurisés à l'aide de certificats SSL publics pour éviter les problèmes de contenu mixte. Le problème est que la sécurité Edge détecte que le site iframe se trouve sur le réseau local des utilisateurs (réseau privé/domaine) et empêche la page de se charger dans un iframe. Edge signale les erreurs de sécurité suivantes dans la console du développeur:
SEC7117: Network request to https://my.company.com/default.html did not succeed. This Internet Explorer instance does not have the following capabilities: privateNetworkClientServer
SEC7111: HTTPS security is compromised by ms-appx-web://Microsoft.microsoftedge/assets/errorpages/dnserror.html
Pour résoudre le problème, nous avons déplacé le site interne vers un espace d'adressage non local (un espace réseau privé utilisant un sous-réseau différent du réseau local) afin qu'Edge détecte le site en tant que réseau public. Vous pouvez également déplacer les ressources vers une véritable adresse publique.
Voici deux alternatives à la restructuration de votre réseau:
- Vous pouvez envisager d'ajouter le site hébergé en externe à votre zone "Intranet local".
Par exemple. Si external.somedomain contient une référence à internal.mydomain/everything.js alors ajoutez external.somedomain à la zone "Intranet local" dans "Options Internet" ".
- Si possible, modifiez le nom d'hôte du site hébergé en externe pour qu'il corresponde à votre site hébergé en interne.
Par exemple. Si external.somedomain contient une référence à internal.mydomain/everything.js alors changez external.somedomain hostname en external.mydomain.
Ces deux options permettront essentiellement aux scripts sur le site externe de rechercher dans une certaine mesure les services HTTPS sur votre réseau interne, ce que je suppose que c'est ce que cette fonctionnalité de sécurité tente d'empêcher. La première option étant la moins sécurisée car la deuxième option se limite à sonder les noms de domaine correspondants.
Lors des tests, j'ai remarqué qu'Edge semble obtenir les détails du réseau d'Active Directory lorsque Windows est joint au domaine. Il est probable que les sites hébergés en externe ne soient pas liés à des ressources hébergées n'importe où dans votre domaine AD, et pas seulement au sous-réseau actuel auquel vous êtes connecté. La seule exception est si le site hébergé en externe partage le même nom de domaine de base. Tout cela n'est apparemment pas documenté, c'est pourquoi je poste cette information ici.