407 Authentification requise - aucune contestation envoyée
mise à jour:
Si vous venez d'arriver à cette question, l'essentiel est que j'essaye de faire un HttpWebRequest via un proxy, et je reçois un 407 de notre étrange serveur proxy. IE, Firefox, Chrome tous parviennent à négocier le proxy avec succès, tout comme les applications Adobe Air. Il est peut-être important que L'installateur Web GoogleChrome échoue et que nous devions utiliser un installateur hors ligne.
grâce au lien de Ian Je l'ai passer à l'étape suivante. Il envoie maintenant un token de nouveau au proxy, mais la troisième étape ne passe pas, de sorte que la requête avec le hachage nom d'utilisateur/mot de passe n'est pas envoyée par .NET et par conséquent aucun HTML n'est retourné.
j'utilise:
- IE6 user-agent
- Windows 7
- procuration de Scansafe
- .NET 3.5
voici le dernier code qui correspond aux logs ci-dessous:
HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
IWebProxy proxy = request.Proxy;
// Print the Proxy Url to the console.
if (proxy != null)
{
// Use the default credentials of the logged on user.
proxy.Credentials = CredentialCache.DefaultCredentials;
}
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
request.Accept = "*/*";
HttpWebResponse response = request.GetResponse() as HttpWebResponse;
Stream stream = response.GetResponseStream();
l'exception
WebException (407) Authentification Requise.
proxy
le client proxy est un Scansafe dispositif matériel dans notre salle de serveur, qui (une fois authentifié avec NTLM) dirige ensuite votre trafic HTTP vers ses serveurs pour filtrer le circulation.
System.Net sortie de suivi
IE succès de la négociation de l'proxy
la solution
Je n'ai pas vraiment trouvé de solution mais grâce à Feroze et Eric, j'ai trouvé une solution de contournement et découvert que le vrai proxy (et non sa configuration) est le problème principal. Il peut s'agir d'un problème obscur avec 3 variables: l'implémentation de .NET HttpWebRequest, Windows 7 et bien sûr le client Matériel Scansafe qui se trouve dans notre rack; mais sans demande de support MSDN, Je ne le saurai pas.
8 réponses
si vous voulez définir des informations d'identification pour le mandataire, ne devriez-vous pas définir des informations d'identification sur la demande.Objet Proxy plutôt que l'objet request?
http://msdn.microsoft.com/en-us/library/system.net.webproxy.credentials.aspx
aussi, gardez à l'esprit que vous devez faire une requête HTTP/1.1 (ou techniquement, toute requête avec Keep-Alive) pour utiliser avec succès L'authentification NTLM/Negotiate.
(L'inspecteur "Auth" de Fiddler va décomposer les blobs D'authentification NTLM pour vous, si vous n'avez pas encore jeté un oeil à cela.)
j'ai écrit un utilitaire pour décoder les blobs NTLM qui ont été envoyés dans les sessions IE et HttpWebRequest.
quand je regarde le HttpWebRequest et IE, ils demandent tous les deux le cryptage 56bit et 128bit du serveur. Voici le dump de la session en utilisant HttpWebRequest
==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: E20882B7
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
RESERVED2
RESERVED3
RESERVED4
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLM_NEGOTIATE_OEM
NTLMSSP_NEGOTIATE_UNICODE)
Domain :
Workstation:
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA
Voici la décharge de IE:
==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: A208B207
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
NTLMSSP_TARGET_TYPE_SHARE
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLMSSP_NEGOTIATE_UNICODE)
Domain : XXXX.UK
Workstation: XXX-X31
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA
dans les deux IE/HttpWebRequest, ils demandent à la fois 64 et 128bit de sécurité. Toutefois, pour la sécurité windows7, 128bit pour NTLM est devenue la sécurité par défaut, et sans cela, l'authentification échouera. Comme vous pouvez le voir à partir de la réponse du serveur, le serveur ne supporte 64 bits de cryptage.
Le lien suivant a une discussion sur un problème similaire rencontré par une autre personne. http://social.msdn.microsoft.com/Forums/en-US/ncl/thread/f68e8878-53e9-4208-b589-9dbedf851198
la raison pour laquelle IE fonctionne, au lieu de L'application gérée, est QU'IE ne demande pas réellement NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN, qui finissent par exiger le chiffrement. Toutefois, HttpWebRequest demande à la fois le sceau et le signe. Cela nécessite un chiffrement de 128bit, alors que la façon dont IE initialise NTLMSSP (sans sceau et signe), il ne nécessite pas de chiffrement. Par conséquent, IE fonctionne, alors que HttpWebRequest ne fonctionne pas. (voir le lien ci-dessus)
je pense que si vous changez votre politique de sécurité pour autoriser le cryptage 64bit pour NTLM, votre application de gestion de code fonctionnera. Ou alternativement, demandez au fournisseur de proxy de prendre en charge le cryptage 128bit pour NTLM.
Espérons que cette aide.
j'ai eu un problème similaire et utilisé les conseils dans le blog suivant pour résoudre le problème:
Vérifier le réglage suivant dans secpol.msc
. Il a résolu notre problème.
Local Security Policy
Local Policies
Security Options
Network security: Minimum session security
mis à:
require 128 only for client.
pouvez-vous essayer de définir L'en-tête User-Agent sur votre HttpWebRequest, à la même valeur que le paramètre IE8?
parfois, les serveurs ne vont pas contester correctement si l'agent-utilisateur n'est pas ce qu'ils attendent.
espérons que cette aide.
Est-ce la façon dont la procuration est-il attribué?
proxy.Credentials = CredentialCache.DefaultCredentials;
quand j'ai utilisé pour la dernière fois le proxy avec le HttpWebRequest il a été assigné comme ceci:
Attribuer un serveur proxy pour demander:
request.Proxy.Credentials = Credentials.GetProxyCredentials();
les Appels de méthode:
public static ICredentials GetProxyCredentials()
{
return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
}
configuration du proxy web.config
<system.net>
<defaultProxy enabled="true">
<proxy
autoDetect="False"
bypassonlocal="True"
scriptLocation="http://www.proxy.pac"
proxyaddress="http://proxy1.blah.com" />
</defaultProxy>
</system.net>
il pourrait être lié à ce qui est dans votre"CredentialCache". Essayez plutôt ceci:
proxy.Credentials = new NetworkCredential("username", "pwd", "domain");
Que pensez-vous de ceci:
HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
WebProxy proxyObject = new System.Net.WebProxy("http://10.0.0.1:8080/", true); //whatever your proxy address is
proxyObject.Credentials = CredentialCache.DefaultCredentials;
request.Proxy = proxyObject;
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
request.Accept = "*/*";
HttpWebResponse response = request.GetResponse() as HttpWebResponse;
Stream stream = response.GetResponseStream();