访问 Amazon S3 时需要 HTTP 407 代理身份验证
HTTP 407 Proxy Authentication Required while accessing Amazon S3
我已经尝试了所有方法，但我似乎无法解决这个问题，这个问题只发生在公司 proxy/firewall 背后的一个客户身上。我们的 Silverlight 应用程序连接到 Amazon S3 以获取 downloading/Uploading 一些文档。在一台客户端和一台客户端上，它 return 出现 407 错误，此后应用程序无法保存任何内容。
Inner Exception:
System.ServiceModel.ProtocolException: [UnexpectedHttpResponseCode]
Arguments: 407,Proxy Authentication Required
我们在不同的客户端遇到了类似的问题，但更多的是 CORS 问题。为了解决这个问题，我使用 cloud-front 来伪造一个 sub-domain 然后访问 S3 存储桶并解决了这个问题。我希望它也能解决此客户端的问题，但没有。
我已经尝试按照很多答案的建议将此代码添加到 web.config
<system.net>
<defaultProxy useDefaultCredentials="true" >
</defaultProxy>
</system.net>
我已阅读有关使用用户名和密码通过基本身份验证传递代理 headers 的文章，但我不确定这对我们有何帮助。代理服务器由客户端使用，它需要的任何身份验证都在我们的域之外。
**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 服务的任何调用 return 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 之间的区别以及何时使用它们。此外，切换到浏览器 http 的潜力 impacts/issues。
**Update 3**
有没有办法请求浏览器 运行 您的 in-browser Silverlight 应用程序处于受信任模式，它是否有助于绕过这个问题？
（答案 #2）
所以，很可能（对于像这个网络这样的企业环境），如果没有在 IE 中设置任何自定义代理设置，几乎什么都做不了，通常是由企业政策推动的。要利用这些代理设置，您需要使用 WebRequestCreator.BrowserHttp，它会在发出请求时自动使用浏览器的默认设置。
这两个客户端之间存在 table 差异 in the Microsoft docs。我猜你正在使用 BrowserHttp.
不支持的东西（可能设置自定义 headers 或读取原始响应 body）
出于安全原因，您无法 "ask" 浏览器的代理设置是什么并使用它们，所以这是一个棘手的情况。您 可以 按域指定浏览器与客户端处理，甚至针对特定请求（上面的同一页面描述了如何）；在这种情况下，您可以仅使用 ClientHttp 进行服务调用并使用 BrowserHttp 进行 S3 调用，从而完全避免该问题！
对于接下来的步骤，我会尝试这种方法；如果它不起作用，我会尝试将批发切换到 BrowserHttp 只是为了看看它是否绕过代理问题 （应用程序几乎没有机会真正工作，因为你可能使用 ClientHttp-only 选项）。
从长远来看，您可能需要考虑对服务进行更改，以便 BrowserHttp-only 应用程序可以使用它们（这需要您的 requests/responses 非常基础，但仅使用BrowserHttp 将保证您可以在几乎任何公司网络中工作。
由于您将其描述为一个 silverlight 应用程序，我假设您不能使用 "move browser to public network" 或 "try a different browser" 等经典浏览器代理故障排除来隔离问题。
您应该尝试隔离代理服务器，并让客户使用所需的代理身份验证。
应用程序正在发出请求，但它可能被透明代理拦截，或者结果可能来自您认为的网络服务器。
早期，401 错误与 web-auth 密切相关，而 407 则用于代理身份验证。
在架构上，分离是为了方便，Web 服务器可以同时具有 Web 服务器、代理和反向代理行为。
发生的情况是您客户的环境正在建立到目标的 Web 连接，但它从某个主机（可能是他们的网络，有时是提供商）接收到 HTTP 407 状态。几乎可以肯定的是，收到的请求没有被转发。您的应用程序所在的 HTTP 客户端需要提供主机所需的凭据。公司拥有足够复杂的环境，您的客户经常会说这是他们第一次听说这个（一些代理身份验证也是动态的或特定于目的地的）。
此外，在某些企业环境中，运营商将允许从代理身份验证服务中临时或永久列入白名单。你应该看看他们是否可以这样做，即使是暂时的，以确认不会有其他问题。
最后，听起来您的应用程序可能无法可靠地支持代理身份验证或他们在其环境中使用的代理身份验证类型。
运行 在受信任模式下可能是一项组策略，需要他们的 AD 管理员批准/将您的应用列入白名单。
我认为您面临的根本问题是代理需要 NTLM 身份验证，并且无论出于何种原因浏览器拒绝为您的应用提供该上下文。
证明这是一个 NTLM 身份验证问题的一种方法是使用 curl 进行测试 - 让它通过代理发出请求，然后编码应该更容易一些。 EG 以下 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 有效，那么只需让应用程序使用默认凭据（即浏览器会话可能提供也可能不提供）
我已经尝试了所有方法，但我似乎无法解决这个问题，这个问题只发生在公司 proxy/firewall 背后的一个客户身上。我们的 Silverlight 应用程序连接到 Amazon S3 以获取 downloading/Uploading 一些文档。在一台客户端和一台客户端上，它 return 出现 407 错误，此后应用程序无法保存任何内容。
Inner Exception:
System.ServiceModel.ProtocolException: [UnexpectedHttpResponseCode]
Arguments: 407,Proxy Authentication Required
我们在不同的客户端遇到了类似的问题，但更多的是 CORS 问题。为了解决这个问题，我使用 cloud-front 来伪造一个 sub-domain 然后访问 S3 存储桶并解决了这个问题。我希望它也能解决此客户端的问题，但没有。
我已经尝试按照很多答案的建议将此代码添加到 web.config
<system.net>
<defaultProxy useDefaultCredentials="true" >
</defaultProxy>
</system.net>
我已阅读有关使用用户名和密码通过基本身份验证传递代理 headers 的文章，但我不确定这对我们有何帮助。代理服务器由客户端使用，它需要的任何身份验证都在我们的域之外。
**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 服务的任何调用 return 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 之间的区别以及何时使用它们。此外，切换到浏览器 http 的潜力 impacts/issues。
**Update 3**
有没有办法请求浏览器 运行 您的 in-browser Silverlight 应用程序处于受信任模式，它是否有助于绕过这个问题？
（答案 #2）
所以，很可能（对于像这个网络这样的企业环境），如果没有在 IE 中设置任何自定义代理设置，几乎什么都做不了，通常是由企业政策推动的。要利用这些代理设置，您需要使用 WebRequestCreator.BrowserHttp，它会在发出请求时自动使用浏览器的默认设置。
这两个客户端之间存在 table 差异 in the Microsoft docs。我猜你正在使用 BrowserHttp.
出于安全原因，您无法 "ask" 浏览器的代理设置是什么并使用它们，所以这是一个棘手的情况。您 可以 按域指定浏览器与客户端处理，甚至针对特定请求（上面的同一页面描述了如何）；在这种情况下，您可以仅使用 ClientHttp 进行服务调用并使用 BrowserHttp 进行 S3 调用，从而完全避免该问题！
对于接下来的步骤，我会尝试这种方法；如果它不起作用，我会尝试将批发切换到 BrowserHttp 只是为了看看它是否绕过代理问题 （应用程序几乎没有机会真正工作，因为你可能使用 ClientHttp-only 选项）。
从长远来看，您可能需要考虑对服务进行更改，以便 BrowserHttp-only 应用程序可以使用它们（这需要您的 requests/responses 非常基础，但仅使用BrowserHttp 将保证您可以在几乎任何公司网络中工作。
由于您将其描述为一个 silverlight 应用程序，我假设您不能使用 "move browser to public network" 或 "try a different browser" 等经典浏览器代理故障排除来隔离问题。
您应该尝试隔离代理服务器，并让客户使用所需的代理身份验证。
应用程序正在发出请求，但它可能被透明代理拦截，或者结果可能来自您认为的网络服务器。
早期，401 错误与 web-auth 密切相关，而 407 则用于代理身份验证。
在架构上，分离是为了方便，Web 服务器可以同时具有 Web 服务器、代理和反向代理行为。
发生的情况是您客户的环境正在建立到目标的 Web 连接，但它从某个主机（可能是他们的网络，有时是提供商）接收到 HTTP 407 状态。几乎可以肯定的是，收到的请求没有被转发。您的应用程序所在的 HTTP 客户端需要提供主机所需的凭据。公司拥有足够复杂的环境，您的客户经常会说这是他们第一次听说这个（一些代理身份验证也是动态的或特定于目的地的）。
此外，在某些企业环境中，运营商将允许从代理身份验证服务中临时或永久列入白名单。你应该看看他们是否可以这样做，即使是暂时的，以确认不会有其他问题。
最后，听起来您的应用程序可能无法可靠地支持代理身份验证或他们在其环境中使用的代理身份验证类型。
运行 在受信任模式下可能是一项组策略，需要他们的 AD 管理员批准/将您的应用列入白名单。
我认为您面临的根本问题是代理需要 NTLM 身份验证，并且无论出于何种原因浏览器拒绝为您的应用提供该上下文。
证明这是一个 NTLM 身份验证问题的一种方法是使用 curl 进行测试 - 让它通过代理发出请求，然后编码应该更容易一些。 EG 以下 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 有效，那么只需让应用程序使用默认凭据（即浏览器会话可能提供也可能不提供）