开发人员使用监听器类跟踪应用会话.它的作用很大,想知道哪个会话因容器使会话超时,或是因为被调用了invalidate方法而失效了。区别在于是直接使用HTTPSession的API还是间接使用监听器。 第十一章 映射请求到Servlet
收到客户机的请求，web容器首先判断由哪个web应用处理它。被选定的应用拥有最长的匹配该请求URL的context路径，和URL的匹配部分就是context path.
web容器接下来必须使用路径映射过程定位处理请求的servlet： 用来映射到servlet的路径是请求的URL减去context path,下列的URL映射规则其顺序是有用的，一个成功的匹配后就不需要进行下一步的匹配了:
1.容器尝试找到请求路径到servlet路径的精确匹配，成功就选定该servlet。
2.容器将回退尝试匹配最长的路径前缀：使用\字符作为路径符，每次沿着路径向下一步查找目录。按最长的那个匹配选择servlet. 3.如果URL最后的那段包含扩展名（即.jsp），servlet容器将试图匹配一个处理该扩展名的servlet。扩展名是最后一个\后面的这部分。
4.如果上述都没有找到匹配的servlet，容器尝试serve content appropriate for the resource requested.如“default\et定义了，就使用default servlet。
11.2 映射规范
以下语法用于在应用配置描述中定义映射: .以'/'开头,'/*'结尾的后缀被用来路径映射 .以'*.'开始的前缀被用来映射扩展名
.只包含'/'的字符串表示应用的缺省servlet,此时,servlet path是请求的URI减去context path,path info 为null.
.所有其他字符串只是被用来做精确匹配.
11.2.1 隐含的映射
若容器拥有内部的JSP容器,所有\扩展被映射到它,允许执行JSP页面。这就是隐含映射。如Web 应用定义了*.jsp映射,将优先于隐含映射。 只要显式映射优先，servlet容器也可以做其他隐含映射。例如：*.shtml可以映射用来包含。
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/index.html “default” servlet /catalog/racecar.bop servlet4 /index.bop servlet4
第十二章 安全
开发人员创建出web应用以后，将其赠与、销售或者传送到发布者，并安装到运行环境中。开发人员需要和发布者沟通如何给安装的应用程序 设置安全。利用配置描述机制完成此项工作。
本章描述了安全需求的发布表示。和web应用目录结构与配置描述类似，本章并不描述运行表现需求。推荐容器实现本章作为它们的运行表示。
12.1 介绍
web应用包含的资源可以被很多用户访问。在开放网络特别是internet，这些资源通常可以被无保护的访问。在这样的环境下，大量的web应用都有安全需求。
虽然质量管理和实施细节可能不同, servlet容器的机制和基础设施可以达到分享一些以下要求:
.认证(Authentication:)：通信的个体互相证明他们就代表着被批准为访问的那个指定的身分。
.资源访问控制:出于增强完整性、机密性、有效性的约束，与资源的交互被限制在某些用户或程序的集合内。
.数据完整性：证明数据在传输过程中未被第三方篡改。 .机密性和数据保密：信息只对被批准访问它的用户可用。
12.2 声明安全
声明安全涉及表示应用安全结构的方式，包括角色，访问控制，外部对应用认证需求形式。配置描述是声明web应用安全的主要工具。 发布者映射应用的逻辑安全需求到针对运行环境特定的安全策略。运行时，servlet容器使用安全策略增强认证和授权。
安全模型适用于web应用的静态内容部分和servlet。当servlet使用RequestDispatcher对象调用静态资源或servlet使用forward或include，安全模型是不应用的。 12.3 安全编程
当只使用声明性的安全措施不能满足应用安全模型的需要时，可进行安全方面的编程。由下列HttpServletRequest接口的方法组成： .getRemoteUser .isUserInRole
.getUserPrincipal
getRemoteUser方法返回客户机用来认证的用户名称。isUserInRole方法判断是否远程用户隶属于某个安全角色。getUserPrincipal方法
判断当前用户的Principal，并返回一个java.security.Principal对象。这些方法允许servlet根据获得的信息作出商业逻辑层的判断。
如果用户没有通过认证，getRemoteUser方法返回NULL.isUserInRole则总是返回false，getUserPrincipal方法返回null。 isUserInRole方法有一个字符串类型的参数代表用户角色名称，配置描述中应声明security-role-ref元素，同时声明role-name子元素，此元素的内容将被传递进该方法。
security-role元素应包含一个role-link子元素，其值就是此用户被映射的安全角色名称。决定调用的返回值时，容器使用security-role-ref到security-role的映射。
例如：映射安全引用\到角色名为\的安全角色的语法如下：
此例中，如属于“manager”角色的用户调用了此servlet，isUserInRole(\方法将返回true。
如果security-role-ref匹配security-role元素未被声明，容器必须默认逆着security-role元素列表检查role-name元素参数。
isUserInRole方法则相关于调用者是否映射到了安全角色。开发人员必须知道使用默认机制也许限制了其灵活性，在改变角色名称而不必要重新编译发起调用的servlet。 12.4 角色
安全角色是由应用开发人员或集成者定义的逻辑用户组。当发布应用时，角色釉发布者映射到运行环境的principal或组。 Servlet容器根据principal的安全属性，为与请求相关的principal执行声明的或编程的安全。
1.发布者已经映射了一个安全角色到操作系统内的一个用户组。正在调用的用户组隶属于哪个principal，可在其安全属性中检索到。
当principal的用户组匹配映射了安全角色的用户组时，principal隶属于安全角色。
2.发布者在安全策略域中已经为principal名称映射了安全角色。在这种情况下,可从其安全属性中检索到正在调用的principal的名称.
只有当principal的名字和安全角色映射的principal名字一样时，principal隶属于安全角色。
12.5 认证
web 客户机使用下列机制向服务器认证用户：
.HTTP基本认证 .HTTP摘要认证 .HTTPS客户端认证 .基于Form认证
12.5.1 HTTP基本认证
HTTP基本认证，基于用户名和密码，是HTTP/1.1规范定义的认证机制。Web服务器要求web客户端认证用户。作为请求的一部分，web服务器传递\领域\字符串)，包含被认证的用户信息。用于基本认证的领域字符串并不附加任何特殊安全策措施。Web客户机将用户名和用户密码传给服务器。然后,web服务器在指定的领域内认证用户。
基本认证并非安全的认证协议，用户密码以简单的base64编码发送。并且目标服务器也不需要被认证。额外的保护可以减轻一些安全忧虑：比如安全传输机制(HTTPS) ,或者网络层安全(IPSEC协议或VPN策略)都是经常被使用的。
12.5.2 HTTP摘要认证
象HTTP基本认证一样，HTTP摘要认证也用用户名和密码的形式给用户授权。但认证的密码被加密，当然比HTTP基本认证使用的base64编码安全得多。HTTPS客户端认证，象摘要认证一样，目前不被广泛使用，servlet容器支持它不是必须的，但值得鼓励。
12.5.3 基于Form的认证
使用“登陆屏幕”这种内建在web浏览器内的认证机制看上去感觉缺乏变化。本规范介绍介绍基于form认证机制，它允许开发人员控制登陆屏幕的外观。
web应用配置描述包含登陆form和错误页面的入口，登陆form必须包含用户名和密码的输入域。这些输入域必须分别命名为j_username和j_password。
当用户试图当问受保护的web资源，容器检验用户的认证。如果用户通过认证，拥有权限访问该资源,该资源被激活，返回它的引用。如果用户未通过认证，则：
1.与安全约束关联的登陆form被发送到客户端，而引发认证的URL被容器存储。
2.用户填写form。
3.客户机将form发送回服务器。
4.容器试图使用form里的信息认证用户 5.若认证失败，适用formward或redirect导航到错误页面，将response的状态码设定为401。
6.如果认证成功，被认证的用户的principal被检查看是否它在一个已授权的角色中.
7.如果认证成功，客户机被重新导航到到前面所存储的URL路径。
发送给未通过认证的用户的错误页包含关于失败的信息。
基于form认证和基本认证一样缺乏安全，因为用户密码是明码传输，而且目的服务器也未经认证。通过附加的保护可以减轻这些安全忧虑：例如安全传输机制(HTTPS)，网络层安全(IPSEC或VPN)。
12.5.3.1 登陆form
基于form登陆和基于URL的会话跟踪一起使用是有问题的，实现基于form登陆应当只在通过cookie方式的会话或SSL会话时使用。
为了使认证能过程正确执行，登陆form的action必须是j_security_check，此约束是为了使登陆form 面对所请求的任何资源都可以工作得很好，并避免要求服务器指定action域。
如果该登陆form由一个带参数的HTTP请求引起，容器必须保存原始的请求参数，当认证成功后，再将其转发到被请求的资源。
如果被认证的用户使用登陆form，并且已创建了HTTP 会话,该会话的超时或失效导致该用户登出,其接下来的请求会引起用户再次认证.
登出的范围和认证是一样的. 例如:如果容器支持single-signon,J2EE技术兼容的web容器,用户只需要认证web容器中的所有应用任何一个就可以了.
12.5.4 HTTPS客户端认证
使用HTTPS的终端用户认证是强认证机制.此机制要求用户拥有公共密钥证书(PKC),PKC对于电子商务应用是很有用的,不兼容J2EE技术的servlet容器不需要支持HTTPS协议.
12.6 服务器跟踪认证信息
下列安全身份在运行环境中映射的角色由运行环境指定而非应用程序所指定的.
1.使登陆机制和策略成为要发布web应用的环境的属性. 2.对于同一容器内的所有应用可以使用相同的认证信息. 3.只有安全策略域的边界交叉的时候,才需要用户重新认证.
因此,servlet容器需要在容器层次(非web应用层)跟踪认证信息,允许在一个web应用中认证后的用户可以访问容器用同样安全身份管理的其他资源.
12.7 EJB调用里的安全身份传播
调用企业bean必须提供安全身份或principal.从web应用中调用企业bean的默认模式是将web用户的安全身份传播到EJB容器.
在另一些场景中,web容器需要允许对于它或者EJB容器来说不认识的用户调用:
1.web容器需要支持还没有认证的客户机访问web资源.
2.应用代码也许是基于访问者身份的数据和signon的唯一处理者.
在这些情况下,web应用配置描述,可以指定一个run-as元素,容器必须根据定义在run-as元素内的安全角色的名字,将调用者的安全身份传播到EJB层.
该安全角色的名字必须是web应用定义的安全角色中的一个.
因为web容器作为J2EE平台的一部份运行,调用在相同或不同J2EE应用中的EJB组件,run-as元素都必须被支持.
12.8 指定安全约束
安全约束是给与网络内容以预期保护的一种声明性方式。包含以下元素：
.web资源集合 .授权约束
.用户数据约束
web资源集合是一系列的URL范式和描述需要保护的一系列资源的HTTP方法。所有路径匹配URL范式的请求遵循此约束。
容器匹配预定义与安全约束内的URL范式的短发与11.1是一致的。
授权限制是一套安全角色,访问网资源集合描述的资源的用户必须属于其中之一。如果用户不是被允许角色的一部分,用户被拒绝访问该资源. 如果授权约束为定义角色,那么没有用户可以访问web应用中被此安全约束定义的这一部分.
用户数据描述了对客户机服务器传输层的需求.此需求的目的是内容一致性(防止通信过程中的破坏)或是机密性(防止传输中被窃听).容器必须至少使用SSL响应标志为 integral或confidential.的请求.如果原始请求的协议是HTTP,容器必须重新导向客户机到HTTPS端口.
12.9 默认策略
默认情况下,访问资源无需认证,只有在配置描述中指定了的才需要认证. （完）