Une page se charge, et les fenêtres de connexion du proxy n’arrêtent pas d’apparaître
Suivez les requêtes de ressources qui échouent et les routes du proxy lorsqu’une page produit des demandes d’authentification répétées.
Une page émet plus d’une requête. Répondre à sa première fenêtre de connexion proxy peut laisser des scripts, des images ou des connexions en direct emprunter d’autres routes et recevoir d’autres défis.
- Trouvez une ressource en échec. Notez sa destination, le proxy sélectionné et le défi 407. Comparez ces mêmes champs avec une ressource qui réussit ; l’URL de la page principale ne suffit pas.
- Cherchez la différence commune. Les échecs peuvent suivre un hôte de ressource, des chemins HTTP/HTTPS distincts, une extension ou une décision PAC. Une connexion acceptée par un point de terminaison ne prouve pas qu’un autre l’accepte. La mise en cache de l’authentification dépend aussi du défi, de l’identité et de la portée de la route.
- Réparez l’échange identifié. Corrigez la route, le compte ou le comportement d’authentification pris en charge, puis examinez à la fois le comportement de la page et les résultats des ressources.
Ressaisir le même mot de passe n’apporte que peu de preuves tant que cette portée n’est pas connue. Les premiers contournements côté navigateur, comme désactiver WebSockets, bloquer les scripts ou changer d’extension, peuvent supprimer la requête qui déclenche une fenêtre, mais aussi une fonctionnalité nécessaire.
Bloquer une ressource indésirable peut être un choix de politique délibéré. Décrivez ce résultat comme un blocage, et non comme la preuve que l’authentification fonctionne désormais. Une page silencieuse privée de sa connexion temps réel requise n’a pas obtenu le même résultat qu’une page fonctionnelle utilisant les routes prévues.