HTTP 407 прокси-аутентификация требуется при доступе к Amazon S3

Question

Я перепробовал все, но не могу решить эту проблему, которая возникает только для одного клиента за корпоративным прокси / брандмауэром.Наше приложение Silverlight подключается к Amazon S3 для загрузки / выгрузки некоторых документов.Только на одном клиенте и на одном клиенте возвращается ошибка 407. После этого приложение не может что-либо сохранить.

Inner Exception:
 System.ServiceModel.ProtocolException: [UnexpectedHttpResponseCode]
Arguments: 407,Proxy Authentication Required

У нас было что-то похожее на другом клиенте, но была проблема CORS.Чтобы решить эту проблему, я использовал облачный фронт для фальсификации субдомена, который затем обращается к корзине S3, и это решило проблему.Я надеялся, что это исправит это и с этим клиентом, но это не так.

Я пытался добавить этот код в web.config, как было предложено многими ответами

 <system.net>
      <defaultProxy useDefaultCredentials="true" >
      </defaultProxy>
   </system.net>

У меня естьПрочитайте статьи о передаче заголовков прокси с базовой аутентификацией, используя имя пользователя и пароль, но я не уверен, как это нам поможет.Прокси-сервер используется клиентом, и любая необходимая аутентификация находится за пределами нашего домена.

**Additional Information**

Код Silverlight ссылается на 2 службы.Одним из них является наш сервис wcf, который извлекает все данные для приложения.Одним из них является сервис Amazon S3, использующий API Amazon Soap, конечной точкой которого является http://s3.amazonaws.com/doc/2006-03-01/AmazonS3.wsdl?

Если я захожу в наше приложение и использую только часть системы, которая не выполняет никаких вызовов к Amazon S3API приложение отлично работает.Как только я перехожу к части системы, которая выполняет вызов на S3, проблема начинается.как ни странно, звонок на S3 проходит нормально, и я могу получить документацию в порядке, но затем любые вызовы нашей службы wcf возвращают 407.

Есть идеи?

**Update 2**

Основываясь на комментариях Эллиота Нельсона, я проверяю стек, который мы использовали для выполнения http-запросов в нашем приложении.Оказывается, мы используем клиентский http для запросов http и https по умолчанию.Вот код, который мы имеем в конструкторе App.xaml

  public App()
        {
            Startup += Application_Startup;
            UnhandledException += Application_UnhandledException;

            InitializeComponent();

            WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
            WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

        }

Теперь, чтобы понять различия между clienthttp и browserhttp и когда их использовать.Кроме того, потенциальные последствия / проблемы перехода на browserhttp.

**Update 3**

Есть ли способ запросить браузеры запустить приложение Silverlight в браузере в доверенном режиме и поможет ли это обойти эту проблему?

Answer 1

Поскольку вы описали это как приложение Silverlight, я собираюсь предположить, что вы не можете использовать классическое устранение неполадок браузера-прокси, например «переместить браузер в общедоступную сеть» или «попробовать другой браузер», чтобы изолировать проблему.

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

Приложение делает запрос, но оно может быть перехвачено прозрачным прокси или результатомможет исходить от того, что вы считаете веб-сервером.

В первые дни ошибка 401 была довольно строго связана с веб-аутентификацией, а 407 - с прокси-аутентификацией.

В архитектурном отношении разделение является удобным, веб-сервер может работать как с веб-сервером, так и с прокси и обратным прокси.

Что происходит, если среда вашего клиента устанавливает веб-соединение с пунктом назначения, но получает статус HTTP 407 от какого-либо хоста, возможно, от его сети или иногда от провайдера.Почти наверняка запрос получен не переадресован.Клиент HTTP, в котором живет ваше приложение, должен предоставить учетные данные, необходимые для хоста.В компаниях существуют достаточно сложные среды, в которых ваш клиент часто говорит, что впервые слышит об этом (некоторые прокси-аутентификации также являются динамическими или зависят от места назначения).

Кроме того, в некоторых корпоративных средахОператор разрешит временный или постоянный белый список из прокси-аутентификации.Вы должны увидеть, могут ли они сделать это, даже временно, чтобы подтвердить, что других проблем не будет.

В конце концов, похоже, что ваше приложение может не поддерживать надежную аутентификацию прокси-сервера или прокси-сервер.-такого типа они используют в своей среде.

Answer 2

Работа в доверенном режиме - это, вероятно, групповая политика, которая требует от администраторов AD одобрения / внесения в белый список вашего приложения.

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

Один из способов доказать, что это проблема с аутентификацией NTLM, - это проверить с помощью curl - заставить его сделать запрос через прокси-сервер, тогда его будет немного проще кодировать.Например, следующий локоть проведет вас через 99% корпоративных прокси-серверов Windows (при условии, что прокси находится на proxy-host.corp: 3128):

C:\> curl.exe -v --proxy proxy-host:3128 --proxy-user : --proxy-ntlm https://www.google.com

ПРИМЕЧАНИЕ --proxy-user : указывает curl использовать текущий пользовательский сеанс для выполнения вызова NTLM.

Так что, если вы можете заставить клиента выполнить это, вы можете по крайней мере определить, что NTLM работает, тогда это простовопрос о том, чтобы приложение выполняло вызов NTLM с использованием учетных данных по умолчанию (которые могут или не могут быть предоставлены сеансом браузера)

Answer 3

(Ответ # 2)

Таким образом, наиболее вероятно (для корпоративных сред, таких как эта сеть), почти ничего не может быть сделано без каких-либо пользовательских настроек прокси-сервера, установленных в IE, обычно навязываемых корпоративной политикой.Чтобы воспользоваться этими настройками прокси, вы хотите использовать WebRequestCreator.BrowserHttp, который автоматически использует настройки браузера по умолчанию при отправке запросов.

В Microsoft есть таблица различий между этими двумя клиентами документы .Я предполагаю, что вы использовали что-то (возможно, устанавливали пользовательские заголовки или читали необработанное тело ответа), которое не поддерживалось в BrowserHttp.

По соображениям безопасности, вы не можете «спросить» браузер, чтоего настройки прокси и использовать их, так что это сложная ситуация.Вы можете указать обработку браузера или клиента по доменам или даже для конкретного запроса (та же страница выше описывает, как);в этом случае вы можете обойтись без использования только ClientHttp для вызовов службы и BrowserHttp для вызовов S3 и вообще избежать этой проблемы!

В следующих шагах я бы попробовал этот подход;если это не сработает, я бы попробовал переключиться на BrowserHttp , просто чтобы обойти проблему с прокси (практически нет шансов, что приложение действительно будет работать, поскольку вы, вероятно, используете ClientHttp-onlyварианты).

В долгосрочной перспективе вы можете рассмотреть возможность внесения изменений в свои службы, чтобы их можно было использовать в приложении только для BrowserHttp (для этого потребуется, чтобы вы были довольно просты в своих запросах / ответах, но использовали толькоBrowserHttp будет гарантией того, что вы будете работать практически в любой корпоративной сети).