unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
數據源配置
比較複雜,各個版本都有所不同,請直接查看 http://java2000. net/p1906,包括tomcat5.0,tomcat5.5x,tomcat6.0的各個版本的配置方法。
(Admin Web Application)
大多數商業化的JavaEE伺服器都提供一個功能強大的管理界面,且大都採用易於理解的Web應用界面。Tomcat按照自己的方式,同樣提供一個成熟的管理工具,並且絲毫不遜於那些商業化的競爭對手。Tomcat的Admin Web Application最初在4.1版本時出現,當時的功能包括管理context、data source、user和group等。當然也可以管理像初始化參數,user、group、role的多種資料庫管理等。在後續的版本中,這些功能將得 到很大的擴展,但現有的功能已經非常實用了。
Admin Web Application被定義在自動部署文件:CATALINA_BASE/webapps/admin.xml 。
必須編輯這個文件,以確定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 到該文件中,如下:
同樣需要有一個用戶,並且這個用戶的角色是“admin”。象存在的用戶那樣,添加一個用戶(改變密碼使其更加安全):
當完成這些步驟后,請重新啟動Tomcat,訪問http://localhost:8080/admin,將看到一個登錄界面。Admin Web Application採用基於容器管理的安全機制,並採用了Jakarta Struts框架。一旦作為“admin”角色的用戶登錄管理界面,將能夠使用這個管理界面配置Tomcat。
Manager Web Application讓你通過一個比Admin Web Application更為簡單的用戶界面,執行一些簡單的Web應用任務。
Manager Web Application被定義在一個自動部署文件中:
CATALINA_BASE/webapps/manager.xml 。
必須編輯這個文件,以確保context的docBase參數是絕對路徑,也就是說CATALINA_HOME/server/webapps/manager的絕對路徑。
如果使用的是UserDatabaseRealm,那麼需要添加一個角色和一個用戶到CATALINA_BASE/conf/tomcat-users.xml文件中。接下來,編輯這個文件,添加一個名為“manager”的角色到該文件中:
同樣需要有一個角色為“manager”的用戶。像已經存在的用戶那樣,添加一個新用戶(改變密碼使其更加安全):
然後重新啟動Tomcat,訪問http://localhost/manager/list,將看到一個很樸素的文本型管理界面,或者訪問http: //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應用。停止一個應用使其無法被訪問,當有用戶嘗試訪問這個被停止的應用時,將 看到一個503的錯誤——“503 - This application is not currently available”。
移除一個web應用,只是指從Tomcat的運行拷貝中刪除了該應用,如果重新啟動Tomcat,被刪除的應用將再次出現(也就是說,移除並不是指從硬碟上刪除)。
有兩個辦法可以在系統中部署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應用的另一種方式是寫一個Context XML片斷文件,然後把該文件拷貝到CATALINA_BASE/webapps目錄下。一個Context片斷並非一個完整的XML文件,而只是一個 context元素,以及對該應用的相應描述。這種片斷文件就像是從server.xml中切取出來的context元素一樣,所以這種片斷被命名為“context片斷”。
舉個例子,如果我們想部署一個名叫MyWebApp.war的應用,該應用使用realm作為訪問控制方式,我們可以使用下面這個片斷:
debug=“0” privileged=“true”>
resourceName=“UserDatabase”/>
把該片斷命名為“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或主機數據。為了測試,為本地IP設置一個IP別名就足夠了,接下來,你需要在server.xml中添加幾行內容,如下:
port=“8080” minProcessors=“5” maxProcessors=“75”
enableLookups=“true” redirectPort=“8443”/>
port=“8443” minProcessors=“5” maxProcessors=“75”
acceptCount=“10” debug=“0” scheme=“https” secure=“true”/>
clientAuth=“false” protocol=“TLS” />
unpackWARs=“true” autoDeploy=“true”>
reloadable=“true” crossContext=“true”>
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方式,彈出一個對話框,要求用戶輸入用戶名和密碼。在這種驗證方法中,所有密碼將被以64位的編碼方式在網路上傳輸。
注意:使用Basic Authentication通常被認為是不安全的,因為它沒有強健的加密方法,除非在客戶端和伺服器端都使用HTTPS或者其他密碼加密碼方式(比如,在一個虛擬私人網路中)。若沒有額外的加密方法,網路管理員將能夠截獲(或濫用)用戶的密碼。但是,如果是剛開始使用Tomcat,或者你想在你的 web應用中測試一下基於容器的安全管理,Basic Authentication還是非常易於設置和使用的。只需要添加和兩個元素到web應用的web.xml文件中,並且在CATALINA_BASE/conf/tomcat-users.xml 文件中添加適當的和即可,然後重新啟動Tomcat。
(Single Sign-On)
一旦設置了realm和驗證的方法,就需要進行實際的用戶登錄處理。一般說來,對用戶而言登錄系統是一件很麻煩的事情,必須盡量減少用戶登錄驗證的 次數。作為預設的情況,當用戶第一次請求受保護的資源時,每一個web應用都會要求用戶登錄。如果運行了多個web應用,並且每個應用都需要進行單獨的 用戶驗證,那這看起來就有點像在用戶搏鬥。用戶們不知道怎樣才能把多個分離的應用整合成一個單獨的系統,所有用戶也就不知道他們需要訪問多少個不 同的應用,只是很迷惑,為什麼總要不停的登錄。
Tomcat 4的“single sign-on”特性允許用戶在訪問同一虛擬主機下所有web應用時,只需登錄一次。為了使用這個功能,只需要在Host上添加一個SingleSignOn Valve元素即可,如下所示:
debug=“0”/>
在Tomcat初始安裝后,server.xml的註釋裡面包括SingleSignOn Valve配置的例子,只需要去掉註釋,即可使用。那麼,任何用戶只要登錄過一個應用,則對於同一虛擬主機下的所有應用同樣有效。
使用single sign-on valve有一些重要的限制:
1> value必須被配置和嵌套在相同的Host元素里,並且所有需要進行單點驗證的web應用(必須通過context元素定義)都位於該Host下。
2> 包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套之外。
3> 不能被context中的realm覆蓋。
4> 使用單點登錄的web應用最好使用一個Tomcat的內置的驗證方式(被定義在web.xml中的
中),這比自定 義的驗證方式強,Tomcat內置的的驗證方式包括basic、digest、form和client-cert。5> 如果你使用單點登錄,還希望集成一個第三方的web應用到你的網站中來,並且這個新的web應用使用它自己的驗證方式,而不使用容器管理安全,那你基本上 就沒招了。用戶每次登錄原來所有應用時需要登錄一次,並且在請求新的第三方應用時還得再登錄一次。
6> 單點登錄需要使用cookies。
一些站點允許個別用戶在伺服器上發布網頁。例如,一所大學的學院可能想給每一位學生一個公共區域,或者是一個ISP希望給一些web空間給他的客戶,但這又不是虛擬主機。在這種情況下,一個典型的方法就是在用戶名前面加一個特殊字元(~),作為每位用戶的網站,比如:
提供兩種方法在主機上映射這些個人網站,主要使用一對特殊的Listener元素。Listener的className屬性應該是 org.apache.catalina.startup.UserConfig,userClass屬性應該是幾個映射類之一。如果電腦系統是 Unix,它將有一個標準的/etc/passwd文件,該文件中的帳號能夠被運行中的Tomcat很容易的讀取,該文件指定了用戶的主目錄,使用 PasswdUserDatabase 映射類。
Tomcat
directoryName=“public_html”
userClass=“org.apache.catalina.startup.PasswdUserDatabase”/>
web文件需要放置在像/home/users/ian/public_html 或者 /users/jbrittain/public_html一樣的目錄下面。當然你也可以改變public_html 到其他任何子目錄下。
實際上,這個用戶目錄根本不一定需要位於用戶主目錄下裡面。如果你沒有一個密碼文件,但你又想把一個用戶名映射到公共的像/home一樣目錄的子目錄裡面,則可以使用HomesUserDatabase類。
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主要是作為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,必須做的幾件事:
1. 把servlets-cgi.renametojar (在CATALINA_HOME/server/lib/目錄下)改名為servlets-cgi.jar。處理CGI的servlet應該位於Tomcat的CLASSPATH下。
2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中,把關於 CGI的那段的註釋去掉(默認情況下,該段位於第241行)。
3. 同樣,在Tomcat的CATALINA_BASE/conf/web.xml文件中,把關於對CGI進行映射的那段的註釋去掉(默認情況下,該段位於第299行)。注意,這段內容指定了HTML鏈接到CGI腳本的訪問方式。
4. 可以把CGI腳本放置在WEB-INF/cgi 目錄下(注意,WEB-INF是一個安全的地方,你可以把一些不想被用戶看見或基於安全考慮不想暴露的文件放在此處),或者也可以把CGI腳本放置在 context下的其他目錄下,並為CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置,且不能與上一步指定的URL重名。
5. 重新啟動Tomcat,你的CGI就可以運行了。
在Tomcat中,CGI程序預設放置在WEB-INF/cgi目錄下,正如前面所提示的那樣,WEB-INF目錄受保護的,通過客戶端的瀏覽器無法窺探 到其中內容,所以對於放置含有密碼或其他敏感信息的CGI腳本而言,這是一個非常好的地方。為了兼容其他伺服器,儘管你也可以把CGI腳本保存在傳統的 /cgi-bin目錄,但要知道,在這些目錄中的文件有可能被網上好奇的衝浪者看到。另外,在
Unix中,請確定運行Tomcat的用戶有執行CGI腳本 的許可權。
在Tomcat 4.1(或更高版本,大概),JSP的編譯由包含在Tomcat裡面的Ant程序控制器直接執行。這聽起來有一點點奇怪,但這正是Ant有意為之的一部 分,有一個API文檔指導開發者在沒有啟動一個新的JVM的情況下,使用Ant。這是使用Ant進行Java開發的一大優勢。另外,這也意味著你現在能夠 在Ant中使用任何javac支持的編譯方式,這裡有一個關於Apache Ant使用手冊的javac page列表。使用起來是容易的,因為你只需要在 元素中定義一個名字叫“compiler”,並且在value中有一個支持編譯的編譯器名字,示例如下:
jsp
org.apache.jasper.servlet.JspServlet
3
當然,給出的編譯器必須已經安裝在你的系統中,並且CLASSPATH可能需要設置,那取決於你選擇的是何種編譯器。
有時,可能想限制對Tomcat web應用的訪問,比如,希望只有指定的主機或IP地址可以訪問應用。這樣一來,就只有那些指定的的客戶端可以訪問服務的內容了。為了實現這種效 果,Tomcat提供了兩個參數供你配置:RemoteHostValve 和RemoteAddrValve。
通過配置這兩個參數,可以讓你過濾來自請求的主機或IP地址,並允許或拒絕哪些主機/IP。與之類似的,在Apache的
httpd文件里有對每個目錄的允許/拒絕指定。
可以把Admin Web application設置成只允許本地訪問,設置如下:
allow=“127.0.0.1” deny=“”/>
如果沒有給出允許主機的指定,那麼與拒絕主機匹配的主機就會被拒絕,除此之外的都是允許的。
/bin:存放windows或Linux平台上啟動和關閉Tomcat的腳本文件
/conf:存放Tomcat伺服器的各種全局配置文件,其中最重要的是server.xml和web.xml
/doc:存放Tomcat文檔
/server:包含三個子目錄:classes、lib和webapps
/server/lib:存放Tomcat伺服器所需的各種JAR文件
/server/webapps:存放Tomcat自帶的兩個WEB應用admin應用和 manager應用
/common/lib:存放Tomcat伺服器以及所有web應用都可以訪問的jar文件
/shared/lib:存放所有web應用都可以訪問的jar文件(但是不能被Tomcat伺服器訪問)
/logs:存放Tomcat執行時的日誌文件
/src:存放Tomcat的源代碼
/webapps:Tomcat的主要Web發布目錄,默認情況下把Web應用文件放於此目錄
/work:存放JSP編譯后產生的class文件
Tomcat是一個世界上廣泛使用的支持jsp和servlets的Web伺服器。它在java上運行時能夠很好地運行並支持Web應用部署。會因為設置不當,造成災難性的後果。在Tomcat默認安裝,Tomcat作為一個系統服務運行,如果沒有將其作為系統服務運行,幾乎所有Web伺服器管理員都是預設地將其以Administrator許可權運行。這兩種方式都允許Java運行時訪問Windows系統下任意文件夾中的任何文件。預設情況下,Java運行時授予安全許可權。當 Tomcat以系統管理員身份或作為系統服務運行時,
Java運行取得了系統用戶或系統管理員所具有的全部許可權。這樣一來,Java運行時就取得了所有文件夾中所有文件的全部許可權。並且Servlets(JSP在運行過程中要轉換成Servlets)取得了同樣的許可權。所以Java代碼可以調用Java SDK中的文件API、列出文件夾中的全部文件、刪除任何文件,最大的危險在於以系統許可權運行一個程序。當任一Servlets含有如下代碼:
b4ae04fd6dYsJkr5 Runtime rt = Runtime.getRuntime();
rt.exec(”c:\SomeDirectory\SomeUnsafePRogram.exe”)
其服務是以system許可權啟動。根據許可權最小安全原則,降低了腳本所獲取的操作本地系統許可權。此操作如下:
新建一個帳戶
1. 用”ITOMCAT_計算機名”建立一個普通用戶
2. 為其設置一個密碼
3. 保證”密碼永不過期”(PassWord Never Expires)被選中
修改Tomcat安裝文件夾的訪問許可權
1. 選定環境參數CATALINA_HOME或TOMCAT_HOME指向的Tomcat安裝文件夾。
2. 為”ITOMCAT_計算機名”用戶賦予讀、寫、執行的訪問許可權。
3. 為”ITOMCAT_計算機名”用戶賦予對WebApps文件夾的只讀訪問許可權。
4. 如果某些Web應用程序需要寫訪問許可權,單獨為其授予對那個文件夾的寫訪問許可權。
Tomcat作為系統服務
1. 到”控制面板”,選擇”管理工具”,然後選擇”服務”。
2. 找到Tomcat:比如Apache Tomcat.exe等等,打開其”屬性”。
3. 選擇其”登錄”(Log)標籤。
4. 選擇”以…登錄”(Log ON Using)選項。
5. 鍵入新建的”ITOMCAT_計算機名”用戶作為用戶名。
6. 輸入密碼。
7. 重啟機器。
在DOS窗口下運行Tomcat步驟
1. 在”開始”按鈕的”運行”框中鍵入
CMD以打開一個DOS窗口。
2. 鍵入”RunAs /user:ITOMCAT_計算機名 CMD.exe”命令。
3. 在詢問”ITOMCAT_計算機名”用戶的密碼時輸入設置的密碼。
4. 這將打開一個新的DOS窗口。
5. 在新開的DOS窗口中,轉換到Tomcat的bin文件夾內。
6. 鍵入”catalina run”命令。
7. 關閉第一個DOS窗口。
設置一下程序
CMD.EXE NET.EXE ATTRIB.EXE At.EXE NET1.EXE FTP.EXE TELNET.EXE COMMAND. COM CAcls.EXEnetstat.exe;system 全部許可權 ,其它用戶無許可權。