配置系統管理(Admin Web Application) 大多數商業化的J
EE服務器都提供一個功能強大的管理界面
且大都采用易於理解的Web應用界面
Tomcat按照自己的方式
同樣提供一個成熟的管理工具
並且絲毫不遜於那些商業化的競爭對手
Tomcat的Admin Web Application最初在
版本時出現
當時的功能包括管理context
data source
user和group等
當然也可以管理像初始化參數
user
group
role的多種數據庫管理等
在後續的版本中
這些功能將得到很大的擴展
但現有的功能已經非常實用了
Admin Web Application被定義在自動部署文件
CATALINA_BASE/webapps/admin
xml
(譯者注
CATALINA_BASE即tomcat安裝目錄下的server目錄)
你必須編輯這個文件
以確定Context中的docBase參數是絕對路徑
也就是說
CATALINA
_BASE/webapps/admin
xml的路徑是絕對路徑
作為另外一種選擇
你也可以刪除這個自動部署文件
而在server
xml文件中建立一個Admin Web Application的context
效果是一樣的
你不能管理Admin Web Application這個應用
換而言之
除了刪除CATALINA_BASE/webapps/admin
xml
你可能什麼都做不了
如果你使用UserDatabaseRealm(默認)
你將需要添加一個user以及一個role到CATALINA_BASE/conf/tomcat
users
xml文件中
你編輯這個文件
添加一個名叫
admin
的role 到該文件中
如下
<role name=
admin
/>
你同樣需要有一個用戶
並且這個用戶的角色是
admin
象存在的用戶那樣
添加一個用戶(改變密碼使其更加安全)
<user name=
admin
password=
deep_dark_secret
roles=
admin
/>
當你完成這些步驟後
請重新啟動Tomcat
訪//localhost:
/admin
你將看到一個登錄界面
Admin Web Application采用基於容器管理的安全機制
並采用了Jakarta Struts框架
一旦你作為
admin
角色的用戶登錄管理界面
你將能夠使用這個管理界面配置Tomcat
配置應用管理(Manager Web Application) Manager Web Application讓你通過一個比Admin Web Application更為簡單的用戶界面
執行一些簡單的Web應用任務
Manager Web Application被被定義在一個自動部署文件中
CATALINA_BASE/webapps/manager
xml
你必須編輯這個文件
以確保context的docBase參數是絕對路徑
也就是說CATALINA_HOME/server/webapps/manager的絕對路徑
(譯者注
CATALINA_HOME即tomcat安裝目錄)
如果你使用的是UserDatabaseRealm
那麼你需要添加一個角色和一個用戶到CATALINA_BASE/conf/tomcat
users
xml文件中
接下來
編輯這個文件
添加一個名為
manager
的角色到該文件中
<role name=
manager
>
你同樣需要有一個角色為
manager
的用戶
像已經存在的用戶那樣
添加一個新用戶(改變密碼使其更加安全)
<user name=
manager
password=
deep_dark_secret
roles=
manager
/>
然後重新啟動Tomcat
訪//localhost/manager/list
將看到一個很樸素的文本型管理界面
或者訪//localhost/manager/html/list
將看到一個HMTL的管理界面
不管是哪種方式都說明你的Manager Web Application現在已經啟動了
Manager application讓你可以在沒有系統管理特權的基礎上
安裝新的Web應用
以用於測試
如果我們有一個新的web應用位於/home/user/hello下在
並且想把它安裝到/hello下
為了測試這個應用
我們可以這麼做
在第一個文件框中輸入
/hello
(作為訪問時的path)
在第二個文本框中輸入
file:/home/user/hello
(作為Config URL)
Manager application還允許你停止
重新啟動
移除以及重新部署一個web應用
停止一個應用使其無法被訪問
當有用戶嘗試訪問這個被停止的應用時
將看到一個
的錯誤??
This application is not currently available
移除一個web應用
只是指從Tomcat的運行拷貝中刪除了該應用
如果你重新啟動Tomcat
被刪除的應用將再次出現(也就是說
移除並不是指從硬盤上刪除)
部署一個web應用 有兩個辦法可以在系統中部署web服務
拷貝你的WAR文件或者你的web應用文件夾(包括該web的所有內容)到$CATALINA_BASE/webapps目錄下
為你的web服務建立一個只包括context內容的XML片斷文件
並把該文件放到$CATALINA_BASE/webapps目錄下
這個web應用本身可以存儲在硬盤上的任何地方
如果你有一個WAR文件
你若想部署它
則只需要把該文件簡單的拷貝到CATALINA_BASE/webapps目錄下即可
文件必須以
war
作為擴展名
一旦Tomcat監聽到這個文件
它將(缺省的)解開該文件包作為一個子目錄
並以WAR文件的文件名作為子目錄的名字
接下來
Tomcat將在內存中建立一個context
就好象你在server
xml文件裡建立一樣
當然
其他必需的內容
將從server
xml中的DefaultContext獲得
部署web應用的另一種方式是寫一個Context XML片斷文件
然後把該文件拷貝到CATALINA_BASE/webapps目錄下
一個Context片斷並非一個完整的XML文件
而只是一個context元素
以及對該應用的相應描述
這種片斷文件就像是從server
xml中切取出來的context元素一樣
所以這種片斷被命名為
context片斷
舉個例子
如果我們想部署一個名叫MyWebApp
war的應用
該應用使用realm作為訪問控制方式
我們可以使用下面這個片斷
<!
Context fragment for deploying MyWebApp
war
>
<Context path=
/demo
docBase=
webapps/MyWebApp
war
debug=
privileged=
true
>
<Realm className=
org
apache
catalina
realm
UserDatabaseRealm
resourceName=
UserDatabase
/>
</Context>
把該片斷命名為
MyWebApp
xml
然後拷貝到CATALINA_BASE/webapps目錄下
這種context片斷提供了一種便利的方法來部署web應用
你不需要編輯server
xml
除非你想改變缺省的部署特性
安裝一個新的web應用時不需要重啟動Tomcat
配置虛擬主機(Virtual Hosts) 關於server
xml中
Host
這個元素
只有在你設置虛擬主機的才需要修改
虛擬主機是一種在一個web服務器上服務多個域名的機制
對每個域名而言
都好象獨享了整個主機
實際上
大多數的小型商務網站都是采用虛擬主機實現的
這主要是因為虛擬主機能直接連接到Internet並提供相應的帶寬
以保障合理的訪問響應速度
另外虛擬主機還能提供一個穩定的固定IP
基於名字的虛擬主機可以被建立在任何web服務器上
建立的方法就是通過在域名服務器(DNS)上建立IP地址的別名
並且告訴web服務器把去往不同域名的請求分發到相應的網頁目錄
因為這篇文章主要是講Tomcat
我們不准備介紹在各種操作系統上設置DNS的方法
如果你在這方面需要幫助
請參考《DNS and Bind》一書
作者是Paul Albitz and Cricket Liu (O
Reilly)
為了示范方便
我將使用一個靜態的主機文件
因為這是測試別名最簡單的方法
在Tomcat中使用虛擬主機
你需要設置DNS或主機數據
為了測試
為本地IP設置一個IP別名就足夠了
接下來
你需要在server
xml中添加幾行內容
如下
<Server port=
shutdown=
SHUTDOWN
debug=
>
<Service name=
Tomcat
Standalone
>
<Connector className=
yote
tomcat
CoyoteConnector
port=
minProcessors=
maxProcessors=
enableLookups=
true
redirectPort=
/>
<Connector className=
yote
tomcat
CoyoteConnector
port=
minProcessors=
maxProcessors=
acceptCount=
debug=
scheme=
https
secure=
true
/>
<Factory className=
yote
tomcat
CoyoteServerSocketFactory
clientAuth=
false
protocol=
TLS
/>
</Connector>
<Engine name=
Standalone
defaultHost=
localhost
debug=
>
<!
This Host is the default Host
>
<Host name=
localhost
debug=
appBase=
webapps
unpackWARs=
true
autoDeploy=
true
>
<Context path=
docBase=
ROOT
debug=
/>
<Context path=
/orders
docBase=
/home/ian/orders
debug=
reloadable=
true
crossContext=
true
>
</Context>
</Host>
<!
This Host is the first
Virtual Host
:
>
<Host name=
appBase=
/home/example/webapp
>
<Context path=
docBase=
/>
</Host>
</Engine>
</Service>
</Server>
Tomcat的server
xml文件
在初始狀態下
只包括一個虛擬主機
但是它容易被擴充到支持多個虛擬主機
在前面的例子中展示的是一個簡單的server
xml版本
其中粗體部分就是用於添加一個虛擬主機
每一個Host元素必須包括一個或多個context元素
所包含的context元素中必須有一個是默認的context
這個默認的context的顯示路徑應該為空(例如
path=
)
配置基礎驗證(Basic Authentication) 容器管理驗證方法控制著當用戶訪問受保護的web應用資源時
如何進行用戶的身份鑒別
當一個web應用使用了Basic Authentication(BASIC參數在web
xml文件中auto
method元素中設置)
而有用戶訪問受保護的web應用時
Tomcat將通過HTTP Basic Authentication方式
彈出一個對話框
要求用戶輸入用戶名和密碼
在這種驗證方法中
所有密碼將被以
位的編碼方式在網絡上傳輸
注意
使用Basic Authentication通過被認為是不安全的
因為它沒有強健的加密方法
除非在客戶端和服務器端都使用HTTPS或者其他密碼加密碼方式(比如
在一個虛擬私人網絡中)
若沒有額外的加密方法
網絡管理員將能夠截獲(或濫用)用戶的密碼
但是
如果你是剛開始使用Tomcat
或者你想在你的web應用中測試一下基於容器的安全管理
Basic Authentication還是非常易於設置和使用的
只需要添加<security
constraint>和<login
config>兩個元素到你的web應用的web
xml文件中
並且在CATALINA_BASE/conf/tomcat
users
xml文件中添加適當的<role>和<user>即可
然後重新啟動Tomcat
下面例子中的web
xml摘自一個俱樂部會員網站系統
該系統中只有member目錄被保護起來
並使用Basic Authentication進行身份驗證
請注意
這種方式將有效的代替Apache web服務器中的
htaccess文件
<!
Define the
Members
only area
by defining
a
Security Constraint
on this Application
and
mapping it to the
subdirectory (URL) that we want
to restrict
>
<security
constraint>
<web
resource
collection>
<web
resource
name>
Entire Application
</web
resource
name>
<url
pattern>/members/*</url
pattern>
</web
resource
collection>
<auth
constraint>
<role
name>member</role
name>
</auth
constraint>
</security
constraint>
<!
Define the Login
Configuration for
this Application
>
<login
config>
<auth
method>BASIC</auth
method>
<realm
name>My Club
Members
only Area</realm
name>
</login
config>
配置單點登錄(Single SignOn) 一旦你設置了realm和驗證的方法
你就需要進行實際的用戶登錄處理
一般說來
對用戶而言登錄系統是一件很麻煩的事情
你必須盡量減少用戶登錄驗證的次數
作為缺省的情況
當用戶第一次請求受保護的資源時
每一個web應用都會要求用戶登錄
如果你運行了多個web應用
並且每個應用都需要進行單獨的用戶驗證
那這看起來就有點像你在與你的用戶搏斗
用戶們不知道怎樣才能把多個分離的應用整合成一個單獨的系統
所有他們也就不知道他們需要訪問多少個不同的應用
只是很迷惑
為什麼總要不停的登錄
Tomcat
的
single sign
on
特性允許用戶在訪問同一虛擬主機下所有web應用時
只需登錄一次
為了使用這個功能
你只需要在Host上添加一個SingleSignOn Valve元素即可
如下所示
<Valve className=
org
apache
catalina
authenticator
SingleSignOn
debug=
/>
在Tomcat初始安裝後
server
xml的注釋裡面包括SingleSignOn Valve配置的例子
你只需要去掉注釋
即可使用
那麼
任何用戶只要登錄過一個應用
則對於同一虛擬主機下的所有應用同樣有效
使用single sign
on valve有一些重要的限制
> value必須被配置和嵌套在相同的Host元素裡
並且所有需要進行單點驗證的web應用(必須通過context元素定義)都位於該Host下
> 包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套之外
> 不能被context中的realm覆蓋
> 使用單點登錄的web應用最好使用一個Tomcat的內置的驗證方式(被定義在web
xml中的<auth
method>中)
這比自定義的驗證方式強
Tomcat內置的的驗證方式包括basic
digest
form和client
cert
> 如果你使用單點登錄
還希望集成一個第三方的web應用到你的網站中來
並且這個新的web應用使用它自己的驗證方式
而不使用容器管理安全
那你基本上就沒招了
你的用戶每次登錄原來所有應用時需要登錄一次
並且在請求新的第三方應用時還得再登錄一次
當然
如果你擁有這個第三方web應用的源碼
而你又是一個程序員
你可以修改它
但那恐怕也不容易做
> 單點登錄需要使用cookies
配置用戶定制目錄(Customized User Directores) 一些站點允許個別用戶在服務器上發布網頁
例如
一所大學的學院可能想給每一位學生一個公共區域
或者是一個ISP希望給一些web空間給他的客戶
但這又不是虛擬主機
在這種情況下
一個典型的方法就是在用戶名前面加一個特殊字符(~)
作為每位用戶的網站
比如
~username
~username
Tomcat提供兩種方法在主機上映射這些個人網站
主要使用一對特殊的Listener元素
Listener的className屬性應該是org
apache
catalina
startup
UserConfig
userClass屬性應該是幾個映射類之一
如果你的系統是Unix
它將有一個標准的/etc/passwd文件
該文件中的帳號能夠被運行中的Tomcat很容易的讀取
該文件指定了用戶的主目錄
使用PasswdUserDatabase 映射類
<Listener className=
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類
<Listener className=
org
apache
catalina
startup
UserConfig
directoryName=
public_html
homeBase=
/home
userClass=
org
apache
catalina
startup
HomesUserDatabase
/>
這樣一來
web文件就可以位於像/home/ian/public_html或者/home/jasonb/public_html一樣的目錄下
這種形式對Windows而言更加有利
你可以使用一個像c:\home這樣的目錄
這些Listener元素
如果出現
則必須在Host元素裡面
而不能在context元素裡面
因為它們都用應用於Host本身
在Tomcat中使用CGI腳本 Tomcat主要是作為Servlet/JSP容器
但它也有許多傳統web服務器的性能
支持通用網關接口(Common Gateway Interface
即CGI)就是其中之一
CGI提供一組方法在響應浏覽器請求時運行一些擴展程序
CGI之所以被稱為通用
是因為它能在大多數程序或腳本中被調用
包括
Perl
Python
awk
Unix shell scripting等
甚至包括Java
當然
你大概不會把一個Java應用程序當作CGI來運行
畢竟這樣太過原始
一般而言
開發Servlet總要比CGI具有更好的效率
因為當用戶點擊一個鏈接或一個按鈕時
你不需要從操作系統層開始進行處理
Tomcat包括一個可選的CGI Servlet
允許你運行遺留下來的CGI腳本
為了使Tomcat能夠運行CGI
你必須做如下幾件事
把servlets
cgi
renametojar (在CATALINA_HOME/server/lib/目錄下)改名為servlets
cgi
jar
處理CGI的servlet應該位於Tomcat的CLASSPATH下
在Tomcat的CATALINA_BASE/conf/web
xml 文件中
把關於<servlet
name> CGI的那段的注釋去掉(默認情況下
該段位於第
行)
同樣
在Tomcat的CATALINA_BASE/conf/web
xml文件中
把關於對CGI進行映射的那段的注釋去掉(默認情況下
該段位於第
行)
注意
這段內容指定了HTML鏈接到CGI腳本的訪問方式
你可以把CGI腳本放置在WEB
INF/cgi 目錄下(注意
WEB
INF是一個安全的地方
你可以把一些不想被用戶看見或基於安全考慮不想暴露的文件放在此處)
或者你也可以把CGI腳本放置在context下的其他目錄下
並為CGI Servlet調整cgiPathPrefix初始化參數
這就指定的CGI Servlet的實際位置
且不能與上一步指定的URL重名
重新啟動Tomcat
你的CGI就可以運行了
在Tomcat中
CGI程序缺省放置在WEB
INF/cgi目錄下
正如前面所提示的那樣
WEB
INF目錄受保護的
通過客戶端的浏覽器無法窺探到其中內容
所以對於放置含有密碼或其他敏感信息的CGI腳本而言
這是一個非常好的地方
為了兼容其他服務器
盡管你也可以把CGI腳本保存在傳統的/cgi
bin目錄
但要知道
在這些目錄中的文件有可能被網上好奇的沖浪者看到
另外
在Unix中
請確定運行Tomcat的用戶有執行CGI腳本的權限
改變Tomcat中的JSP編譯器(JSP Compiler) 在Tomcat
(或更高版本
大概)
JSP的編譯由包含在Tomcat裡面的Ant程序控制器直接執行
這聽起來有一點點奇怪
但這正是Ant有意為之的一部分
有一個API文檔指導開發者在沒有啟動一個新的JVM的情況下
使用Ant
這是使用Ant進行Java開發的一大優勢
另外
這也意味著你現在能夠在Ant中使用任何javac支持的編譯方式
這裡有一個關於Apache Ant使用手冊的javac page列表
使用起來是容易的
因為你只需要在<init
param> 元素中定義一個名字叫
compiler
並且在value中有一個支持編譯的編譯器名字
示例如下
<servlet>
<servlet
name>jsp</servlet
name>
<servlet
class>
org
apache
jasper
servlet
JspServlet
</servlet
class>
<init
param>
<param
name>logVerbosityLevel
</param
name>
<param
value>WARNING</param
value>
</init
param>
<init
param>
<param
name>compiler</param
name>
<param
value>jikes</param
value>
</init
param>
<load
on
startup>
</load
on
startup>
</servlet>
當然
給出的編譯器必須已經安裝在你的系統中
並且CLASSPATH可能需要設置
那處決於你選擇的是何種編譯器
限制特定主機訪問(Restricting Access to Specific Hosts) 有時
你可能想限制對Tomcat web應用的訪問
比如
你希望只有你指定的主機或IP地址可以訪問你的應用
這樣一來
就只有那些指定的的客戶端可以訪問服務的內容了
為了實現這種效果
Tomcat提供了兩個參數供你配置
RemoteHostValve 和RemoteAddrValve
通過配置這兩個參數
可以讓你過濾來自請求的主機或IP地址
並允許或拒絕哪些主機/IP
與之類似的
在Apache的httpd文件裡有對每個目錄的允許/拒絕指定
例如你可以把Admin Web application設置成只允許本地訪問
設置如下
<Context path=
/path/to/secret_files
>
<Valve className=
org
apache
catalina
valves
RemoteAddrValve
allow=
deny=
/>
</Context>
如果沒有給出允許主機的指定
那麼與拒絕主機匹配的主機就會被拒絕
除此之外的都是允許的
與之類似
如果沒有給出拒絕主機的指定
那麼與允許主機匹配的主機就會被允許
除此之外的都是拒絕的
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28555.html