TOM系统安全配置Word格式.docx
《TOM系统安全配置Word格式.docx》由会员分享,可在线阅读,更多相关《TOM系统安全配置Word格式.docx(15页珍藏版)》请在冰豆网上搜索。
将其中的8080,改成80,然后重启tomcat,本机使用http:
//localhost即可访问。
注:
其他版本,查找相应的8080,然后修改。
3、修改发布目录
例如将d:
test目录作为自己的文档发布目录,并指定mytest为http访问的相对目录(本机即http:
//localhost/mytest)。
同上要修改server.xml文件,找到
--TomcatRootContext-->
--
Contextpath="
"
docBase="
ROOT"
/>
-->
去掉注释,或者将已经屏蔽掉的<
复制到下面的空白处,这时候复制的文本已经可以彩色亮显。
根据例子中的要求,修改这段文本如下:
/mytest"
d:
test"
然后重启tomcat,本机即可通过http:
//localhost/mytest来访问放在d:
test目录下的JSP文件。
总结:
如上例中发布目录结构整体结构如下:
test┄┄JSP文件
│
└/WEB-INF┄┄web.xml
│
└/classes┈┈JavaBean/Servlet文件
│
└myPackages(包路径)┈┈JavaBean/Servlet文件
Tomcat配置技巧Top10
2004-01-0917:
19:
25
作者:
JasonBrittain&
IanF.Darwin
出处:
译者:
陈光
2003-12-31
编者按:
现在开发JavaWeb应用,建立和部署Web内容是一件很简单的工作。
使用JakartaTomcat作为Servlet和JSP容器的人已经遍及全世界。
Tomcat具有免费、跨平台等诸多特性,并且更新得很快,现在非常的流行。
你所需要做的就是:
按照你的需求配置Tomcat,只要你正确配置,Tomcat一般都能适合你的要求。
下面是一系列关于Tomcat的配置技巧,这些技巧源自于我的书:
《Tomcat权威指南》,希望对你有所帮助。
——JasonBrittain
1.配置系统管理(AdminWebApplication)
大多数商业化的J2EE服务器都提供一个功能强大的管理界面,且大都采用易于理解的Web应用界面。
Tomcat按照自己的方式,同样提供一个成熟的管理工具,并且丝毫不逊于那些商业化的竞争对手。
Tomcat的AdminWebApplication最初在4.1版本时出现,当时的功能包括管理context、datasource、user和group等。
当然也可以管理像初始化参数,user、group、role的多种数据库管理等。
在后续的版本中,这些功能将得到很大的扩展,但现有的功能已经非常实用了。
AdminWebApplication被定义在自动部署文件:
CATALINA_BASE/webapps/admin.xml。
(译者注:
CATALINA_BASE即tomcat安装目录下的server目录)
你必须编辑这个文件,以确定Context中的docBase参数是绝对路径。
也就是说,CATALINA_BASE/webapps/admin.xml的路径是绝对路径。
作为另外一种选择,你也可以删除这个自动部署文件,而在server.xml文件中建立一个AdminWebApplication的context,效果是一样的。
你不能管理AdminWebApplication这个应用,换而言之,除了删除CATALINA_BASE/webapps/admin.xml,你可能什么都做不了。
如果你使用UserDatabaseRealm(默认),你将需要添加一个user以及一个role到CATALINA_BASE/conf/tomcat-users.xml文件中。
你编辑这个文件,添加一个名叫“admin”的role到该文件中,如下:
rolename="
admin"
你同样需要有一个用户,并且这个用户的角色是“admin”。
象存在的用户那样,添加一个用户(改变密码使其更加安全):
username="
password="
deep_dark_secret"
roles="
当你完成这些步骤后,请重新启动Tomcat,访问http:
//localhost:
8080/admin,你将看到一个登录界面。
AdminWebApplication采用基于容器管理的安全机制,并采用了JakartaStruts框架。
一旦你作为“admin”角色的用户登录管理界面,你将能够使用这个管理界面配置Tomcat。
2.配置应用管理(ManagerWebApplication)
ManagerWebApplication让你通过一个比AdminWebApplication更为简单的用户界面,执行一些简单的Web应用任务。
ManagerWebApplication被被定义在一个自动部署文件中:
CATALINA_BASE/webapps/manager.xml。
你必须编辑这个文件,以确保context的docBase参数是绝对路径,也就是说CATALINA_HOME/server/webapps/manager的绝对路径。
CATALINA_HOME即tomcat安装目录)
如果你使用的是UserDatabaseRealm,那么你需要添加一个角色和一个用户到CATALINA_BASE/conf/tomcat-users.xml文件中。
接下来,编辑这个文件,添加一个名为“manager”的角色到该文件中:
rolename=”manager”>
你同样需要有一个角色为“manager”的用户。
像已经存在的用户那样,添加一个新用户(改变密码使其更加安全):
manager"
然后重新启动Tomcat,访问http:
//localhost/manager/list,将看到一个很朴素的文本型管理界面,或者访问http:
//localhost/manager/html/list,将看到一个HMTL的管理界面。
不管是哪种方式都说明你的ManagerWebApplication现在已经启动了。
Managerapplication让你可以在没有系统管理特权的基础上,安装新的Web应用,以用于测试。
如果我们有一个新的web应用位于/home/user/hello下在,并且想把它安装到/hello下,为了测试这个应用,我们可以这么做,在第一个文件框中输入“/hello”(作为访问时的path),在第二个文本框中输入“file:
/home/user/hello”(作为ConfigURL)。
Managerapplication还允许你停止、重新启动、移除以及重新部署一个web应用。
停止一个应用使其无法被访问,当有用户尝试访问这个被停止的应用时,将看到一个503的错误——“503-Thisapplicationisnotcurrentlyavailable”。
移除一个web应用,只是指从Tomcat的运行拷贝中删除了该应用,如果你重新启动Tomcat,被删除的应用将再次出现(也就是说,移除并不是指从硬盘上删除)。
3.部署一个web应用
有两个办法可以在系统中部署web服务。
1>
拷贝你的WAR文件或者你的web应用文件夹(包括该web的所有内容)到$CATALINA_BASE/webapps目录下。
2>
为你的web服务建立一个只包括context内容的XML片断文件,并把该文件放到$CATALINA_BASE/webapps目录下。
这个web应用本身可以存储在硬盘上的任何地方。
如果你有一个WAR文件,你若想部署它,则只需要把该文件简单的拷贝到CATALINA_BASE/webapps目录下即可,文件必须以“.war”作为扩展名。
一旦Tomcat监听到这个文件,它将(缺省的)解开该文件包作为一个子目录,并以WAR文件的文件名作为子目录的名字。
接下来,Tomcat将在内存中建立一个context,就好象你在server.xml文件里建立一样。
当然,其他必需的内容,将从server.xml中的DefaultContext获得。
部署web应用的另一种方式是写一个ContextXML片断文件,然后把该文件拷贝到CATALINA_BASE/webapps目录下。
一个Context片断并非一个完整的XML文件,而只是一个context元素,以及对该应用的相应描述。
这种片断文件就像是从server.xml中切取出来的context元素一样,所以这种片断被命名为“context片断”。
举个例子,如果我们想部署一个名叫MyWebApp.war的应用,该应用使用realm作为访问控制方式,我们可以使用下面这个片断:
ContextfragmentfordeployingMyWebApp.war
/demo"
webapps/MyWebApp.war"
privileged="
>
<
RealmclassName="
org.apache.catalina.realm.UserDatabaseRealm"
resourceName="
UserDatabase"
/Context>
把该片断命名为“MyWebApp.xml”,然后拷贝到CATALINA_BASE/webapps目录下。
这种context片断提供了一种便利的方法来部署web应用,你不需要编辑server.xml,除非你想改变缺省的部署特性,安装一个新的web应用时不需要重启动Tomcat。
4.配置虚拟主机(VirtualHosts)
关于server.xml中“Host”这个元素,只有在你设置虚拟主机的才需要修改。
虚拟主机是一种在一个web服务器上服务多个域名的机制,对每个域名而言,都好象独享了整个主机。
实际上,大多数的小型商务网站都是采用虚拟主机实现的,这主要是因为虚拟主机能直接连接到Internet并提供相应的带宽,以保障合理的访问响应速度,另外虚拟主机还能提供一个稳定的固定IP。
基于名字的虚拟主机可以被建立在任何web服务器上,建立的方法就是通过在域名服务器(DNS)上建立IP地址的别名,并且告诉web服务器把去往不同域名的请求分发到相应的网页目录。
因为这篇文章主要是讲Tomcat,我们不准备介绍在各种操作系统上设置DNS的方法,如果你在这方面需要帮助,请参考《DNSandBind》一书,作者是PaulAlbitzandCricketLiu(O'
Reilly)。
为了示范方便,我将使用一个静态的主机文件,因为这是测试别名最简单的方法。
在Tomcat中使用虚拟主机,你需要设置DNS或主机数据。
为了测试,为本地IP设置一个IP别名就足够了,接下来,你需要在server.xml中添加几行内容,如下:
Serverport="
8005"
shutdown="
SHUTDOWN"
Servicename="
Tomcat-Standalone"
ConnectorclassName="
org.apache.coyote.tomcat4.CoyoteConnector"
port="
enableLookups="
acceptCount="
10"
scheme="
https"
secure="
FactoryclassName="
org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
clientAuth="
protocol="
TLS"
/Connector>
Enginename="
Standalone"
defaultHost="
localhost"
--ThisHostisthedefaultHost-->
Hostname="
appBase="
webapps"
unpackWARs="
autoDeploy="
/orders"
/home/ian/orders"
reloadable="
crossContext="
/Host>
--ThisHostisthefirst"
VirtualHost"
:
-->
/home/example/webapp"
."
/Engine>
/Service>
/Server>
Tomcat的server.xml文件,在初始状态下,只包括一个虚拟主机,但是它容易被扩充到支持多个虚拟主机。
在前面的例子中展示的是一个简单的server.xml版本,其中粗体部分就是用于添加一个虚拟主机。
每一个Host元素必须包括一个或多个context元素,所包含的context元素中必须有一个是默认的context,这个默认的context的显示路径应该为空(例如,path=””)。
5.配置基础验证(BasicAuthentication)
容器管理验证方法控制着当用户访问受保护的web应用资源时,如何进行用户的身份鉴别。
当一个web应用使用了BasicAuthentication(BASIC参数在web.xml文件中auto-method元素中设置),而有用户访问受保护的web应用时,Tomcat将通过HTTPBasicAuthentication方式,弹出一个对话框,要求用户输入用户名和密码。
在这种验证方法中,所有密码将被以64位的编码方式在网络上传输。
注意:
使用BasicAuthentication通过被认为是不安全的,因为它没有强健的加密方法,除非在客户端和服务器端都使用HTTPS或者其他密码加密码方式(比如,在一个虚拟私人网络中)。
若没有额外的加密方法,网络管理员将能够截获(或滥用)用户的密码。
但是,如果你是刚开始使用Tomcat,或者你想在你的web应用中测试一下基于容器的安全管理,BasicAuthentication还是非常易于设置和使用的。
只需要添加<
security-constraint>
和<
login-config>
两个元素到你的web应用的web.xml文件中,并且在CATALINA_BASE/conf/tomcat-users.xml文件中添加适当的<
role>
user>
即可,然后重新启动Tomcat。
下面例子中的web.xml摘自一个俱乐部会员网站系统,该系统中只有member目录被保护起来,并使用BasicAuthentication进行身份验证。
请注意,这种方式将有效的代替Apacheweb服务器中的.htaccess文件。
--
DefinetheMembers-onlyarea,bydefining
a"
SecurityConstraint"
在Tomcat初始安装后,server.xml的注释里面包括SingleSignOnValve配置的例子,你只需要去掉注释,即可使用。
那么,任何用户只要登录过一个应用,则对于同一虚拟主机下的所有应用同样有效。
使用singlesign-onvalve有一些重要的限制:
value必须被配置和嵌套在相同的Host元素里,并且所有需要进行单点验证的web应用(必须通过context元素定义)都位于该Host下。
包括共享用户信息的realm必须被设置在同一级Host中或者嵌套之外。
3>
不能被context中的realm覆盖。
4>
使用单点登录的web应用最好使用一个Tomcat的内置的验证方式(被定义在web.xml中的<
auth-method>
中),这比自定义的验证方式强,Tomcat内置的的验证方式包括basic、digest、form和client-cert。
5>
如果你使用单点登录,还希望集成一个第三方的web应用到你的网站中来,并且这个新的web应用使用它自己的验证方式,而不使用容器管理安全,那你基本上就没招了。
你的用户每次登录原来所有应用时需要登录一次,并且在请求新的第三方应用时还得再登录一次。
当然,如果你拥有这个第三方web应用的源码,而你又是一个程序员,你可以修改它,但那恐怕也不容易做。
6>
单点登录需要使用cookies。
7.配置用户定制目录(CustomizedUserDirectores)
一些站点允许个别用户在服务器上发布网页。
例如,一所大学的学院可能想给每一位学生一个公共区域,或者是一个ISP希望给一些web空间给他的客户,但这又不是虚拟主机。
在这种情况下,一个典型的方法就是在用户名前面加一个特殊字符(~),作为每位用户的网站,比如:
http:
//www.cs.myuniversity.edu/~username
Tomcat提供两种方法在主机上映射这些个人网站,主要使用一对特殊的Listener元素。
Listener的className属性应该是org.apache.catalina.startup.UserConfig,userClass属性应该是几个映射类之一。
如果你的系统是Unix,它将有一个标准的/etc/passwd文件,该文件中的帐号能够被运行中的Tomcat很容易的读取,该文件指定了用户的主目录,使用PasswdUserDatabase映射类。
ListenerclassName="
org.apache.catalina.startup.UserConfig"
directoryName="
public_html"
userClass="
org.apache.catalina.startup.PasswdUserDatabase"
web文件需要放置在像/home/users/ian/public_html或者/users/jbrittain/public_html一样的目录下面。
当然你也可以改变public_html到其他任何子目录下。
实际上,这个用户目录根本不一定需要位于用户主目录下里面。
如果你没有一个密码文件,但你又想把一个用户名映射到公共的像/home一样目录的子目录里面,则可以使用HomesUserDatabase类。
homeBase="
/home"
org.apache.catalina.startup.HomesUserDatabase"
这样一来,web文件就可以位于像/home/ian/public_html或者/home/jasonb/public_html一样的目录下。
这种形式对Windows而言更加有利,你可以使用一个像c:
home这样的目录。
这些Listener元素,如果出现,则必须在Host元素里面,而不能在context元素里面,因为它们都用应用于Host本身。
8.在Tomcat中使用CGI脚本
Tomcat主要是作为Servlet/JSP容器,但它也有许多传统web服务器的性能。
支持通用网关接口(CommonGatewayInterface,即CGI)就是其中之一,CGI提供一组方法在响应浏览器请求时运行一些扩展程序。
CGI之所以被称为通用,是因为它能在大多数程序或脚本中被调用,包括:
Perl,Python,awk,Unixshellscripting等,甚至包括Java。
当然,你大概不会把一个Java应用程序当作CGI来运行,毕竟这样太过原始。
一般而言,开发Servlet总要比CGI具有更好的效率,因为当用户点击一个链接或一个按钮时,你不需要从操作系统层开始进行处理。
Tomcat包括一个可选的CGIServlet,允许你运行遗留下来的CGI脚本。
为了使Tomcat能够运行CGI,你必须做如下几件事:
1.把servlets-cgi.renametojar(在CATALINA_HOME/server/lib/目录下)改名为servlets-cgi.jar。
处理CGI的servlet应该位于Tomcat的CLASSPATH下。
2.在Tomcat的CATALINA_BASE/conf/web.xml文件中,把关于<
servlet-name>
CGI的那段的注释去掉(默认情况下,该段位于第241行)。
3.同样,在Tomcat的CATALINA_BASE/conf/web.xml文件中,把关于对CGI进行映射的那段的注释去掉(默认情况下,该段位于第299行)。
注意,这段内容指定了HTML链接到CGI脚本的访问方式。
4.你可以把CGI脚本放置在WEB-INF/cgi目录下(注意,WEB-INF是一个安全的地方,你可以把一些不