所以我正在尝试实现以下场景:
- 应用程序受基本身份验证保护。假设它托管在
app.com
上
- 在应用程序前面的 HTTP 代理也需要身份验证。它托管在
proxy.com
因此,用户必须在同一个请求中为代理和应用程序提供凭据,因此他有不同的用户名/密码对:一对用户名/密码对应用程序进行身份验证,另一个用户名/密码对对应用程序进行身份验证代理。
阅读规范后,我不太确定应该如何实现它。我想做的是:
- 用户在没有任何身份验证的情况下向代理发出 HTTP 请求。
- 代理回答
407 Proxy Authentication Required
并返回Proxy-Authenticate
header ,格式为:"Proxy-Authenticate: Basic realm="proxy. com”
。
问题:Proxy-Authenticate
header 设置是否正确? - 客户端然后使用
Proxy-Authorization
header 重试请求,这是代理username:password
的 Base64 表示。 - 这一次代理对请求进行身份验证,但随后应用程序使用
401 Unauthorized
header 进行响应。用户已通过代理进行身份验证,但未通过应用程序进行身份验证。应用程序将WWW-Authenticate
header 添加到响应中,例如WWW-Authenticate: Basic realm="app.com"
。 问题:这个 header 值是正确的吗? - 客户端再次使用
Proxy-Authorization
header 和Authorization
header 重试请求,该 header 的值以应用程序的username:password< 的 Base64 表示形式表示
。 - 此时,代理成功验证了请求,并将请求转发给对用户进行身份验证的应用程序。客户最终得到回复。
整个工作流程是否正确?
最佳答案
是的,对于您描述的情况,这看起来像是一个有效的工作流,而且那些 Authenticate header 的格式似乎正确。
有趣的是,尽管不太可能,给定的连接可能涉及多个链接在一起的代理,并且每个代理本身都需要身份验证。在这种情况下,每个中间代理的客户端自己会返回一个 407 Proxy Authentication Required
消息,并且自己用 Proxy-Authorization
header 重复请求; Proxy-Authenticate
和 Proxy-Authorization
header 是单跳 header ,不会从一个服务器传递到下一个服务器,但 WWW-Authenticate
和 Authorization
是端到端 header ,被认为是从客户端到最终服务器,由中介逐字传递。
由于 Basic
方案以明文形式发送密码(base64 是一种可逆编码),因此最常用于 SSL。这种情况以不同的方式实现,因为希望防止代理看到发送到最终服务器的密码:
- 客户端打开到代理的 SSL channel 以发起请求,但它不会提交常规的 HTTP 请求,而是提交 a special
CONNECT
request (仍然带有Proxy-Authorization
header )以打开到远程服务器的 TCP 隧道。 - 然后,客户端继续创建嵌套在第一个 channel 内的另一个 SSL channel ,它通过该 channel 传输最终的 HTTP 消息,包括
Authorization
header 。
在这种情况下,代理只知道客户端连接到的主机和端口,不知道通过内部 SSL channel 传输或接收的内容。此外,嵌套 channel 的使用允许客户端“看到”代理和服务器的 SSL 证书,从而可以验证两者的身份。
关于HTTP 规范 : Proxy-Authorization and Authorization headers,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10023636/