HTTP规格：代理授权和授权头

问题描述

所以我想实现以下情形：

So I'm trying to implement the following scenario:

• 的申请是由基本身份验证保护。比方说，它托管在 app.com


• HTTP代理，在申请前，需要进行身份验证也是如此。它托管在 proxy.com

• An application is protected by Basic Authentication. Let's say it is hosted on app.com
• An HTTP proxy, in front of the application, requires authentication as well. It is hosted on proxy.com

因此​​用户必须提供代理，并在同一请求应用程序中都凭据，他也因此有不同的用户名/密码对：一对自己进行身份验证针对应用程序，而另一个用户名/密码对自己进行身份验证反对代理服务器。

The user must therefore provide credentials for both the proxy and the application in the same request, thus he has different username/password pairs: one pair to authenticate himself against the application, and another username/password pair to authenticate himself against the proxy.

读取规格后，我不是我应该如何实现这真的肯定。我在想什么做的是：

After reading the specs, I'm not really sure on how I should implement this. What I was thinking to do is:

1. 的用户发出一个HTTP请求到代理没有任何类型的身份验证。


2. 代理答案 407代理服务器身份验证键，返回的格式代理服务器进行身份验证标题：代理服务器进行身份验证：基本境界=proxy.com
   问题：这是代理服务器进行身份验证头设置是否正确？


3. 客户端然后重试与代理授权头的要求，那就是代理用户名中的Base64重新presentation：密码。


4. 这一次的代理验证请求，但然后用 401未授权头应用的答案。用户通过代理验证，而不是由应用程序。该应用程序将 WWW验证头像响应 WWW身份验证：基本境界=app.com 。 问题：这头值是正确的权


5. 客户端再次重试既具有代理授权头的要求，以及授权头与价值Base64编码重$ p $应用程序的的psentation用户名：密码


6. 此时，代理成功认证的请求，将请求转发给该认证用户以及应用程序。和客户端终于得到回一个响应。

1. The user makes an HTTP request to the proxy without any sort of authentication.
2. The proxy answers 407 Proxy Authentication Required and returns a Proxy-Authenticate header in the format of: "Proxy-Authenticate: Basic realm="proxy.com".
   Question: Is this Proxy-Authenticate header correctly set?
3. The client then retries the request with a Proxy-Authorization header, that is the Base64 representation of the proxy username:password.
4. This time the proxy authenticates the request, but then the application answers with a 401 Unauthorized header. The user was authenticated by the proxy, but not by the application. The application adds a WWW-Authenticate header to the response like WWW-Authenticate: Basic realm="app.com". Question: this header value is correct right?
5. The client retries again the request with both a Proxy-Authorization header, and a Authorization header valued with the Base64 representation of the app's username:password.
6. At this point, the proxy successfully authenticates the request, forwards the request to the application that authenticates the user as well. And the client finally gets a response back.

时的整个工作流程是否正确？

Is the whole workflow correct?

推荐答案

是的，看起来像你描述的情况有效的工作流程，而那些身份验证头似乎是正确的格式。

Yes, that looks like a valid workflow for the situation you described, and those Authenticate headers seem to be in the correct format.

这是有趣的是，这是可能的，尽管是不太可能的，对于一个给定的连接，以涉及该被链接在一起的多个代理，并且本身每一个可能需要验证。在这种情况下，每个中间代理的客户端本身将得到一个 407代理服务器身份验证消息，并重演与代理授权请求头;在代理服务器进行身份验证和代理授权标头是没有从一台服务器传递到单跳头接下来，但 WWW验证和授权是被认为是从客户端的终端到终端头最终的服务器上，通过中介机构通过逐字过去了。

It's interesting to note that it's possible, albeit unlikely, for a given connection to involve multiple proxies that are chained together, and each one can itself require authentication. In this case, the client side of each intermediate proxy would itself get back a 407 Proxy Authentication Required message and itself repeat the request with the Proxy-Authorization header; the Proxy-Authenticate and Proxy-Authorization headers are single-hop headers that do not get passed from one server to the next, but WWW-Authenticate and Authorization are end-to-end headers that are considered to be from the client to the final server, passed through verbatim by the intermediaries.

由于基本方案发出了明确的密码（Base64是一个可逆的编码），这是最常见的通过SSL使用。此方案是在一个不同的方式实现的，因为理想的是prevent从看到发送到最终服务器的密码代理：

Since the Basic scheme sends the password in the clear (base64 is a reversible encoding) it is most commonly used over SSL. This scenario is implemented in a different fashion, because it is desirable to prevent the proxy from seeing the password sent to the final server:

• 客户端打开一个SSL通道到代理发起请求，但不是提交常规HTTP请求，将提交（仍然以代理授权头），打开一个TCP隧道至远程服务器。


• 客户端然后创建的其他的SSL通道嵌套在第一个里面，在它传送包括授权头最后的HTTP消息。

• the client opens an SSL channel to the proxy to initiate the request, but instead of submitting a regular HTTP request it would submit a special CONNECT request (still with a Proxy-Authorization header) to open a TCP tunnel to the remote server.
• The client then proceeds to create another SSL channel nested inside the first, over which it transfers the final HTTP message including the Authorization header.

在这种情况下的代理只知道主机和端口连接到的，而不是被传输或以上的内SSL通道接收到的客户端。另外，使用嵌套信道允许客户端看到的代理和服务器的SSL证书，允许两者的身份进行认证。

In this scenario the proxy only knows the host and port the client connected to, not what was transmitted or received over the inner SSL channel. Further, the use of nested channels allows the client to "see" the SSL certificates of both the proxy and the server, allowing the identity of both to be authenticated.

这篇关于HTTP规格：代理授权和授权头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！