Tomcat 5.5 基本详细配置(4)

6 声明过滤器
servlet版本2.3引入了过滤器的概念。虽然所有支持servlet API版本2.3的服务器都支持过滤器，但为了使用与过滤器有关的元素，必须在web.xml中使用版本2.3的DTD。

过滤器可截取和修改进入一个servlet或JSP页面的请求或从一个servlet或JSP页面发出的相应。在执行一个servlet或JSP页面之前，必须执行第一个相关的过滤器的doFilter方法

。在该过滤器对其FilterChain对象调用doFilter时，执行链中的下一个过滤器。如果没有其他过滤器，servlet或JSP页面被执行。过滤器具有对到来的ServletRequest对象的全部

访问权，因此，它们可以查看客户机名、查找到来的cookie等。为了访问servlet或JSP页面的输出，过滤器可将响应对象包裹在一个替身对象（stand-in object）中，比方说把输

出累加到一个缓冲区。在调用FilterChain对象的doFilter方法之后，过滤器可检查缓冲区，如有必要，就对它进行修改，然后传送到客户机。

例如，程序清单5-11帝国难以了一个简单的过滤器，只要访问相关的servlet或JSP页面，它就截取请求并在标准输出上打印一个报告（开发过程中在桌面系统上运行时，大多数服

务器都可以使用这个过滤器）。

程序清单5-11 ReportFilter.java

package moreservlets;

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

import java.util.*;

public class ReportFilter implements Filter {

public void doFilter(ServletRequest request,

ServletResponse response,

FilterChain chain)

throws ServletException, IOException {

HttpServletRequest req = (HttpServletRequest)request;

System.out.println(req.getRemoteHost() +

" tried to access " +

req.getRequestURL() +

" on " + new Date() + ".");

chain.doFilter(request,response);

}

public void init(FilterConfig config)

throws ServletException {

}

public void destroy() {}

}

一旦建立了一个过滤器，可以在web.xml中利用filter元素以及filter-name（任意名称）、file-class（完全限定的类名）和（可选的）init-params子元素声明它。请注意，元素

在web.xml的web-app元素中出现的次序不是任意的；允许服务器（但不是必需的）强制所需的次序，并且实际中有些服务器也是这样做的。但这里要注意，所有filter元素必须出

现在任意filter-mapping元素之前， filter-mapping元素又必须出现在所有servlet或servlet-mapping元素之前。

例如，给定上述的ReportFilter类，可在web.xml中作出下面的filter声明。它把名称Reporter与实际的类ReportFilter（位于moreservlets程序包中）相关联。

<filter>

<filter-name>Reporter</filter-name>

<filter-class>moresevlets.ReportFilter</filter-class>

</filter>

一旦命名了一个过滤器，可利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。关于此项工作有两种选择。

首先，可使用filter-name和servlet-name子元素把此过滤器与一个特定的servlet名（此servlet名必须稍后在相同的 web.xml文件中使用servlet元素声明）关联。例如，下面的

程序片断指示系统只要利用一个定制的URL访问名为SomeServletName 的servlet或JSP页面，就运行名为Reporter的过滤器。

<filter-mapping>

<filter-name>Reporter</filter-name>

<servlet-name>SomeServletName</servlet-name>

</filter-mapping>

其次，可利用filter-name和url-pattern子元素将过滤器与一组servlet、JSP页面或静态内容相关联。例如，相面的程序片段指示系统只要访问Web应用中的任意URL，就运行名为

Reporter的过滤器。

<filter-mapping>

<filter-name>Reporter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

例如，程序清单5-12给出了将ReportFilter过滤器与名为PageName的servlet相关联的web.xml文件的一部分。名字 PageName依次又与一个名为TestPage.jsp的JSP页面以及以模式

http: //host/webAppPrefix/UrlTest2/ 开头的URL相关联。TestPage.jsp的源代码已经JSP页面命名的谈论在前面的3节”分配名称和定制的URL”中给出。事实上，程序清单5- 12

中的servlet和servlet-name项从该节原封不动地拿过来的。给定这些web.xml项，可看到下面的标准输出形式的调试报告（换行是为了容易阅读）。

audit.irs.gov tried to access

mycompany.com/deployDemo/UrlTest2/business/tax-plan.html

on Tue Dec 25 13:12:29 EDT 2001.

程序清单5-12 Web.xml（说明filter用法的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<filter>

