Éradication de 401 réponses "non autorisées" suivies de 200 réponses "Ok"
J'ai une situation avec une grande application web d'entreprise interne en cours d'exécution ASP.NET 3.5 sur IIS6 générant 401 réponses " non autorisées "suivies de 200 réponses" Ok " (telles que profilées par Fiddler). Je suis conscient de la raison pour laquelle cela se produit (authentification intégrée forçant le navigateur à renvoyer les informations d'identification), mais je cherche quelques réflexions sur la façon de minimiser ou d'éradiquer la situation. L'application en question s'exécute dans le WAN avec certains utilisateurs éprouvant une latence allant jusqu'à 250ms forçant ainsi un requête peut avoir un impact notable sur le temps de chargement de page, en particulier lorsqu'il existe un certain nombre de listes déroulantes en cascade sur les pages.
Les utilisateurs de l'application sont internes dans un environnement de bureau géré, donc des mécanismes pour forcer le navigateur à envoyer des informations d'identification à la première demande(est-ce même possible?) pourrait être possible du point de vue du déploiement. Cela fonctionnerait pour les pages nécessitant l'identité de l'utilisateur mais pour les ressources ne nécessitant pas d'authentification (WebResource.axd, ScriptResource.axd et certains services web personnalisés), permettant l'authentification anonyme serait possible. J'ai regardé définir ceci sur une base par emplacement dans le web.config mais les résultats ont été mitigés (encore un certain nombre de 401 réponses).
J'apprécierais toute orientation sur une "meilleure pratique" pour faire face à cette situation. Il y a beaucoup de ressources là-bas pour identifier le problème, mais aucune que j'ai trouvé fournissant une solution réalisable.
Merci!
Modifier: Les ressources ne nécessitant pas d'authentification (c'est-à-dire les services web utilisés pour les listes déroulantes en cascade) peuvent être demandées anonymement en ajoutant une entrée d'emplacement à la configuration web, mais je n'ai pas encore trouvé de réponse pour les ressources authentifiées.
4 réponses
Malheureusement, il s'agit D'un artefact du schéma D'authentification HTTP NTLM .
En bref, le navigateur (Internet Explorer ou autre) ne sait pas qu'il doit s'authentifier du tout jusqu'à ce qu'il soit rebondi avec une réponse 401 contenant un en-tête de réponse WWW-Authenticate.
Dans le cas de WWW-Authenticate: NTLM -- assez ennuyeux -- il faut deux réponses 401 sur une seule connexion persistante pour terminer, et ce processus doit être répété une fois la connexion persistante HTTP est fermé. Donc, même si vous étiez en mesure d'obtenir le navigateur pour lancer une demande essayant aveuglément NTLM, au moins une réponse 401 ne peut pas être supprimée de la transaction.
Je pense que votre meilleur pari serait de maximiser le temps pendant lequel les connexions persistantes sont laissées ouvertes lorsqu'elles sont inactives.
CSCRIPT.EXE c:\inetpub\adminscripts\ADSUTIL.VBS SET W3SVC / AuthPersistSingleRequest FALSE
Réduira considérablement la quantité de 401.
Je crois que vous pouvez convaincre Firefox d'envoyer automatiquement des informations D'identification NTLM à un ensemble de domaines en liste blanche via les paramètres "about: config" - utilisez le "réseau".automatique-ntlm-auth.paramètre trusted-uris". Je n'ai pas essayé moi-même cependant. Je ne suis pas sûr qu'il y ait un équivalent Pour Internet Explorer.
Malheureusement, si vous utilisez autre chose comme Kerberos, il ne semble pas y avoir un moyen d'éviter le 401.
Vous devrez peut-être considérer L'authentification des formulaires si la latence induite par 401 est trop longue. Les utilisateurs devraient se connecter explicitement, mais juste une fois. Ensuite, vous pouvez utiliser un cookie ou un schéma sans cookie et obtenir une réponse au premier essai.
J'imagine que le chargement de la page serait lent si vous avez des listes déroulantes en cascade et que votre chargement initial de la page remplit une valeur qui amène un POST à obtenir la liste suivante, définissez cette valeur, un autre POST pour obtenir la liste suivante, et ainsi de suite. Si c'est le situation, peut-être que vous avez besoin de remplir toutes ces listes déroulantes sur le premier aller-retour plutôt que d'attendre les réponses POST.