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

Question

Обновление:
Если вы только что пришли к этому вопросу, основная суть в том, что я пытаюсь сделать 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 и Эрику я нашел обходной путь и обнаружил, что основной проблемой является фактический прокси (а не его конфигурация). Это может быть неясной проблемой с 3 переменными: реализация .NET HttpWebRequest, Windows 7 и, конечно, аппаратный клиент Scansafe, который находится в нашей стойке; но без запроса поддержки MSDN я не узнаю.

Answer 1

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

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

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

(Инспектор Fiddler "Auth" разложит для вас BLOB-объекты аутентификации NTLM, если вы еще не посмотрели.)

Answer 2

Я написал утилиту для декодирования BLOB-объектов NTLM, отправленных в сеансах 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 запрашивает как SEAL | SIGN. Это требует 128-битного шифрования, тогда как способ, которым IE инициализирует NTLMSSP (без SEAL & SIGN), не требует шифрования. Следовательно, IE работает, а HttpWebRequest - нет. (см. ссылку выше)

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

Надеюсь, это поможет.

Answer 3

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

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

Answer 4

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

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

Установить на:

require 128 only for client. 

Answer 5

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

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

Answer 6

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

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

Answer 7

Это способ назначения прокси?

proxy.Credentials = CredentialCache.DefaultCredentials;

Когда я последний раз использовал прокси с HttpWebRequest, он был назначен так:

Назначить прокси на запрос:

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

Метод вызовов:

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

Настройка прокси в 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>

Answer 8

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

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

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