HTTP規格：代理授權和授權頭

Question

所以我想實現以下情景：

• 的申請是由基本身份驗證保護。假設它位於app.com
• 在應用程序前面的HTTP代理也需要身份驗證。它是在proxy.com

託管因此，用戶必須提供代理，並在同一個請求的應用既證書，他也因此有不同的用戶名/密碼對：一對，以驗證自己對應用程序，而另一個用戶名/密碼對，以對代理進行身份驗證。

閱讀規範後，我不太確定我應該如何實現這一點。我想要做的是：

1. 用戶向代理髮出HTTP請求，而不進行任何類型的身份驗證。
2. 代理回答407 Proxy Authentication Required，並返回Proxy-Authenticate標題，格式爲："Proxy-Authenticate: Basic realm="proxy.com"。
   問題：這Proxy-Authenticate標題設置正確嗎？
3. 客戶端然後用Proxy-Authorization標題重試請求，即代理username:password的Base64表示。
4. 這次代理驗證請求，但應用程序使用401 Unauthorized標題進行回答。用戶由代理進行了身份驗證，但不是由應用程序進行身份驗證。該應用程序將一個WWW-Authenticate標題添加到響應中，如WWW-Authenticate: Basic realm="app.com"。 問題：此標題值是否正確？
5. 客戶端再次嘗試使用Proxy-Authorization標頭和Authorization標頭，並使用應用程序的username:password的Base64表示值重新發送請求。
6. 此時，代理成功驗證請求，並將請求轉發給驗證用戶的應用程序。客戶終於得到迴應。

整個工作流程是否正確？

Answer 1

是的，這看起來像您描述的情況的有效工作流程，並且這些驗證標頭似乎是正確的格式。

有趣的是，儘管不太可能，給定的連接可能涉及多個連接在一起的代理，並且每個代理本身都可能需要身份驗證。在這種情況下，每個中間代理的客戶端將自己獲得一個407 Proxy Authentication Required消息，並且自己用Proxy-Authorization頭重複該請求; Proxy-Authenticate和Proxy-Authorization標頭是單跳標頭，不會從一臺服務器傳遞到下一臺服務器，但WWW-Authenticate和Authorization是端到端標頭，被認爲是從客戶端到最終服務器的端到端標頭，通過逐字傳遞中介。

由於Basic方案在明文中發送密碼（base64是一種可逆編碼），因此它最常用於SSL。這種情況是以不同的方式實現的，因爲希望防止代理看到發送到最終服務器的密碼：

• 客戶端打開一個到代理的SSL通道來發起請求，而不是提交一個普通的HTTP請求，它會提交a special CONNECT request（仍然帶有一個Proxy-Authorization頭）來打開到遠程服務器的TCP隧道。
• 然後客戶端繼續創建另一個 SSL通道嵌套在第一個SSL通道中，通過它傳輸最終的HTTP消息，包括Authorization標頭。

在這種情況下，代理只知道客戶端連接到的主機和端口，而不知道通過內部SSL通道發送或接收的內容。此外，使用嵌套通道允許客戶端「查看」代理服務器和服務器的SSL證書，從而允許兩者的身份驗證。