作者carpo5279 (carpo5279)
看板LinuxDev
標題[問題] webserver boa 問題
時間Thu Feb 2 17:14:24 2017
目前有個問題
瀏覽器上輸入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://webptt.com/m.aspx?n=bbs/LinuxDev/M.1486026867.A.54E.html
1F：推 yvb: 應該是 server 回應 401 的 HTTP狀態碼, 由瀏覽器自行產生的. 02/03 06:29
2F：→ yvb: 看了一下boa源碼,該回應即response.c的send_r_unauthorized() 02/03 06:43
3F：→ carpo5279: 好，謝謝，我在研究一下，有問題可以用站內信問你嗎? 02/03 09:51
4F：推 yvb: 站內信當然可以,但我未必懂. 在此和大家一同討論應該更好. 02/03 18:03
5F：→ carpo5279: 我大概了解了，但我想請教另個問題，要如何設計瀏覽器 02/05 23:02
6F：→ carpo5279: 在輸入3次錯誤後，自動導向一個錯誤訊息的頁面，主要是 02/05 23:04
7F：→ carpo5279: 如何抓到瀏覽器輸入錯誤3次的值。 02/05 23:06
8F：推 yvb: 光靠401產生認證視窗的方式沒辦法,只能依賴瀏覽器本身行為, 02/06 19:44
9F：→ liang168: Boa 是很久的東西為何還要用？ 02/06 19:46
10F：→ yvb: 比如 IE 會在3次錯誤後停止嘗試, Chrome 仍繼續跳認證視窗. 02/06 19:46
11F：→ yvb: HTTP本身是stateless的, server無法確認是否同一瀏覽器錯幾次 02/06 19:51
12F：→ yvb: 因此需要引入stateful機制如cookie/session/url-ext之類, 02/06 19:53
13F：→ yvb: 使用如多數用戶網站的登入, 搭配後台程式進行驗證及計次等... 02/06 19:58
14F：→ carpo5279: liang168,我是公司新人被叫去修產品BUG，裡面有用到boa 02/06 21:15
15F：→ carpo5279: yyb,我瀏覽器帳號密碼輸入正確後，之後再連就不需要輸 02/07 09:08
16F：→ carpo5279: 入帳號密碼，所以伺服器是不是已經有採用session..之 02/07 09:10
17F：→ carpo5279: 類的方法，謝謝。 02/07 09:11
18F：→ CP64: basic auth 瀏覽器會把他 cache 起來一段時間就是 02/07 10:05
19F：→ CP64: 至於 session 或是 cookie 之類的要看你的 cgi 有沒有做 02/07 10:06
20F：推 yvb: 原來是貴公司的產品用到. 所以是視瀏覽器對 HTTP 認證失敗的 02/07 20:02
21F：→ yvb: 後續行為不同為 bug? 不知您對 HTTP 這個協定中, 諸如 02/07 20:02
22F：→ yvb: HTTP status, HTTP header, HTTP auth, HTTP cookie 的了解 02/07 20:03
23F：→ yvb: 情況如何; 以及認證這部分, 在產品中的內部運作流程又是如何, 02/07 20:03
24F：→ yvb: 是直接改寫 boa 程式碼逹成, 或是使用 uClinux boa 的 auth 02/07 20:04
25F：→ yvb: 搭配設定檔, 還是叫用 cgi/scripting 來處理認證? 02/07 20:04
26F：→ carpo5279: 我用站內信跟你說明，這邊回應有點麻煩。 02/08 21:05
27F：→ yvb: 發文者應該可以用大寫 E 編輯文章啊... 02/08 21:16
※ 編輯: carpo5279 (36.231.52.106), 02/08/2017 22:29:52
28F：推 yvb: 編輯若非修改原內容, 而是追加, 回推文, 那寫在推文下較佳. 02/10 18:53
29F：→ yvb: 其實 HTTP auth 最大的問題(缺點)就是定義得太簡單,缺少諸如 02/10 18:56
30F：→ yvb: 檢查次數,要求登出等機制 (無法登出是否又會被當另一個bug?) 02/10 18:58
31F：→ yvb: 所以一切要靠browser自定行為. 不知貴公司是怎樣的產品, 02/10 19:02
32F：→ yvb: 登入成功的後續是靜態網頁?CGI?或是仍在boa中加怎樣的處理? 02/10 19:03
33F：→ yvb: 若是另外使用CGI或scripting languages (asp,php...), 02/10 19:05
34F：→ yvb: 那也許考慮把認證機制做成cookie/session型式會更好. 02/10 19:07
35F：→ yvb: 是否一定堅持要使用HTTP auth ? 02/10 19:08
36F：→ yvb: 雖然 HTTP auth 搭配 cookie 可能還是有 partial solution, 02/10 19:09
37F：→ yvb: 但使用上應該還蠻蹩腳的... 02/10 19:11
38F：→ yvb: 大致上是認證失敗就檢查是否有某cookie,沒有就設定初值, 02/10 19:13
39F：→ yvb: 有就檢查是第幾次的值,然後重設新值或設定清除; 02/10 19:15
40F：→ yvb: 若認證成功也要設定清除. 02/10 19:16
41F：→ carpo5279: 好，謝謝，我在研究一下。 02/11 19:44