407 требуется аутентификация - вызов не отправлен

обновление:
Если вы только что пришли к этому вопросу, общая суть в том, что я пытаюсь сделать HttpWebRequest через прокси-сервер, и я получаю 407 от нашего странного прокси-сервера. IE, Firefox, Chrome все удается успешно согласовать прокси-сервер, как и приложения Adobe Air. Может быть важно, что веб-установщик Google Chrome на самом деле терпит неудачу, и мы должны использовать автономный установщик.

благодаря ссылке Яна я получил его до следующего ступень. Теперь он отправляет токен обратно на прокси-сервер, однако 3-й этап не проходит, поэтому запрос с хэшем имени пользователя/пароля не отправляется .NET и, следовательно, HTML не возвращается.

Я использую:

  • IE6 user-agent
  • Windows 7
  • прокси-Scansafe
  • .NET 3.5

вот последний код, который приравнивается к логи ниже:

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

в исключение

Требуется Аутентификация WebException (407).

прокси используется

прокси-клиент-это Scansafe аппаратное устройство в нашей серверной комнате, которое (после аутентификации с NTLM) затем направляет ваш HTTP-трафик на свои серверы для фильтрации трафика.

System.Net вывод трассировки

IE успешно переговоры прокси

решение

Я действительно не нашел решение, но благодаря Feroze и Eric я нашел обходной путь и обнаружил, что фактический прокси (а не его конфигурация) является основной проблемой. Это может быть неясная проблема с 3 переменными: реализация .NET HttpWebRequest, Windows 7 и конечно, аппаратный клиент Scansafe, который находится в нашей стойке; но без запроса поддержки MSDN я не узнаю.

8
c# http-status-code-407 httpwebrequest proxy

8 ответов

Если вы хотите установить учетные данные для прокси-сервера, не следует ли установить учетные данные для запроса.Прокси-объект, а не объект запроса?

http://msdn.microsoft.com/en-us/library/system.net.webproxy.credentials.aspx

кроме того, имейте в виду, что вам нужно сделать запрос HTTP/1.1 (или технически любой запрос с Keep-Alive), чтобы успешно использовать аутентификацию NTLM/Negotiate.

(инспектор "Auth" скрипача разложит NTLM authentication blobs для вас, если вы еще не взглянули на это.)

8

Я написал утилиту для декодирования NTLM blobs, которые были отправлены в сеансах IE и HttpWebRequest.

когда я смотрю на HttpWebRequest и IE, они оба запрашивают 56-битное и 128-битное шифрование с сервера. Вот дамп сеанса с использованием 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

вот дамп из 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

в обоих IE / HttpWebRequest они запрашивают как 64, так и 128-битную безопасность. Однако для windows7 была сделана 128-битная безопасность для NTLM по умолчанию, и без этого, аутентификация завершится ошибкой. Как вы можете видеть из ответа сервера, сервер поддерживает только 64-битное шифрование.

по ссылке есть обсуждение подобной проблемы на другого человека. http://social.msdn.microsoft.com/Forums/en-US/ncl/thread/f68e8878-53e9-4208-b589-9dbedf851198

причина, по которой IE работает вместо управляемого приложения, заключается в том, что IE фактически не запрашивает NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN, которые в конечном итоге требуют шифрования. Однако HttpWebRequest запрашивает как печать|знак. Для этого требуется 128-битное шифрование, тогда как способ инициализации NTLMSSP (без печати и знака) IE не требует шифрования. Следовательно, IE работает, тогда как HttpWebRequest-нет. (см. ссылку выше)

Я думаю, что если вы измените политику безопасности, чтобы разрешить 64-битное шифрование для NTLM, ваше приложение управляемого кода будет работать. Или, наоборот, попросите поставщика прокси-сервера поддержать 128-битное шифрование для NTLM.

надеюсь, что это помогает.

6

У меня была аналогичная проблема и я использовал советы в следующем сообщении в блоге для решения проблемы:

http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy-authentication-required.aspx

3

Проверьте следующий параметр в secpol.msc. Это исправило нашу проблему.

Local Security Policy 
    Local Policies
        Security Options
            Network security: Minimum session security

значение:

require 128 only for client.

enter image description here

1

можете ли вы попробовать установить заголовок User-Agent в вашем HttpWebRequest на то же значение, что и IE8?

иногда серверы не будут правильно оспаривать, если пользовательский агент не то, что они ожидают.

надеюсь, что это помогает.

0

это как посредник присвоил?

proxy.Credentials = CredentialCache.DefaultCredentials;

когда я последний раз использовал прокси с HttpWebRequest, он был назначен следующим образом:

назначить прокси-сервера запрос:

request.Proxy.Credentials = Credentials.GetProxyCredentials();

вызывает метод:

    public static ICredentials GetProxyCredentials()
    {
        return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
    }

Настройка прокси в интернете.config

<system.net>
  <defaultProxy enabled="true">
    <proxy
      autoDetect="False"
      bypassonlocal="True"
      scriptLocation="http://www.proxy.pac"
      proxyaddress="http://proxy1.blah.com" />
  </defaultProxy>
</system.net>
0

это может быть связано с тем, что находится в вашем "CredentialCache". Попробуйте вместо этого:

proxy.Credentials = new NetworkCredential("username", "pwd", "domain");
0

Как насчет этого:

        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();
0