关于basic 验证

response.setStatus(response.SC_UNAUTHORIZED);
response.setHeader("WWW-Authenticate","Basic realm=\"" + "人民服务" + "\"");

关于上面的代码是采用basic验证,我想知道 basic 验证是怎么样的一个通讯(客户端<-->服务器,我知道是要设置响应头)的呢(因为只要你的用户名和密码正确了,以后就不用再输入了(对于本资源),想知道客户端是如何保存这个用户码和密码的),如我想取消它(让它失效),应该怎么做呢.
还有我怎么知道客户端是点取消按扭的呢???

请大家多发表意见

最近看了Tomcat这方面的东西，希望和你一起探讨。
Tomcat中存在Valve的概念，每个Request要经过若干Valve处理得到最终的Response。其中有一个Authenticator的Valve，负责处理认证。如果web.xml中定义了<security-constraint>，则当每次请求该web.xml所在的Context内的资源时，Authenticator Valve就会对请求进行认证。第一次时可能会谈出一个认证框让用户输入用户名和密码，如果正确，就生成一个Principal保存在Session中；如果错误，就给出SC_UNAUTHORIZED状态错误。下次请求时，就检查Session中是否有该用户的Principal。
response.setHeader("WWW-Authenticate","Basic realm=\"" + "人民服务" + "\""); 主要是让浏览器弹出认证框。是否需要认证完全取决于你的web.xml的配置。
客户端是点确定还是取消按扭，似乎服务器不用关心。在弹出认证框之前，服务器已经设置了Status和Header，如你所写的。点取消，则表明终止请求，服务器直接SC_UNAUTHORIZED；点确定，表明再一次发送请求。
以上纯属个人看法，不当之处还请大家批评指正。

很多谢谢楼上的回答,也许它的验证方式是这个样子(tomcat,我没有试过),
其实这个验证我是写在Filter中的(也就是我明确写在代码中的,不要问为什么).
其实这也并不要紧,最重要的是让它如何失效.
不知道你是否知道:
一旦身份验证成功,大多数浏览器会继续把Authorization标题或中的身份验证信息随每个后续的请求发送给服务器(目的是不用每次请求都要进行身份验证).

也就是这个浏览器的问题吧(我分析是99%的可能),所以失效让我很难过(如果可能以清除浏览器那些信息我就不用头痛了).嘻嘻
请高手指教.

实现安全认证：
1.全部交由服务器处理，即在web.xml中进行相应的配置。这是符合J2EE规范的；
2.客户端自己控制。如你所说放在Filter中是个不错的方法，你完全可以自己控制是否每次进行认证，如代码可以这样写：
doFilter(...){
检查session中是否有该用户的认证信息
如果session中没有该用户的认证信息，就进行认证，
认证错误，就设置status为SC_UNAUTHORIZED，flush后返回
认证正确，就将认证信息放入session中
如果有该用户的认证信息，就不进行认证，直接FilterChain.doFilter(...)
}

另外，客户端每次request时，status和header都是新的，不要期望浏览器为你保存上次request时的status和header

嘻嘻,楼上和我刚开始想得一样(不知道是不是真的一样,因为没有代码).
不过也许楼上可能真是不知道:
一旦身份验证成功,大多数浏览器会继续把Authorization标题或中的身份验证信息随每个后续的请求发送给服务器(目的是不用每次请求都要进行身份验证).

我不敢肯定浏览器每次发送header是不是都是新的,但这并不重要,重要的是头部是不是有相同的信息.
如果是相同的信息又怎么样区分新或旧呢??

如果当session失效(或者说是注销吧)后再登录的话,你会如何判断它呢>

String auth=request.getHeader("Authentication");;

if(null==request.getSession(false););{
      
      if(null==auth || auth.length();==0);
           //发送验证
     //验证并保存到Session
}

是不是像上面的代码那样呢??如果是的话,它就有很大的问题罗.自己像一下吧.

认证是为了验证是否允许具有某种身份的人有没有足够的权限来访问其欲访问的
资料。我认为浏览器的这种处理方法具有普遍性，既然已经通过了认证，就应该让它具有可持续性，并且这种可持续性有一个界限，那就是只在当前session中有效！这种设计是很合情合理的。

我不是很清楚你现在要进行的认证主要是什么目的，以及在什么情况下认证。

楼上说得对，但是有时必须采取帐号失效操作（帐号注销），在这时这个就是麻烦，例如，你的系统是一个在公众的触屏式电脑中运行（好象是电脑城中一样的，有一些公用电脑，这时如果不能将帐号注销那就会有麻烦（别人会用到你的帐号使用该系统)。

对，当session有效时应该不用验证，但这个basic与session是没有关联的。
只有你自己强制式将它们邦定。

session的失效（注销）是很简单的，但是加上basic 就是麻烦的。
其实现在我唯一的办法，就是放弃basic验证。当然觉得这样很可悲，我想是有方法的，只是我没有想到，在当务之急，我暂时也只能这样。

其实我公司的同事同我说过，在注销时也把当前的窗口关掉就可以了。但是一个人很可能会在同一个窗口再新建N个窗口的（例如：文件--》新建--》窗口，shift 点击链接等）。这时浏览器是采用clone方法来进行的（即其它的新的窗口会与该窗口拥有相同的信息）.

这种验证方法更时候需要对整个站点的内容进行访问控制的情况，比较难跟业务系统的权限结合起来！

其实basic验证就是很简单的，与业务逻辑是没有什么关联的。
因为basic只是简单地弹出一个验证窗口，请求时就检查一下用户名和密码。
也就是说basic就是让你得到一个用户名和密码，究竟能不能访问这个资源还是由你决定的（业务）。

当然验证有很多种方法。只不过这个方法有这个毛病，希望大家也要注意一下（我想在http 1.1 协议中的都可能会有这个毛病）。
当然浏览器的初哀是正确的，因为我们在大多数的时候并不用我那样做。