Ich versuche, Apache / Jakarta HttpClient 4.1.1 zu verwenden, um eine Verbindung zu einer beliebigen Webseite herzustellen, die die angegebenen Anmeldeinformationen verwendet. Um dies zu testen, habe ich eine minimale Installation von IIS 7.5 auf meinem Dev-Computer ausgeführt, auf dem jeweils nur ein Authentifizierungsmodus aktiv ist. Die Standardauthentifizierung funktioniert einwandfrei, aber Digest und NTLM geben 401 Fehlermeldungen zurück, wenn ich mich anmelde. Hier ist mein Code:
%Vor%Die eine Sache, die ich bei Fiddler bemerkt habe, ist, dass die Hashes, die von Firefox und HttpClient gesendet werden, anders sind, was mich denken lässt, dass IIS 7.5 stärkeres Hashing erwartet als HttpClient? Irgendwelche Ideen? Es wäre großartig, wenn ich überprüfen könnte, dass dies mit NTLM funktionieren würde. Digest wäre auch nett, aber ich kann ohne das leben, wenn nötig.
Ich bin kein Experte auf dem Thema, aber während der NTLM-Authentifizierung mit HTTP-Komponenten habe ich gesehen, dass der Client 3 Versuche benötigt, um in meinem Fall eine Verbindung zu einem NTML-Endpunkt herzustellen. Es ist irgendwie hier für Spnego beschrieben, aber es ist ein bisschen unterschiedlich für die NTLM-Authentifizierung.
Für NTLM wird beim ersten Versuch der Client eine Anfrage mit Target auth state: UNCHALLENGED machen und der Webserver gibt den HTTP 401-Status und eine Kopfzeile zurück: WWW-Authenticate: NTLM
Client sucht nach den konfigurierten Authentifizierungsschemas, NTLM sollte im Client-Code konfiguriert werden.
Beim zweiten Versuch wird der Client eine Anfrage mit Target auth state: CHALLENGED stellen und einen Berechtigungsheader mit einem Token senden, das im Base64-Format codiert ist: Authorization: NTLM TlRMTVNTUAABAAAAAYIIogAAAAAoAAAAAAAAACgAAAAFASgKAAAADw==
Der Server gibt erneut den HTTP 401-Status zurück, aber der Header: WWW-Authenticate: NTLM enthält jetzt codierte Informationen.
3. Attentat Client wird die Informationen aus WWW-Authenticate: NTLM header verwenden und die letzte Anfrage mit Target auth state: HANDSHAKE und einem Autorisierungsheader Authorization: NTLM machen, der mehr Informationen für den Server enthält.
In meinem Fall erhalte ich danach ein HTTP/1.1 200 OK .
Um all das in jeder Anfrage zu vermeiden Dokumentation In Kapitel 4.7.1 heißt es, dass für logisch zusammenhängende Anfragen das gleiche Ausführungstoken verwendet werden muss. Für mich hat es nicht geklappt.
Mein Code:
Ich initialisiere den Client einmal in einer @PostConstruct -Methode eines EJB
Verwenden Sie dieselbe Client-Instanz in jeder Anfrage:
%Vor%Erneutes Zuweisen der Ressourcen und Zurückgeben der Verbindung an den Verbindungsmanager an der @ PreDestroy-Methode meines EJB:
%Vor%%Vor%Ich hatte das gleiche Problem mit HttpClient4.1.X Nach dem Upgrade auf HttpClient 4.2.6 es wackelte wie Charme. Unten ist mein Code
Ich hatte ein ähnliches Problem mit HttpClient 4.1.2. Für mich wurde es aufgelöst, indem ich zu HttpClient 4.0.3 zurückkehrte. Ich konnte NTLM nie mit 4.1.2 arbeiten, entweder mit der eingebauten Implementierung oder mit JCIFS.
Der einfachste Weg, um solche Situationen zu finden, die ich gefunden habe, ist Wireshark . Es ist ein sehr großer Hammer, aber es wird dir wirklich alles zeigen. Installieren Sie es, stellen Sie sicher, dass sich Ihr Server auf einem anderen Computer befindet (funktioniert nicht mit Localhost), und starten Sie die Protokollierung.
Führen Sie Ihre fehlgeschlagene Anfrage aus, führen Sie eine aus, die funktioniert. Dann filtern Sie nach http (setzen Sie einfach http im Filterfeld), suchen Sie die erste GET-Anfrage, suchen Sie die andere GET-Anfrage und vergleichen Sie. Identifizieren Sie sinnvolle Unterschiede. Sie haben jetzt spezifische Schlüsselwörter oder Probleme, nach denen Sie Code / Netz suchen können. Wenn nicht genug, beschränken Sie sich auf die erste TCP-Konversation und sehen Sie sich die vollständige Anfrage / Antwort an. Gleiches mit dem anderen.
Ich habe mit diesem Ansatz eine unglaubliche Anzahl von Problemen gelöst. Und Wireshark ist ein sehr nützliches Werkzeug, um es zu wissen. Viele super-erweiterte Funktionen, um das Debuggen im Netzwerk zu erleichtern.
Sie können es auch auf Client- oder Server-Seite ausführen. Was auch immer Ihnen beide Wünsche zeigen, damit Sie vergleichen können.
Die Aktualisierung unserer Anwendung zur Verwendung der jars im httpcomponents-client-4.5.1 hat dieses Problem für mich gelöst.
Ich habe es endlich herausgefunden. Bei der Digestauthentifizierung muss der Proxy bei Verwendung einer vollständigen URL in der Anforderung auch die vollständige URL verwenden. Ich habe den Proxy-Code nicht in der Probe gelassen, aber er wurde an "localhost" weitergeleitet, was dazu führte, dass er fehlschlug. Das Ändern zu 127.0.0.1 hat es funktioniert.
Tags und Links java iis httpclient ntlm digest