Aktualisierung:
Wenn Sie gerade bei dieser Frage angekommen sind, besteht die allgemeine Aussage darin, dass ich versuche, eine HttpWebRequest über einen Proxy zu machen, und ich bekomme einen 407 von unserem seltsamen Proxy-Server. IE, Firefox, Chrome verwalten den Proxy erfolgreich, ebenso wie Adobe Air-Anwendungen. Es kann wichtig sein, dass das Google Chrome-Web-Installationsprogramm fehlschlägt und wir ein Offline-Installationsprogramm verwenden müssen.
Dank Ians Verbindung habe ich es bis zur nächsten Stufe geschafft. Es sendet jetzt ein Token zurück an den Proxy, aber die dritte Stufe kommt nicht durch, daher wird die Anfrage mit dem Benutzernamen / Passwort-Hash nicht von .NET gesendet und folglich wird kein HTML zurückgegeben.
Ich verwende:
Hier ist der neueste Code, der den folgenden Logs entspricht:
%Vor%Die Ausnahme
WebException (407) Authentifizierung erforderlich.
Der Proxy-Client ist ein Scansafe Hardware-Gerät in unserem Serverraum, das (sobald es mit NTLM authentifiziert wurde) Ihre Daten anleitet HTTP-Verkehr zu seinen Servern, um den Verkehr zu filtern.
Ich habe nicht wirklich eine Lösung gefunden, aber dank Feroze und Eric habe ich einen Workaround gefunden und festgestellt, dass der eigentliche Proxy (und nicht seine Konfiguration) das Hauptproblem ist. Es kann ein obskures Problem mit 3 Variablen sein: .NET HttpWebRequest-Implementierung, Windows 7 und natürlich der Scansafe-Hardware-Client, der in unserem Rack sitzt; aber ohne eine MSDN-Supportanfrage werde ich es nicht herausfinden.
Wenn Sie Anmeldeinformationen für den Proxy festlegen möchten, sollten Sie keine Anmeldeinformationen für das request.Proxy-Objekt und nicht für das Anforderungsobjekt festlegen?
Beachten Sie auch, dass Sie eine HTTP / 1.1-Anfrage (oder technisch gesehen, eine Anfrage mit Keep-Alive) machen müssen, um die NTLM / Negotiate-Authentifizierung erfolgreich zu nutzen.
(Fiddlers "Auth" -Inspektor wird die NTLM-Authentifizierungs-Blobs für Sie zerlegen, falls Sie sich das noch nicht angesehen haben.)
Ich habe ein Dienstprogramm geschrieben, um die NTLM-Blobs zu decodieren, die in den IE- und HttpWebRequest-Sitzungen gesendet wurden.
Wenn ich mir HttpWebRequest und IE anschaue, fordern beide vom Server 56-Bit- und 128-Bit-Verschlüsselung an. Hier ist der Dump der Sitzung mit HttpWebRequest
%Vor%Hier ist der Dump von IE:
%Vor%In beiden IE / HttpWebRequest fordern sie sowohl 64 & amp; 128-Bit-Sicherheit. Für Windows7 wurde jedoch 128-Bit-Sicherheit für NTLM als Standard festgelegt, und ohne diese wird die Authentifizierung fehlschlagen. Wie Sie anhand der Serverantwort sehen können, unterstützt der Server nur die 64-Bit-Verschlüsselung.
Der folgende Link enthält eine Diskussion über ein ähnliches Problem, auf das eine andere Person gestoßen ist. Ссылка
Der Grund dafür, dass IE anstelle der verwalteten App funktioniert, ist, dass der IE NTLMSSP_NEGOTIATE_SEAL | nicht tatsächlich anfordert NTLMSSP_NEGOTIATE_SIGN, die letztendlich eine Verschlüsselung erfordern. HttpWebRequest fordert jedoch beide SEAL | SIGN an. Dies erfordert eine 128-Bit-Verschlüsselung, während die Art und Weise, wie IE den NTLMSSP initialisiert (ohne SEAL & amp; SIGN), keine Verschlüsselung erfordert. Daher funktioniert IE, während HttpWebRequest nicht funktioniert. (siehe obigen Link)
Ich denke, wenn Sie Ihre Sicherheitsrichtlinie ändern, um 64-Bit-Verschlüsselung für NTLM zuzulassen, wird Ihre App mit verwaltetem Code funktionieren. Oder fragen Sie den Proxy-Anbieter alternativ, 128-Bit-Verschlüsselung für NTLM zu unterstützen.
Hoffe, das hilft.
Überprüfen Sie die folgende Einstellung in secpol.msc
. Es hat unser Problem behoben.
Legen Sie Folgendes fest:
%Vor%
Es könnte damit in Verbindung stehen, was in Ihrem "CredentialCache" enthalten ist. Versuchen Sie es stattdessen:
%Vor%Tags und Links c# proxy httpwebrequest http-status-code-407