<filter-name>Reporter</filter-name>

<filter-class>moresevlets.ReportFilter</filter-class>

</filter>

<!-- ... -->

<filter-mapping>

<filter-name>Reporter</filter-name>

<servlet-name>PageName</servlet-name>

</filter-mapping>

<!-- ... -->

<servlet>

<servlet-name>PageName</servlet-name>

<jsp-file>/RealPage.jsp</jsp-file>

</servlet>

<!-- ... -->

<servlet-mapping>

<servlet-name> PageName </servlet-name>

<url-pattern>/UrlTest2/*</url-pattern>

</servlet-mapping>

<!-- ... -->

</web-app>

7 指定欢迎页
假如用户提供了一个像http: //host/webAppPrefix/directoryName/ 这样的包含一个目录名但没有包含文件名的URL，会发生什么事情呢？用户能得到一个目录表？一个错误？还

是标准文件的内容？如果得到标准文件内容，是 index.html、index.jsp、default.html、default.htm或别的什么东西呢？

Welcome-file-list 元素及其辅助的welcome-file元素解决了这个模糊的问题。例如，下面的web.xml项指出，如果一个URL给出一个目录名但未给出文件名，服务器应该首先试用

index.jsp，然后再试用index.html。如果两者都没有找到，则结果有赖于所用的服务器（如一个目录列表）。

<welcome-file-list>

<welcome-file>index.jsp</welcome-file>

<welcome-file>index.html</welcome-file>

</welcome-file-list>

虽然许多服务器缺省遵循这种行为，但不一定必须这样。因此，明确地使用welcom-file-list保证可移植性是一种良好的习惯

8 指定处理错误的页面
现在我了解到，你在开发servlet和JSP页面时从不会犯错误，而且你的所有页面是那样的清晰，一般的程序员都不会被它们的搞糊涂。但是，是人总会犯错误的，用户可能会提供

不合规定的参数，使用不正确的URL或者不能提供必需的表单字段值。除此之外，其它开发人员可能不那么细心，他们应该有些工具来克服自己的不足。

error-page元素就是用来克服这些问题的。它有两个可能的子元素，分别是：error-code和exception- type。第一个子元素error-code指出在给定的HTTP错误代码出现时使用的

URL。第二个子元素excpetion-type指出在出现某个给定的Java异常但未捕捉到时使用的URL。error-code和exception-type都利用location元素指出相应的URL。此 URL必须以/开

始。location所指出的位置处的页面可通过查找HttpServletRequest对象的两个专门的属性来访问关于错误的信息，这两个属性分别是：javax.servlet.error.status_code和

javax.servlet.error.message。

可回忆一下，在web.xml内以正确的次序声明web-app的子元素很重要。这里只要记住，error-page出现在web.xml文件的末尾附近，servlet、servlet-name和welcome-file-list之

后即可。

我知道在web.xml中有两种配置error-page的方法，一是通过错误码来配置，而是通过异常的类型来配置，分别举例如下：

通过错误码来配置error-page

Eg.

<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>

上面配置了当系统发生500错误（即服务器内部错误）时，跳转到错误处理页面error.jsp。

通过异常的类型配置error-page

Eg.

<error-page>
<exception-type>java.lang.NullException</exception-type>
<location>/error.jsp</location>
</error-page>

上面配置了当系统发生java.lang.NullException（即空指针异常）时，跳转到错误处理页面error.jsp
9 error-code元素
为了更好地了解error-code元素的值，可考虑一下如果不正确地输入文件名，大多数站点会作出什么反映。这样做一般会出现一个404错误信息，它表示不能找到该文件，但几乎没

提供更多有用的信息。另一方面，可以试一下在www.microsoft.com、www.ibm.com 处或者特别是在www.bea.com 处输出未知的文件名。这是会得出有用的消息，这些消息提供可选

择的位置，以便查找感兴趣的页面。提供这样有用的错误页面对于Web应用来说是很有价值得。事实上rm-error-page子元素）。由form-login-page给出的HTML表单必须具有一个j_security_check的 ACTION属性、一个名为j_username的用户名文本字段以及一个名为j_password的口令字段。

例如，程序清单5-19指示服务器使用基于表单的验证。Web应用的顶层目录中的一个名为login.jsp的页面将收集用户名和口令，并且失败的登陆将由相同目录中名为login-

error.jsp的页面报告。

程序清单5-19 web.xml（说明login-config的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<!-- ... -->

<security-constraint> ... </security-constraint>

<login-config>

<auth-method> FORM </auth-method>

<form-login-config>

<form-login-page>/login.jsp</form-login-page>

<form-error-page>/login-error.jsp</form-error-page>

</form-login-config>

</login-config>

<!-- ... -->

</web-app>

9.1 限制对Web资源的访问
现在，可以指示服务器使用何种验证方法了。”了不起，”你说道，”除非我能指定一个来收到保护的 URL，否则没有多大用处。”没错。指出这些URL并说明他们应该得到何种保

护正是security-constriaint元素的用途。此元素在 web.xml中应该出现在login-config的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、 auth-

constraint、user-data-constraint和display-name。下面各小节对它们进行介绍。

ü web-resource-collection

此元素确定应该保护的资源。所有security-constraint元素都必须包含至少一个web-resource-collection项。此元素由一个给出任意标识名称的web-resource-name元素、一个确

定应该保护的URL的url-pattern元素、一个指出此保护所适用的 HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料的可选description元素组成。例

如，下面的 Web-resource-collection项（在security-constratint元素内）指出Web应用的proprietary目录中所有文档应该受到保护。

<security-constraint>

<web-resource-coolection>

<web-resource-name>Proprietary</web-resource-name>

<url-pattern>/propritary/*</url-pattern>

</web-resource-coolection>

<!-- ... -->

</security-constraint>

重要的是应该注意到，url-pattern仅适用于直接访问这些资源的客户机。特别是，它不适合于通过MVC体系结构利用 RequestDispatcher来访问的页面，或者不适合于利用类似

jsp:forward的手段来访问的页面。这种不匀称如果利用得当的话很有好处。例如，servlet可利用MVC体系结构查找数据，把它放到bean中，发送请求到从bean中提取数据的JSP页

面并显示它。我们希望保证决不直接访问受保护的JSP页面，而只是通过建立该页面将使用的bean的servlet来访问它。url-pattern和auth-contraint元素可通过声明不允许任何用

户直接访问JSP页面来提供这种保证。但是，这种不匀称的行为可能让开发人员放松警惕，使他们偶然对应受保护的资源提供不受限制的访问。

ü auth-constraint

尽管web-resource-collention元素质出了哪些URL应该受到保护，但是auth-constraint元素却指出哪些用户应该具有受保护资源的访问权。此元素应该包含一个或多个标识具有访

问权限的用户类别role- name元素，以及包含（可选）一个描述角色的description元素。例如，下面web.xml中的security-constraint元素部门规定只有指定为Administrator或

Big Kahuna（或两者）的用户具有指定资源的访问权。

<security-constraint>

<web-resource-coolection> ... </web-resource-coolection>

<auth-constraint>

<role-name>administrator</role-name>

<role-name>kahuna</role-name>

</auth-constraint>

</security-constraint>

重要的是认识到，到此为止，这个过程的可移植部分结束了。服务器怎样确定哪些用户处于任何角色以及它怎样存放用户的口令，完全有赖于具体的系统。

例如，Tomcat使用install_dir/conf/tomcat-users.xml将用户名与角色名和口令相关联，正如下面例子中所示，它指出用户joe（口令bigshot）和jane（口令enaj）属于

administrator和kahuna角色。

<tomcat-users>

<user name="joe" password="bigshot" roles="administrator,kahuna" />

<user name="jane" password="enaj" roles="kahuna" />

</tomcat-users>

ü user-data-constraint

这个可选的元素指出在访问相关资源时使用任何传输层保护。它必须包含一个transport-guarantee子元素（合法值为NONE、 INTEGRAL或CONFIDENTIAL），并且可选地包含一个

description元素。transport-guarantee为NONE值将对所用的通讯协议不加限制。INTEGRAL值表示数据必须以一种防止截取它的人阅读它的方式传送。虽然原理上（并且在未来的

HTTP版本中），在 INTEGRAL和CONFIDENTIAL之间可能会有差别，但在当前实践中，他们都只是简单地要求用SSL。例如，下面指示服务器只允许对相关资源做 HTTPS连接：

<security-constraint>

<!-- ... -->

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

ü display-name

security-constraint的这个很少使用的子元素给予可能由GUI工具使用的安全约束项一个名称。