9.2 分配角色名
迄今为止,讨论已经集中到完全由容器(服务器)处理的安全问题之上了。但servlet以及JSP页面也能够处理它们自己的安全问题。
例如,容器可能允许用户从bigwig或bigcheese角色访问一个显示主管人员额外紧贴的页面,但只允许bigwig用户修改此页面的参数。完成这种更细致的控制的一种常见方法是调用
HttpServletRequset的isUserInRole方法,并据此修改访问。
Servlet的 security-role-ref子元素提供出现在服务器专用口令文件中的安全角色名的一个别名。例如,假如编写了一个调用 request.isUserInRole(”boss”)的servlet,但
后来该servlet被用在了一个其口令文件调用角色manager而不是boss的服务器中。下面的程序段使该servlet能够使用这两个名称中的任何一个。
<servlet>
<!-- ... -->
<security-role-ref>
<role-name>boss</role-name> <!-- New alias -->
<role-link>manager</role-link> <!-- Real name -->
</security-role-ref>
</servlet>
也可以在web-app内利用security-role元素提供将出现在role-name元素中的所有安全角色的一个全局列表。分别地生命角色使高级IDE容易处理安全信息。
10控制会话超时
如果某个会话在一定的时间内未被访问,服务器可把它扔掉以节约内存。可利用HttpSession的setMaxInactiveInterval方法直接设置个别会话对象的超时值。如果不采用这种方法
,则缺省的超时值由具体的服务器决定。但可利用session-config和session- timeout元素来给出一个适用于所有服务器的明确的超时值。超时值的单位为分钟,因此,下面的例
子设置缺省会话超时值为三个小时(180分钟)。
<session-config>
<session-timeout>180</session-timeout>
</session-config>
11Web应用的文档化
越来越多的开发环境开始提供servlet和JSP的直接支持。例子有Borland Jbuilder Enterprise Edition、Macromedia UltraDev、Allaire JRun Studio(写此文时,已被
Macromedia收购)以及IBM VisuaAge for Java等。
大量的web.xml元素不仅是为服务器设计的,而且还是为可视开发环境设计的。它们包括icon、display-name和discription等。
可回忆一下,在web.xml内以适当地次序声明web-app子元素很重要。不过,这里只要记住icon、display-name和description是web.xml的web-app元素内的前三个合法元素即可。
ü icon
icon元素指出GUI工具可用来代表Web应用的一个和两个图像文件。可利用small-icon元素指定一幅16 x 16的GIF或JPEG图像,用large-icon元素指定一幅32 x 32的图像。下面举一
个例子:
<icon>
<small-icon>/images/small-book.gif</small-icon>
<large-icon>/images/tome.jpg</large-icon>
</icon>
ü display-name
display-name元素提供GUI工具可能会用来标记此Web应用的一个名称。下面是个例子。
<display-name>Rare Books</display-name>
ü description
description元素提供解释性文本,如下所示:
<description>
This Web application represents the store developed for
rare-books.com, an online bookstore specializing in rare
and limited-edition books.
</description>
12关联文件与MIME类型
服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如,将会自动给予名为mom.jpg的文件一个image/jpeg的MIME 类型。但是,假如你的Web应用具有几
个不寻常的文件,你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素(具有 extension和mime-type子元素)可提供这种保证。例如,下面的代码指示服务
器将application/x-fubar的MIME类型分配给所有以.foo结尾的文件。
<mime-mapping>
<extension>foo</extension>
<mime-type>application/x-fubar</mime-type>
</mime-mapping>
或许,你的Web应用希望重载(override)标准的映射。例如,下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本(text/plain)而不是作为PostScript
(application/postscript)。
<mime-mapping>
<extension>ps</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>
13定位TLD
JSP taglib元素具有一个必要的uri属性,它给出一个TLD(Tag Library Descriptor)文件相对于Web应用的根的位置。TLD文件的实际名称在发布新的标签库版本时可能会改变,
但我们希望避免更改所有现有JSP页面。此外,可能还希望使用保持taglib元素的简练性的一个简短的uri。这就是部署描述符文件的taglib元素派用场的所在了。Taglib包含两个
子元素:taglib-uri和taglib-location。taglib-uri元素应该与用于JSP taglib元素的uri属性的东西相匹配。Taglib-location元素给出TLD文件的实际位置。例如,假如你将文
件chart-tags- 1.3beta.tld放在WebApp/WEB-INF/tlds中。现在,假如web.xml在web-app元素内包含下列内容。
<taglib>
<taglib-uri>/charts.tld</taglib-uri>
<taglib-location>
/WEB-INF/tlds/chart-tags-1.3beta.tld
</taglib-location>
</taglib>
给出这个说明后,JSP页面可通过下面的简化形式使用标签库。
<%@ taglib uri="/charts.tld" prefix="somePrefix" %>
14指定应用事件监听程序
应用事件监听器程序是建立或修改servlet环境或会话对象时通知的类。它们是servlet规范的版本2.3中的新内容。这里只简单地说明用来向Web应用注册一个监听程序的web.xml的
用法。
注册一个监听程序涉及在web.xml的web-app元素内放置一个listener元素。在listener元素内,listener-class元素列出监听程序的完整的限定类名,如下所示:
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
虽然listener元素的结构很简单,但请不要忘记,必须正确地给出web-app元素内的子元素的次序。listener元素位于所有的servlet 元素之前以及所有filter-mapping元素之后。
此外,因为应用生存期监听程序是serlvet规范的2.3版本中的新内容,所以必须使用 web.xml DTD的2.3版本,而不是2.2版本。
例如,程序清单5-20给出一个名为ContextReporter的简单的监听程序,只要Web应用的Servlet-Context建立(如装载Web应用)或消除(如服务器关闭)时,它就在标准输出上显
示一条消息。程序清单5-21给出此监听程序注册所需要的web.xml文件的一部分。
程序清单5-20 ContextReporterjava
package moreservlets;
import javax.servlet.*;
import java.util.*;
public class ContextReporter implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
System.out.println("Context created on " +
new Date() + ".");
}
public void contextDestroyed(ServletContextEvent event) {
System.out.println("Context destroyed on " +
new Date() + ".");
}
}
程序清单5-21 web.xml(声明一个监听程序的摘录)
<?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-mapping> … </filter-mapping>
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
<servlet> ... </servlet>
<!-- ... -->
</web-app>
15J2EE元素
本节描述用作J2EE环境组成部分的Web应用的web.xml元素。这里将提供一个简明的介绍,详细内容可以参阅http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的Java 2 Plantform
Enterprise Edition版本1.3规范的第5章。
15.1 distributable
distributable 元素指出,Web应用是以这样的方式编程的:即,支持集群的服务器可安全地在多个服务器上分布Web应用。例如,一个可分布的应用必须只使用 Serializable对象
作为其HttpSession对象的属性,而且必须避免用实例变量(字段)来实现持续性。distributable元素直接出现在discription元素之后,并且不包含子元素或数据,它只是一个如
下的标志。
<distributable />
15.2 resource-env-ref
resource -env-ref元素声明一个与某个资源有关的管理对象。此元素由一个可选的description元素、一个resource-env-ref- name元素(一个相对于java:comp/env环境的JNDI名
)以及一个resource-env-type元素(指定资源类型的完全限定的类),如下所示:
<resource-env-ref>
<resource-env-ref-name>
jms/StockQueue
</resource-env-ref-name>
<resource-env-ref-type>
javax.jms.Queue
</resource-env-ref-type>
</resource-env-ref>
15.3 env-entry
env -entry元素声明Web应用的环境项。它由一个可选的description元素、一个env-entry-name元素(一个相对于java: comp/env环境JNDI名)、一个env-entry-value元素(项值
)以及一个env-entry-type元素(java.lang程序包中一个类型的完全限定类名,java.lang.Boolean、java.lang.String等)组成。下面是一个例子:
<env-entry>
<env-entry-name>minAmout</env-entry-name>
<env-entry-value>100.00</env-entry-value>
<env-entry-type>minAmout</env-entry-type>
</env-entry>
15.4 ejb-ref
ejb -ref元素声明对一个EJB的主目录的应用。它由一个可选的description元素、一个ejb-ref-name元素(相对于java: comp/env的EJB应用)、一个ejb-ref-type元素(bean的类
型,Entity或Session)、一个home元素(bean的主目录接口的完全限定名)、一个remote元素(bean的远程接口的完全限定名)以及一个可选的ejb-link元素(当前bean链接的另
一个 bean的名称)组成。
15.5 ejb-local-ref
ejb-local-ref元素声明一个EJB的本地主目录的引用。除了用local-home代替home外,此元素具有与ejb-ref元素相同的属性并以相同的方式使用
该文件描述了如何启动Tomcat Server
<Listener />
<GlobaNamingResources>
</GlobaNamingResources
<Service>
<Connector />
<Engine>
<Logger />
<Realm />
<host>
<Logger />
<Context />
</host>
</Engine>
</Service>
</Server>
元素名
| 属性
| 解释
|
server | port | 指定一个端口,这个端口负责监听关闭tomcat的请求 |
shutdown | 指定向端口发送的命令字符串 | |
service | name | 指定service的名字 |
Connector(表示客户端和service之间的连接) | port | 指定服务器端要创建的端口号,并在这个断口监听来自客户端的请求 |
minProcessors | 服务器启动时创建的处理请求的线程数 | |
maxProcessors | 最大可以创建的处理请求的线程数 | |
enableLookups | 如果为true,则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名,若为false则不进行DNS查询,而是返回其ip地址 | |
redirectPort | 指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号 | |
acceptCount | 指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理 | |
connectionTimeout | 指定超时的时间数(以毫秒为单位) | |
Engine(表示指定service中的请求处理机,接收和处理来自Connector的请求) | defaultHost | 指定缺省的处理请求的主机名,它至少与其中的一个host元素的name属性值是一样的 |
Context(表示一个web应用程序,通常为WAR文件,关于WAR的具体信息见servlet规范) | docBase | 应用程序的路径或者是WAR文件存放的路径 |
path | 表示此web应用程序的url的前缀,这样请求的url为http://localhost:8080/path/**** | |
reloadable | 这个属性非常重要,如果为true,则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化,自动装载新的应用程序,我们可以在不重起tomcat的情况下改变应用程序 | |
host(表示一个虚拟主机) | name | 指定主机名 |
appBase | 应用程序基本目录,即存放应用程序的目录 | |
unpackWARs | 如果为true,则tomcat会自动将WAR文件解压,否则不解压,直接从WAR文件中运行应用程序 | |
Logger(表示日志,调试和错误信息) | className | 指定logger使用的类名,此类必须实现org.apache.catalina.Logger 接口 |
prefix | 指定log文件的前缀 | |
suffix | 指定log文件的后缀 | |
timestamp | 如果为true,则log文件名中要加入时间,如下例:localhost_log.001-10-04.txt | |
Realm(表示存放用户名,密码及role的数据库) | className | 指定Realm使用的类名,此类必须实现org.apache.catalina.Realm接口 |
Valve(功能与Logger差不多,其prefix和suffix属性解释和Logger 中的一样) | className | 指定Valve使用的类名,如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息 |
directory | 指定log文件存放的位置 | |
pattern | 有两个值,common方式记录远程主机名或ip地址,用户名,日期,第一行请求的字符串,HTTP响应代码,发送的字节数。combined方式比common方式记录的值更多 |
<Server>元素
它代表整个容器,是Tomcat实例的顶层元素.由org.apache.catalina.Server接口来定义.它包含一个<Service>元素.并且它不能做为任何元素的子元素.
<!-- 一个“Server”是一个提供完整的JVM的独立组件,它可以包含一个或多个
“Service”实例。服务器在指定的端口上监听shutdown命令。
注意:一个“Server”自身不是一个“Container”(容器),因此在这里你
不可以定义诸如“Valves”或者“Loggers”子组件
-->
在端口8005处等待关闭命令
如果接受到"SHUTDOWN"字符串则关闭服务器
-->
测试:
telnet localhost 8005
输入:SHUTDOWN
结果:关闭tomcat
<Server port="8005" shutdown="SHUTDOWN" debug="0">
1>className指定实现org.apache.catalina.Server接口的类.默认值为org.apache.catalina.core.StandardServer
2>port指定Tomcat监听shutdown命令端口.终止服务器运行时,必须在Tomcat服务器所在的机器上发出shutdown命令.该属性是必须的.
3>shutdown指定终止Tomcat服务器运行时,发给Tomcat服务器的shutdown监听端口的字符串.该属性必须设置
<Service>元素
该元素由org.apache.catalina.Service接口定义,它包含一个<Engine>元素,以及一个或多个<Connector>,这些Connector元素共享用同一个Engine元素
<!-- 一个“Service”是一个或多个共用一个单独“Container”(容器)的“Connectors”
组合(因此,应用程序在容器中可见)。通常,这个容器是一个“Engine”
(引擎),但这不是必须的。
注意:一个“Service”自身不是一个容器,因此,在这个级别上你不可定义
诸如“Valves”或“Loggers”子组件。
-->
Service是一组Connector的集合
它们共用一个Engine来处理所有Connector收到的请求
-->
<Service name="Catalina">
<Service name="Apache">
第一个<Service>处理所有直接由Tomcat服务器接收的web客户请求.
第二个<Service>处理所有由Apahce服务器转发过来的Web客户请求 .
1>className 指定实现org.apahce.catalina.Service接口的类.默认为org.apahce.catalina.core.StandardService
2>name定义Service的名字
<Connector>元素
由Connector接口定义.<Connector>元素代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果.
<!-- 一个“Connector”(连接器)代表一个请求被接收和应答所需要的端点。每个连
接器通过相关的“Container”(容器)处理请求。
默认情况下,一个非SSL的HTTP/1.1的连接器被绑定在端口8080。你也可以通过
根据后面的使用说明并取消第二个连接器入口的注释,在端口8443上建立一个
SSL HTTP/1.1的连接器。开放SSL支持需要下面几步(参见Tomcat 5文档中怎样
配置SSL的说明以取得更多的详细信息):
* 如果你的JDK是1.3或1.3以前的版本,下载安装JSSE 1.0.2或以后版本,并放
置JAR文件到“$JAVA_HOME/jre/lib/ext”目录下。
* 带一个“changeit”的口令值执行:
%JAVA_HOME%/bin/keytool -genkey -alias tomcat -keyalg RSA (Windows)
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (UNIX)
来生成它自己的证书私钥。
默认情况下,当一个web应用程序调用请求时,DNS查询是可行的。这将对性能造
成一些不利的影响,因此,你可以将“enableLookups”设置为“false”来关闭DNS
查询。当DNS查询被关闭时,request.getRemoteHost()将返回包含远程客户IP地
址的字符串。
-->
className : 该Connector的实现类是org.apache.coyote.tomcat4.CoyoteConnector
port : 在端口号8080处侦听来自客户browser的HTTP1.1请求.如果把8080改成80,则只要输入 http://localhost/即可
protocol:设定Http协议,默认值为HTTP/1.1
minSpareThreads: 该Connector先创建5个线程等待客户请求,每个请求由一个线程负责
maxSpareThread:设定在监听端口的线程的最大数目,这个值也决定了服务器可以同时响应客户请求的最大数目.默认值为200
acceptCount : 当现有线程已经达到最大数75时,为客户请求排队.当队列中请求数超过100时,后来的请求返回Connection refused错误
redirectport : 当客户请求是https时,把该请求转发到端口8443去
enableLookups:如果设为true,表示支持域名解析,可以把IP地址解析为主机名.WEB应用中调用request.getRemoteHost方法返回客户机主机名.默认值为true
connectionTimeout:定义建立客户连接超时的时间.如果为-1,表示不限制建立客户连接的时间
其它属性略
-->
<Connector port="8080" maxThread="50" minSpareThreads="25" maxSpareThread="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" />
<Connection port="8009" enableLookups="false" redirectPort="8443" debug="0" protocol="AJP/1.3" />
第一个Connector元素定义了一个HTTP Connector,它通过8080端口接收HTTP请求;第二个Connector元素定义了一个JD Connector,它通过8009端口接收由其它服务器转发过来的请求.
<Engine>元素
每个Service元素只能有一个Engine元素.处理在同一个<Service>中所有<Connector>元素接收到的客户请求.由org.apahce.catalina.Engine接口定义.
<!-- 一个“Engine”(引擎)代表处理每个请求的入口点(在Catalina内)。这个Tomcat
的标准独立引擎实现分析包含在请求中的HTTP头信息,并将请求传送到适当的主机
或虚拟主机上。-->
它将匹配请求和自己的虚拟主机,并把请求转交给对应的Host来处理
默认虚拟主机是localhost
-->
<Engine name="Catalina" defaultHost="localhost" debug="0">
1>className指定实现Engine接口的类,默认值为StandardEngine
2>defaultHost指定处理客户的默认主机名,在<Engine>中的<Host>子元素中必须定义这一主机
3>name定义Engine的名字
在<Engine>可以包含如下元素<Logger>, <Realm>, <Value>, <Host>
<Host>元素
它由Host接口定义.一个Engine元素可以包含多个<Host>元素.每个<Host>的元素定义了一个虚拟主机.它包含了一个或多个Web应用.
<!-- 定义默认的虚拟主机
注意:XML模式确认将不能与Xerces 2.2同工作。
-->
appBase : 指定虚拟主机的目录,可以指定绝对目录,也可以指定相对于<CATALINA_HOME>的相对目录.如果没有此项,默认为< CATALINA_HOME>/webapps. 它将匹配请求和自己的Context的路径,并把请求转交给对应的Context来处理
autoDeploy:如果此项设为true,表示Tomcat服务处于运行状态时,能够监测appBase下的文件,如果有新有web应用加入进来,会自运发布这个WEB应用
unpackWARs:如果此项设置为true,表示把WEB应用的WAR文件先展开为开放目录结构后再运行.如果设为false将直接运行为WAR文件
alias:指定主机别名,可以指定多个别名
deployOnStartup:如果此项设为true,表示Tomcat服务器启动时会自动发布appBase目录下所有的Web应用.如果Web应用中的server.xml没有相应的<Context>元素,将采用Tomcat默认的Context
-->
<Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
在<Host>元素中可以包含如下子元素
<Logger>, <Realm>, <Value>, <Context>
<Context>元素
它由Context接口定义.是使用最频繁的元素.每个<Context元素代表了运行在虚拟主机上的单个Web应用.一个<Host>可以包含多个<Context>元素.每个web应用有唯一
的一个相对应的Context代表web应用自身.servlet容器为第一个web应用创建一个
path : 该Context的路径名是"",故该Context是该Host的默认Context
docBase : 该Context的根目录是webapps/mycontext/
reloadable:如果这个属性设为true, Tomcat服务器在运行状态下会监视在WEB-INF/classes和Web-INF/lib目录CLASS文件的改运.如果监视到有class文件被更新,服务器自重新加载Web应用
useNaming:指定是否支持JNDI,默认值为了true
cookies指定是否通过Cookies来支持Session,默认值为true
-->
<Context path="" docBase="mycontext" debug="0"/>
Tomcat Server处理一个http请求的过程
假设来自客户的请求为:
http://localhost:8080/wsota/wsota_index.jsp
2) Connector把该请求交给它所在的Service的Engine来处理,并等待来自Engine的回应
3) Engine获得请求localhost/wsota/wsota_index.jsp,匹配它所拥有的所有虚拟主机Host
4) Engine匹配到名为localhost的Host(即使匹配不到也把请求交给该Host处理,因为该Host被定义为该Engine的默认主机)
5) localhost Host获得请求/wsota/wsota_index.jsp,匹配它所拥有的所有Context
6) Host匹配到路径为/wsota的Context(如果匹配不到就把该请求交给路径名为""的Context去处理)
7) path="/wsota"的Context获得请求/wsota_index.jsp,在它的mapping table中寻找对应的servlet
8) Context匹配到URL PATTERN为*.jsp的servlet,对应于JspServlet类
9) 构造HttpServletRequest对象和HttpServletResponse对象,作为参数调用JspServlet的doGet或doPost方法
10)Context把执行完了之后的HttpServletResponse对象返回给Host
11)Host把HttpServletResponse对象返回给Engine
12)Engine把HttpServletResponse对象返回给Connector
13)Connector把HttpServletResponse对象返回给客户browser