web安全
一、打开认证：
<login-config>
<auth-method>认证类型</>
</>
如果使用FORM形式，
数据完整性非常弱，没有加密，允许有定制的登陆界面。
配置如下：
<web-app>
......
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
......
</web-app>
这里的 FORM 方式需要说明的是 登录页面的固定的元素:login.html
<form name="loginform" method="post" action="j_security_check">
<INPUT name="j_username" type="text">
<INPUT name="j_password" TYPE="password">
<input type="submit" value="登 录" >
</form>
form 的action 必须是j_security_check, method="post", 用户名 name="j_username" , 密码name="j_password" 这些都是固定的元素
以上来源
二、设置好认证方式后，在web.xml下配置资源约束：
<security-constraint>
<web-resource-collection> 可以有多个resource-collection，但只对应一个auth-constraint
<web-resource-name>xxxx</> 由工具使用，别的地方不会见到这个名字，但它是必要的
<url-pattern>/Beer/AddBeer/*</>
<http-method>GET</> 如果不写此项，则所有请求方式都可以访问，写了就只允许写的方式
</web-resource-collection>
<auth-constraint>
authorization授权约束
<description>可选的，用于增加可读性</>
<role-name></role-name> 指定的角色才可以访问上面的内容，不写则所有角色请求都会拒绝
</auth-constraint>
</security-constraint>
注意：
1. <security-constraint>本身可以有多个。
2.<role-name>*</role-name>|没有<auth-constraint> 所有角色认证后可访问
3.有<auth-constraint>没有<role-name>则所有角色都不可访问
多个<security>中，有相同url-pattern的合并规则：
1.如果存在空的<auth-constraint>，则所有用户不可访问
2.取多个<auth-constraint>中最大的范围：并集
Servlet规范对程序式安全的支持：
1.用户通过http的401认证
2.servlet中，在httpRequest上调用isUserInRole("XXX")；
3.此时容器会拿这个XXX去DD中(security-role下)寻找，是否存在一个role-name为XXX的安全角色
4.存在则返回true，否则false
5.DD中还可以指定<security-role-ref>(<role-name>&<role-link>)不必与tomcat-users.xml中完全一致
6.寻找时，先查ref，如果找到就返回，因此如果ref和security-role重名，则找到的是ref
三、要在自定义表单的基础上对传输的数据进行加密，需要使用https：
在security-constraint中进行声明，则容器自动实现数据加密。但是，并非所有的数据都有加密的必要，为了提升性能，我们需要进行如下操作：
①声明一个security-constraint，并指定这个安全约束的web-resource-collection。
②声明user-data-constraint，
默认是NONE，不进行数据保护；
使用INTEGRAL（完整的），会保证数据在传输过程中不能被修改(一般用shar1等实现，最后检查一致性)；
使用confidential（机密的），会对数据进行加密。
完整例子：
零、未认证用户请求受限资源的过程：
①客户发起请求，容器检查web.xml，发现这个资源是security-constraint中的，并且要求了数据保密性（transport-guarantee CONFIDENTIAL）。
②容器向客户发回301重定向响应，要求用户以https进行访问。
301(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。
③重定向完成，客户以https请求资源。此时容器发现用户还未认证，会弹出登陆界面。
④浏览器弹出登录界面，用户进行登陆，再次请求该资源。
⑤检查，如果有权访问则返回资源。