NTLM-Dialogfeld nach unbefugter Anfrage unterdrücken

Question

In einem aktuellen Sharepoint-Projekt habe ich ein Authentifizierungs-Webpart implementiert, das das NTLM-Authentifizierungsdialogfeld ersetzen sollte.Es funktioniert einwandfrei, solange der Benutzer gültige Anmeldeinformationen bereitstellt.Immer wenn der Benutzer ungültige Anmeldeinformationen angibt, wird das NTLM-Dialogfeld im Internet Explorer angezeigt.

Mein Javascript-Code, der die Authentifizierung über XmlHttpRequest durchführt, sieht folgendermaßen aus:

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);
}

Ich möchte nicht, dass das NTLM-Dialogfeld angezeigt wird, wenn der Benutzer ungültige Anmeldeinformationen angibt.Stattdessen sollte das Postback über den Login-Button im Authentifizierungsformular ausgeführt werden.Mit anderen Worten: Der Browser sollte nichts von meiner unautorisierten Anfrage erfahren.

Gibt es eine Möglichkeit, dies über Javascript zu tun?

Answer 1

MarkierenDer Kommentar von ist richtig;Die NTLM-Authentifizierungsaufforderung wird durch einen 401-Antwortcode und das Vorhandensein von NTLM als erstem im WWW-Authenticate-Header angebotenen Mechanismus ausgelöst (Ref: Das NTLM-Authentifizierungsprotokoll).

Ich bin mir nicht sicher, ob ich die Beschreibung der Frage richtig verstehe, aber ich glaube, Sie versuchen, die NTLM-Authentifizierung für SharePoint zu verpacken, was bedeutet, dass Sie keine Kontrolle über das serverseitige Authentifizierungsprotokoll haben, richtig?Wenn Sie die Serverseite nicht so manipulieren können, dass bei fehlgeschlagenen Anmeldeinformationen keine 401-Antwort gesendet wird, können Sie dieses Problem nicht vermeiden, da es Teil der (clientseitigen) Spezifikation ist:

Das XMLHttpRequest-Objekt

Wenn die UA die HTTP -Authentifizierung unterstützt [RFC2617], sollten Anfragen in Betracht gezogen werden, die aus diesem Objekt stammen, um Teil des Schutzraums zu sein, der die zugegriffenen URIs enthält, und die Autorisierungsüberschriften zu senden und 401 nicht autorisierte Anfragen angemessen zu bearbeiten.Wenn die Authentifizierung fehlschlägt, sollten UAs die Benutzer zur Eingabe von Anmeldeinformationen auffordern.

Die Spezifikation fordert also tatsächlich, dass der Browser den Benutzer entsprechend auffordert, wenn eine 401-Antwort in einer XMLHttpRequest empfangen wird, so als ob der Benutzer direkt auf die URL zugegriffen hätte.Soweit ich das beurteilen kann, besteht die einzige Möglichkeit, dies wirklich zu vermeiden, darin, die Kontrolle über die Serverseite zu haben und dafür zu sorgen, dass nicht autorisierte 401-Antworten vermieden werden, wie Mark erwähnt hat.

Ein letzter Gedanke ist, dass Sie dies möglicherweise umgehen können, indem Sie einen Proxy verwenden, beispielsweise ein separates serverseitiges Skript auf einem anderen Webserver.Dieses Skript nimmt dann einen Benutzer- und Übergabeparameter und überprüft die Authentifizierung, sodass der Browser des Benutzers nicht derjenige ist, der die ursprüngliche HTTP-Anfrage stellt und daher nicht die 401-Antwort erhält, die die Eingabeaufforderung verursacht.Wenn Sie es auf diese Weise tun, können Sie anhand Ihres „Proxy“-Skripts herausfinden, ob es fehlgeschlagen ist, und wenn ja, dann den Benutzer erneut auffordern, bis es erfolgreich ist.Bei einem erfolgreichen Authentifizierungsereignis können Sie die HTTP-Anfrage einfach so abrufen, wie Sie es jetzt tun, da bei korrekter Angabe der Anmeldeinformationen alles funktioniert.

Answer 2

IIRC, der Browser öffnet den Authentifizierungsdialog, wenn Folgendes im Anforderungsstream zurückkommt:

• HTTP-Status von 401
• WWW-Authenticate-Header

Ich würde vermuten, dass Sie eines oder beide davon unterdrücken müssen.Der einfache Weg, dies zu tun, besteht darin, über eine Anmeldemethode zu verfügen, die einen Base64-Benutzernamen und ein Base64-Kennwort akzeptiert (Sie verwenden HTTPS, oder?) und 200 mit einem gültigen/ungültigen Status zurückgibt.Sobald das Passwort validiert wurde, können Sie es mit XHR verwenden.

Answer 3

Ich konnte dies für alle Browser außer Firefox zum Laufen bringen.Siehe unten meinen Blog-Beitrag von vor ein paar Jahren.Mein Beitrag richtet sich nur an den IE, aber mit ein paar kleinen Codeänderungen sollte er in Chrome und Safari funktionieren.

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

BEARBEITEN:

Der Kern meines Beitrags besteht darin, Ihren JS-XML-Aufruf in eine Try-Catch-Anweisung zu verpacken.In IE, Chrome und Safari wird dadurch das NTLM-Dialogfeld unterdrückt.Es scheint in Firefox nicht wie erwartet zu funktionieren.