Supprimer la boîte de dialogue NTLM après une demande non autorisée

Question

Dans un récent projet sharepoint, j'ai implémenté un composant WebPart d'authentification qui devrait remplacer la boîte de dialogue d'authentification NTLM.Cela fonctionne bien tant que l'utilisateur fournit des informations d'identification valides.Chaque fois que l'utilisateur fournit des informations d'identification non valides, la boîte de dialogue NTLM apparaît dans Internet Explorer.

Mon code Javascript qui effectue l'authentification via XmlHttpRequest ressemble à ceci :

function Login() {
   var request = GetRequest(); // retrieves XmlHttpRequest
   request.onreadystatechange = function() {
      if (this.status == 401) {     // unauthorized request -> invalid credentials
         // do something to suppress NTLM dialog box...
         // already tried location.reload(); and window.location = <url to authentication form>;
      }
   }
   request.open("GET", "http://myServer", false, "domain\\username", "password");
   request.send(null);
}

Je ne souhaite pas que la boîte de dialogue NTLM s'affiche lorsque l'utilisateur fournit des informations d'identification non valides.Au lieu de cela, la publication via le bouton de connexion dans le formulaire d'authentification doit être exécutée.En d’autres termes, le navigateur ne devrait pas connaître ma demande non autorisée.

Existe-t-il un moyen de le faire via Javascript ?

Answer 1

MarqueLe commentaire de est correct ;L'invite d'authentification NTLM est déclenchée par un code de réponse 401 et la présence de NTLM comme premier mécanisme proposé dans l'en-tête WWW-Authenticate (Réf : Le protocole d'authentification NTLM).

Je ne suis pas sûr de bien comprendre la description de la question, mais je pense que vous essayez d'encapsuler l'authentification NTLM pour SharePoint, ce qui signifie que vous n'avez pas de contrôle sur le protocole d'authentification côté serveur, n'est-ce pas ?Si vous ne parvenez pas à manipuler le côté serveur pour éviter d'envoyer une réponse 401 en cas d'échec des informations d'identification, vous ne pourrez pas éviter ce problème, car cela fait partie de la spécification (côté client) :

L'objet XMLHttpRequest

Si l'UA prend en charge l'authentification HTTP [RFC2617], il devrait considérer les demandes provenant de cet objet pour faire partie de l'espace de protection qui inclut les URI accessibles et envoyer des en-têtes d'autorisation et gérer 401 demandes non autorisées de manière appropriée.si l'authentification échoue, les UA doivent demander aux utilisateurs leurs informations d'identification.

Ainsi, la spécification demande en fait au navigateur d'inviter l'utilisateur en conséquence si une réponse 401 est reçue dans un XMLHttpRequest, comme si l'utilisateur avait accédé directement à l'URL.Autant que je sache, la seule façon d'éviter vraiment cela serait que vous ayez le contrôle du côté serveur et que vous évitiez les réponses 401 non autorisées, comme Mark l'a mentionné.

Une dernière pensée est que vous pourrez peut-être contourner ce problème en utilisant un proxy, tel qu'un script côté serveur distinct sur un autre serveur Web.Ce script prend ensuite un paramètre user and pass et vérifie l'authentification, de sorte que le navigateur de l'utilisateur n'est pas celui qui effectue la requête HTTP d'origine et ne reçoit donc pas la réponse 401 à l'origine de l'invite.Si vous procédez de cette façon, vous pouvez savoir à partir de votre script "proxy" s'il a échoué, et si c'est le cas, inviter à nouveau l'utilisateur jusqu'à ce qu'il réussisse.En cas d'événement d'authentification réussi, vous pouvez simplement récupérer la requête HTTP telle que vous le faites actuellement, car tout fonctionne si les informations d'identification sont correctement spécifiées.

Answer 2

IIRC, le navigateur affiche la boîte de dialogue d'authentification lorsque les éléments suivants reviennent dans le flux de requête :

• Statut HTTP de 401
• En-tête WWW-Authentifier

Je suppose que vous devrez supprimer l'un ou les deux.Le moyen le plus simple de le faire est d'avoir une méthode de connexion qui prendra un nom d'utilisateur et un mot de passe Base64 (vous utilisez HTTPS, n'est-ce pas ?) et renverra 200 avec un statut valide/invalide.Une fois le mot de passe validé, vous pouvez l'utiliser avec XHR.

Answer 3

J'ai pu faire fonctionner cela pour tous les navigateurs sauf Firefox.Voir mon article de blog ci-dessous d'il y a quelques années.Mon message s'adresse uniquement à IE, mais avec quelques petites modifications de code, il devrait fonctionner dans Chrome et Safari.

http://steve.thelineberrys.com/ntlm-login-with-anonymous-fallback-2/

MODIFIER:

L'essentiel de mon message consiste à envelopper votre appel XML JS dans une instruction try catch.Dans IE, Chrome et Safari, cela supprimera la boîte de dialogue NTLM.Cela ne semble pas fonctionner comme prévu dans Firefox.