7

我已经尝试了所有方法，但我似乎无法解决仅在公司代理/防火墙后面的一个客户端发生的问题。我们的 Silverlight 应用程序连接到 Amazon S3 以下载/上传一些文档。在一个客户端和一个客户端上，它仅返回 407 错误，之后应用程序无法保存任何内容。

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

我们在不同的客户那里也遇到过类似的情况，但更多的是 CORS 问题。为了解决这个问题，我使用 cloud-front 来伪造一个子域，然后访问 S3 存储桶并解决了这个问题。我希望它也能与这个客户一起解决它，但它没有。

我已尝试按照很多答案的建议将此代码添加到 web.config

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

我已阅读有关使用用户名和密码通过基础身份验证传递代理标头的文章，但我不确定这将如何帮助我们。代理服务器由客户端使用，它需要的任何身份验证都在我们的域之外。

**Additional Information**

Silverlight 代码引用了 2 个服务。一个是我们的 wcf 服务，它检索应用程序的所有数据。一种是使用 amazon Soap api 的 Amazon S3 服务，其端点位于http://s3.amazonaws.com/doc/2006-03-01/AmazonS3.wsdl？

如果我进入我们的应用程序并且只使用不调用 Amazon S3 api 的系统部分，则应用程序可以正常工作。一旦我进入调用 S3 的系统部分，问题就开始了。有趣的是，对 S3 的调用很顺利，我可以很好地检索文档，但是对我们的 wcf 服务的任何调用都会返回 407。

有任何想法吗？

**Update 2**

根据 Elliot Nelson 的评论，我检查了我们在应用程序中用于发出 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 应用程序，这是否有助于绕过此问题？

4

3 回答 3

3

（答案＃2）

因此，最有可能（对于像这个网络这样的公司环境），如果没有在 IE 中设置任何自定义代理设置，几乎什么都做不了，通常是由公司策略推动的。要利用这些代理设置，您需要使用WebRequestCreator.BrowserHttp，它会在发出请求时自动使用浏览器的默认设置。

Microsoft 文档中提供了这两个客户端之间的差异表。我猜您正在使用BrowserHttp.

出于安全原因，您不能“询问”浏览器它的代理设置是什么并使用它们，所以这是一个棘手的情况。您可以按域指定浏览器与客户端处理，甚至可以指定特定请求（上面的同一页描述了如何处理）；在这种情况下，您可能可以只使用 ClientHttp 进行服务调用，使用 BrowserHttp 进行 S3 调用，从而完全避免这个问题！

对于接下来的步骤，我会尝试这种方法；如果它不起作用，我会尝试将批发切换到 BrowserHttp以查看它是否绕过代理问题（应用程序实际上几乎不可能工作，因为您可能正在使用仅限 ClientHttp 选项）。

从长远来看，您可能需要考虑对您的服务进行更改，以便它们可供仅 BrowserHttp 的应用程序使用（这将要求您在请求/响应中非常基础，但仅使用 BrowserHttp 可以保证您工作在几乎任何公司网络中）。

于 2018-12-17T23:32:29.870 回答
2

在受信任模式下运行可能是一项组策略，需要他们的 AD 管理员批准/将您的应用列入白名单。

我认为您面临的根本问题是代理需要 NTLM 身份验证，并且无论出于何种原因，浏览器都拒绝为您的应用程序提供该上下文。

证明它是 NTLM 身份验证问题的一种方法是使用 curl 进行测试 - 让它通过代理生成一个 req，然后它应该更容易编码。例如，以下 curl 将让您通过 99% 的 Windows 公司代理（假设代理位于 proxy-host.corp:3128）：

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

注意告诉 curl使用--proxy-user :当前用户会话来执行 NTLM 质询。

因此，如果您可以让客户端运行它，您至少可以识别 NTLM 工作，那么只需让应用程序使用默认凭据（可能由浏览器提供也可能不提供）执行 NTLM 质询会议）

于 2018-12-20T03:09:12.350 回答
0

由于您将其描述为 Silverlight 应用程序，因此我假设您不能使用经典的浏览器代理故障排除（例如“将浏览器移动到公共网络”或“尝试不同的浏览器”）来隔离问题。

您应该尝试隔离代理服务器，并让客户使用所需的代理身份验证。

应用程序正在发出请求，但它可能被透明代理拦截，或者结果可能来自您认为的 Web 服务器。

在早期，401 错误与 web-auth 密切相关，而 407 则与 proxy-auth 相关。

从架构上讲，分离是一种方便，Web 服务器可以同时具有 Web 服务器、代理和反向代理行为。

发生的情况是您的客户环境正在与目标建立 Web 连接，但它从某个主机（可能是他们的网络，有时是提供商）接收到 HTTP 407 状态。几乎可以肯定的是，请求是收到而不是转发的。您的应用程序所在的 HTTP 客户端需要提供主机所需的凭据。公司拥有足够复杂的环境，您的客户经常会说这是他们第一次听说这一点（一些代理身份验证也是动态的或特定于目标的）。

此外，在某些公司环境中，运营商将允许代理身份验证服务的临时或永久白名单。您应该看看他们是否可以这样做，即使是暂时的，以确认不会出现其他问题。

最后，听起来您的应用程序可能不可靠地支持代理身份验证，或者他们在其环境中使用的代理身份验证类型。

于 2018-12-19T00:42:59.587 回答