Как проверить подлинность .NET2 Webservice с прокси-сервером SQUID

У меня есть небольшая утилита, которая является клиентом SOAP WebService. SOAP-прокси генерируется из WSDL. Он работал нормально.Как проверить подлинность .NET2 Webservice с прокси-сервером SQUID

Теперь клиент хочет использовать прокси-сервер SQUID, но отказывает в аутентификации моего клиента SOAP.

Я уже пробовал:

MyWebservice ws = new MyWebservice(); 
// set URL etc. 
// login for the actual service, this part works 
HeaderLogin hl = new HeaderLogin(); 
hl.username = svcLogin; 
hl.password = svcPassword; 
ws.HeaderLoginValue = hl; 

// setting up the Proxy of the Proxy 
//ws.Proxy = System.Net.WebRequest.GetSystemWebProxy(); 
ws.Proxy = System.Net.WebRequest.DefaultWebProxy; 

//ws.Proxy.Credentials = CredentialCache.DefaultCredentials;     
ws.Proxy.Credentials = new NetworkCredential(proxyUser, proxyPassword, proxyDomain);

Но я продолжаю получать HTTP 407 ошибка: требуется проверка подлинности прокси.

SQUID (squid/2.7.STABLE4) предназначен для использования NTLM и AD для аутентификации. Кажется, что все работает нормально: есть другие клиенты WebService, которые проходят через Proxy OK.

У меня нет прямого доступа к сайту, но только некоторые лог-файлы, на которые нужно смотреть. Самое замечательное - это то, что я вижу в файлах PCAP (Wireshark). Когда я создаю NetworkCredential с именем пользователя = «Хенк», домен = «TEST» он показывает в PCAP, как

... HTTP CONNECT someurl:443 HTTP/1.1 , NTLMSSP_AUTH, User: T\H

И когда я смотрю на PCAP для рабочего обслуживания

... HTTP CONNECT someurl:443 HTTP/1.0 , NTLMSSP_AUTH, User: TEST\Henk

И в SQUID acces.log все попытки показаны как:

... 0 192.168.15.95 TCP_DENIED/407 1759 CONNECT someurl:443 - NONE/- text/html
... 32 192.168.15.95 TCP_DENIED/407 2055 CONNECT someurl:443 - NONE/- text/html
... 31 192.168.15.95 TCP_DENIED/407 1759 CONNECT someurl:443 - NONE/- text/html

Бетонные вопросы:

любые известные проблемы с .NET2 SOAP и Squid?
есть дисплей TEST \ Henk как T \ H значительный?
что-нибудь еще я должен искать?

источник

2010-07-14 Henk Holterman

Любая вещь, чтобы проверить: где PROXYUSER, ProxyPassword и proxyDomain приходит? Возможно ли, что они были некорректны до достижения этой точки? 'proxyUser = form.Fields [" proxyUser "] [0]' вместо 'proxyUser = form.Fields [" proxyUser "]' может быть? – Stobor

@Stobor: Хороший вопрос, но я бы назвал это «систематическим», а не «случайным». Все проверяется и проверяется дважды. –

@ Хенк - ты когда-нибудь это решал? Я сталкиваюсь с той же проблемой, используя WebClient, который отказывается пройти аутентификацию с помощью прокси-сервера Squid, несмотря на то, что все браузеры аутентифицируются с помощью прокси-сервера, а WebClient работает, если отключить проверку подлинности. –

T \ H может быть признаком того, что в качестве строки ASCII используется строка Юникода. Поскольку символы Юникода - это два байта (наиболее распространенный случай в Windows), если вы интерпретируете их как ASCII, вы получаете реальный символ и байт с нулевым терминатором.

Я бы не ожидал увидеть этот тип ошибки в приложении .NET, но вы никогда не знаете.

источник

2010-07-19 18:33:05 Nasko

Я попробую завтра, но я думаю, что есть флаг в заголовках под названием UnicodeNegotiate. Вещь T \ H может исходить от WireShark. –

Вы можете посмотреть необработанные байты в WireShark, который покажет вам, является ли это WireShark или просто отправителем данных. – Nasko

Мне понравилось это предложение, вы протестировали его Хенк? – Segfault

Я вижу, что журнал squid показывает, что доступ запрещен someurl: 443 ... port 443 - это безопасный канал канала (SSL). В обычной практике веб-сервисы, размещенные на SSL, требуют определенной аутентификации. пожалуйста, проверьте требования к учетным записям webservice. вам может потребоваться передать учетные данные или подтвердить подлинность себя как действительного клиента через сертификат.

источник

2010-07-21 19:30:37

ajay, вы правы, но у нас есть все это (и работает). Это просто прокси, и ошибка 407 блокирует нас. –

вы можете попробовать установить «http_access allow» в домен в вашей конфигурации squid –

Возможно, соединение NTLM переработано до завершения соединения, в результате чего будет получен новый/второй запрос анонимного соединения и ошибка 407.

Попробуйте переопределить метод GetWebRequest (Uri uri) и установить для свойства KeepAlive значение false.

Отредактируйте Reference.cs файл со следующим:

protected override WebRequest GetWebRequest(Uri uri) 
{ 
    HttpWebRequest webRequest = (HttpWebRequest)base.GetWebRequest(uri); 
    webRequest.KeepAlive = false; 
    return webRequest; 
}

Просто помните, что обновление веб-ссылки вызовет Visual Studio, чтобы восстановить файл, и вы должны изменить файл снова.

источник

2010-07-22 12:33:19

Я не могу проверить это до следующей недели, но я бы предположил, что это не проблема, я вижу в журналах, что другие (рабочие) клиенты также используйте KeepAlive = true. –

вы можете попробовать добавить «http_access позволяют» к домену в вашем кальмара конфигурации

источник

2010-07-23 11:10:06

Как проверить подлинность .NET2 Webservice с прокси-сервером SQUID

ответ

Смежные вопросы