目前有个问题
浏览器上输入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,没有就设定初值,有就检查是第几次的值,然后重设新值或设定清除;若认证成功也要设定清除.

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