目前有個問題
瀏覽器上輸入ip後連接server時會跳出一個要求輸入帳號密碼的認證視窗
http://imgur.com/a/zlL2e
想問這個認證視窗是在server裡的哪個程式呼叫的?
謝謝
以下內容針對yvb提出的問題做回覆
這個BUG就像你推文所說的，不同瀏覽器對於認證失敗後的處理有所不同
，上頭是把這個情況當作是一個BUG，目標是希望能夠都是3次認證失敗導向
一個錯誤訊息的頁面
我對http只有接觸這個bug才去了解而已， HTTP status, HTTP header, HTTP auth
這邊都有去稍微了解，有找到server 裡對應到的code， HTTP cookie這部分還不是
很了解，沒有找到對應的code
至於認證的處理
當server判斷使用者沒通過認證會回401狀態，好像是由這裡來完成的
void send_r_unauthorized(request * req, const char *realm_name)
{
SQUASH_KA(req); req->response_status = R_UNAUTHORIZED;
if((req->http_version != HTTP09))
{
req_write(req, http_ver_string(req->http_version));
req_write(req, " 401 Unauthorized" CRLF);
print_http_headers(req);
req_write(req, "WWW-Authenticate: Basic realm=\".\"" );
req_write(req, realm_name); req_write(req, CRLF);
req_write(req, "Content-Type: " HTML CRLF CRLF); /* terminate header */
}
..
}
我在更改的時候也是在這附近更改，單純加入一個變數當作他送出認證的次數，超過
3次就不執行if的那段code，這樣雖然可以達到目的，但有個問題是，當我在網頁按f5或
是開啟新頁面連接時，我找不到一個正確位置來重置這個變數，導致它一直停留在錯誤訊
息頁面
當server在檢查使用者帳號密碼這部分，我有看到boa server裡有code是在做這方面的處
理，我對你所提到的那些方法不懂，所以不確定它裡面有沒有使用到那些方法。
謝謝
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.147.6.146
※ 文章網址: https://www.ptt.cc/bbs/LinuxDev/M.1486026867.A.54E.html

應該是 server 回應 401 的 HTTP狀態碼, 由瀏覽器自行產生的.看了一下boa源碼,該回應即response.c的send_r_unauthorized()

好，謝謝，我在研究一下，有問題可以用站內信問你嗎?

站內信當然可以,但我未必懂. 在此和大家一同討論應該更好.

我大概了解了，但我想請教另個問題，要如何設計瀏覽器在輸入3次錯誤後，自動導向一個錯誤訊息的頁面，主要是如何抓到瀏覽器輸入錯誤3次的值。

光靠401產生認證視窗的方式沒辦法,只能依賴瀏覽器本身行為,

Boa 是很久的東西為何還要用？

比如 IE 會在3次錯誤後停止嘗試, Chrome 仍繼續跳認證視窗.HTTP本身是stateless的, server無法確認是否同一瀏覽器錯幾次因此需要引入stateful機制如cookie/session/url-ext之類,使用如多數用戶網站的登入, 搭配後台程式進行驗證及計次等...

liang168,我是公司新人被叫去修產品BUG，裡面有用到boayyb,我瀏覽器帳號密碼輸入正確後，之後再連就不需要輸入帳號密碼，所以伺服器是不是已經有採用session..之類的方法，謝謝。

basic auth 瀏覽器會把他 cache 起來一段時間就是至於 session 或是 cookie 之類的要看你的 cgi 有沒有做

原來是貴公司的產品用到. 所以是視瀏覽器對 HTTP 認證失敗的後續行為不同為 bug? 不知您對 HTTP 這個協定中, 諸如HTTP status, HTTP header, HTTP auth, HTTP cookie 的了解情況如何; 以及認證這部分, 在產品中的內部運作流程又是如何,是直接改寫 boa 程式碼逹成, 或是使用 uClinux boa 的 auth搭配設定檔, 還是叫用 cgi/scripting 來處理認證?

我用站內信跟你說明，這邊回應有點麻煩。

發文者應該可以用大寫 E 編輯文章啊...編輯若非修改原內容, 而是追加, 回推文, 那寫在推文下較佳.其實 HTTP auth 最大的問題(缺點)就是定義得太簡單,缺少諸如檢查次數,要求登出等機制 (無法登出是否又會被當另一個bug?)所以一切要靠browser自定行為. 不知貴公司是怎樣的產品,登入成功的後續是靜態網頁?CGI?或是仍在boa中加怎樣的處理?若是另外使用CGI或scripting languages (asp,php...),那也許考慮把認證機制做成cookie/session型式會更好.是否一定堅持要使用HTTP auth ?雖然 HTTP auth 搭配 cookie 可能還是有 partial solution,但使用上應該還蠻蹩腳的...大致上是認證失敗就檢查是否有某cookie,沒有就設定初值,有就檢查是第幾次的值,然後重設新值或設定清除;若認證成功也要設定清除.

好，謝謝，我在研究一下。