JAVA流通桥

Servlet2.3中文文档(第11,12,13章)

                                                  第十一章 请求到servlet的映射
11.1 URI的使用
web容器根据客户端的请求决定要调用的资源。
URL路径映射规则是第一个匹配成功就不再匹配了。
1）引擎将尽力为每一个请求一个servlet的路径匹配一个servlet
2）引擎将递归的匹配最长的路径前缀（在一个目录树中）
3）如果在URL路径中的最后一节有扩展名（例如：.jsp），则servlet引擎将会匹配一个适当的servlet获
取请求对象
4）如果没有一个servlet能够匹配请求，引擎将用一个适当的资源来处理该请求。如：在应用中配置了
默认的servlet，就会被用来处理匹配不到资源的请求。
11.2 匹配规则
在web应用描述文件中，匹配的定义如下：
.以'/'开始，以'/*'为结尾的字符串,用作路径匹配
.以'*.'开始的字符串，用作扩展名匹配
.包含'/'字符串，定义一个默认的servlet。如匹配的servlet路径是请求URI路径的最小上下文路径，路经
的info为空。
.其它的字符串用作精确的匹配。
11.2.1 绝对匹配
servlet引擎能够匹配任何精确的资源，如后缀为*.jsp的匹配，引擎中有JSP引擎的话，就会把所有的JSP
页面和与之对象的资源相匹配。
11.2.2 匹配的例子：
path pattern servlet
/foo/bar/* servlet1
/baz/* servlet2
/catalog servlet3
*.bop servlet4
incoming path servlet handling request
/foo/bar/index.html servlet1
/foo/bar/index.bop servlet1
/baz servlet2
/baz/index.html servlet2
/catalog servlet3
/catalog/racecar.bop servlet4
/index.bop servlet4
第十二章 安全
12.1介绍
web应用的资源能够被很多的用户访问，这些资源经常没有保护的暴露在网络中，因此一个稳定的web
应用需要一个安全的环境。
提高安全性有以下的几个方面：
.认证：访问一个实例前需要一个特殊的ID进行授权认证后才能访问该实例
.资源的访问控制：一些机密资源或局部资源只限制给某些用户或程序使用。
.数据完整性：在传输过程中数据不能被意外的改变。
.机密性：确定信息只能被授权过的用户使用。
12.2 公共安全
安全性声明是指表明应用是有安全结构的；包括权限、访问控制、认证。在web应用中部署描述是安全
声明的主要工具。
开发者应该为应用运行时配一个逻辑安全策略，在运行时中，servlet引擎用这个安全策略去验证授权请
求。
安全模块应该适用web应用的静态内容，当servlet用RequestDispatcher调用一个静态资源或servlet用
forward或include,时安全模块不适用。
12.3 程序级安全
当应用的安全模块不能充分的表明安全时程序安全就可以被使用。
程序安全有以下部分组成：
HttpServletRequest接口：
.getRemoteUser
.isUserInRole
.getUserPrincipal
getRemoteUser方法返回客户端用户的名称，用于授权。
isUserInRole方法判断远程用户是否在一个安全的角色内。
getUserPrincipal方法返回一个java.security.Principal对象，表明当前用户的主要名称。这个API允许
servlet根据这个信息处理一些业务逻辑。
如果用户没有授权，getRemoteUser返回null，isUserInRole返回false，getUserPrincipal返回null。
isUserInRole以一个role-name为参数。一个security-role-ref元素为在部署描述文件中定义，role-name
子元素包含角色名称。Security-role包含一个子元素role-link,role-link的value值是客户端用户将匹配的
安全角色。当用isUserInRole时引擎将调用security-role-ref到security-role的匹配。
举个例子：
<security-role-ref>
<role-name>FOO</role-name>
<role-link>manager</role-link>
</security-role-ref>
当一个用户属于“manager”角色是调用isUsesrInRole("FOO")返回true
如果匹配一个security-role元素的security-role-ref没有被定义，引擎必须找出一个与security-role
列表不同的roel-name元素作为web应用默认的安全角色。但默认的安全角色限制了变换角色名
称不需要重新编译的机动性。
12.4 角色
一个安全角色是一组用户的逻辑名称。当应用发布时，角色就部署在web应用的运行时环境中
了。在基于安全属性的请求到来时，servlet引擎就会执行公共安全或程序级安全。安全请求在以
下的一些情况中会产生：
1）开发者给用户群配置了一个安全角色。
2）开发者把一个安全角色配置给一个安全域中的一个主要名称。
12.5 验证
web客户端可以用以下的一些机制验证用户：
.HTTP Basic Authentication
.HTTP Digest Authentication
.HTTPS Client Authentication
.Form Based Authentication
12.5.1 HTTP Basic Authentication
HTTP Basic Authentication是基于用户名和密码的验证机制，是在HTTP/1.0规范中定义的。web
服务要求客户端验证用户，web服务用一个realm字符串作为请求的一部分，用户通过这个realm
字符串被验证。realm字符串不会和任何安全域相关联。客户端获得用户名称和密码发送到服务
端。然后服务端用一个特殊的realm去验证该用户。
Basic Authentication 不是安全的验证协议。用户的密码是用base64编码的，服务端是不能够识
别的。一些附加的安全措施可以被使用，这些协议有：HTTPS安全传输协议或网络安全标准（如
IPSEC协议、VPN策略）。
12.5.2 HTTP Digest Authentication
和HTTP Basic Authentication一样，HTTP Digest Authentication 也是验证用户名和密码的。然而
这种验证是把密码加密传输的，要比Basic Authentication的base64编码要安全的多。Digest
Authentication 没有被广泛的运用，建议servlet引擎支持这种验证，但不是必须的。
12.5.3 Form Based Authentication
web应用部署描述文件包含登陆表单和错误页面。登陆表单必须包含用户名和用户密码字段，这
两个字段必须以j_username和j_password命名。当一个用户要访问一个被保护的资源时，引擎就
会验证该用户信息，如果该用户验证通过就会调用保护的资源，如果没有验证通过，以下的步骤
就会发生：
1）登陆表单被送到客户端，启动这个验证的URL路径将被引擎保存。
2）用户被要求填写用户名和密码
3）客户端重新post表单到服务端
4）引擎尝试着重新去验证该用户的信息
5）如果验证有失败，响应被设置为401的错误页面将被返回
6）如果验证成功，如果该访问的资源在一个授权角色中，将进一步验证。
7）如果用户是授权用户，客户端将用保存的URL路径重新定向到访问的资源。
发送到验证失败的用户的错误页面包含了失败的信息。
Form Based Authentication 和 Basic Authentication 有一样的弊端，密码是用简单的文本传输
的，不能够被服务端验证。附加的一些协议可以增强这部分功能。如HTTPS传输协议，或网路安
全标准（如IPSEC协议或VPN策略）。
12.5.3.1 登陆表单的一些注意事项
登陆的表单和跟踪session的URL实现上是有限制的。
登陆表单只能在cookies或SSL跟踪session的方式下才能使用。
登陆表单要进行验证的话，表单的action就必须为j_security_check。这个约束使得登陆表单访问
的资源没有问题，也避免了把表单外的字段提交进请求中。
在HTML页面中登陆表单的一个例子如下：
<form method="POST" action="j_security_check" >
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>
当登陆表单因为HTTP请求被调用时，原始的请求参数必须被引擎存储，在验证成功后重新定向
请求的资源。
如果用登陆表单的用户被验证通过，创建了一个session,当session超时或调用了失效方法，使得
登陆者推出了。后续来的请求就必须重新对用户进行验证。
12.5.4 HTTPS Client Authentication
用HTTPS验证用户是很强的验证机制。这个验证需要用户拥有一个公共钥匙（PKC）。servlet引
擎不需要支持HTTPS协议。
12.6 验证信息的跟踪
基本的身份验证实在运行时环境中进行的：
1）确认一个登陆验证机制或策略已经配置在web应用中。
2）把需验证的信息发往一个容器中的所有应用。
3）当一个安全域被删除时，用户的请求就需要重新验证。

posted on 2007-08-20 17:52 朱岩 阅读(357) 评论(0)  编辑  收藏 所属分类: servlet文章