JAVA流通橋

Servlet2.3中文文檔(第11,12,13章)

                                                  第十一章 請求到servlet的映射
11.1 URI的使用
web容器根據客戶端的請求決定要調用的資源。
URL路徑映射規則是第一個匹配成功就不再匹配了。
1）引擎將盡力為每一個請求一個servlet的路徑匹配一個servlet
2）引擎將遞歸的匹配最長的路徑前綴（在一個目錄樹中）
3）如果在URL路徑中的最后一節有擴展名（例如：.jsp），則servlet引擎將會匹配一個適當的servlet獲
取請求對象
4）如果沒有一個servlet能夠匹配請求，引擎將用一個適當的資源來處理該請求。如：在應用中配置了
默認的servlet，就會被用來處理匹配不到資源的請求。
11.2 匹配規則
在web應用描述文件中，匹配的定義如下：
.以'/'開始，以'/*'為結尾的字符串,用作路徑匹配
.以'*.'開始的字符串，用作擴展名匹配
.包含'/'字符串，定義一個默認的servlet。如匹配的servlet路徑是請求URI路徑的最小上下文路徑，路經
的info為空。
.其它的字符串用作精確的匹配。
11.2.1 絕對匹配
servlet引擎能夠匹配任何精確的資源，如后綴為*.jsp的匹配，引擎中有JSP引擎的話，就會把所有的JSP
頁面和與之對象的資源相匹配。
11.2.2 匹配的例子：
path pattern servlet
/foo/bar/* servlet1
/baz/* servlet2
/catalog servlet3
*.bop servlet4
incoming path servlet handling request
/foo/bar/index.html servlet1
/foo/bar/index.bop servlet1
/baz servlet2
/baz/index.html servlet2
/catalog servlet3
/catalog/racecar.bop servlet4
/index.bop servlet4
第十二章 安全
12.1介紹
web應用的資源能夠被很多的用戶訪問，這些資源經常沒有保護的暴露在網絡中，因此一個穩定的web
應用需要一個安全的環境。
提高安全性有以下的幾個方面：
.認證：訪問一個實例前需要一個特殊的ID進行授權認證后才能訪問該實例
.資源的訪問控制：一些機密資源或局部資源只限制給某些用戶或程序使用。
.數據完整性：在傳輸過程中數據不能被意外的改變。
.機密性：確定信息只能被授權過的用戶使用。
12.2 公共安全
安全性聲明是指表明應用是有安全結構的；包括權限、訪問控制、認證。在web應用中部署描述是安全
聲明的主要工具。
開發者應該為應用運行時配一個邏輯安全策略，在運行時中，servlet引擎用這個安全策略去驗證授權請
求。
安全模塊應該適用web應用的靜態內容，當servlet用RequestDispatcher調用一個靜態資源或servlet用
forward或include,時安全模塊不適用。
12.3 程序級安全
當應用的安全模塊不能充分的表明安全時程序安全就可以被使用。
程序安全有以下部分組成：
HttpServletRequest接口：
.getRemoteUser
.isUserInRole
.getUserPrincipal
getRemoteUser方法返回客戶端用戶的名稱，用于授權。
isUserInRole方法判斷遠程用戶是否在一個安全的角色內。
getUserPrincipal方法返回一個java.security.Principal對象，表明當前用戶的主要名稱。這個API允許
servlet根據這個信息處理一些業務邏輯。
如果用戶沒有授權，getRemoteUser返回null，isUserInRole返回false，getUserPrincipal返回null。
isUserInRole以一個role-name為參數。一個security-role-ref元素為在部署描述文件中定義，role-name
子元素包含角色名稱。Security-role包含一個子元素role-link,role-link的value值是客戶端用戶將匹配的
安全角色。當用isUserInRole時引擎將調用security-role-ref到security-role的匹配。
舉個例子：
<security-role-ref>
<role-name>FOO</role-name>
<role-link>manager</role-link>
</security-role-ref>
當一個用戶屬于“manager”角色是調用isUsesrInRole("FOO")返回true
如果匹配一個security-role元素的security-role-ref沒有被定義，引擎必須找出一個與security-role
列表不同的roel-name元素作為web應用默認的安全角色。但默認的安全角色限制了變換角色名
稱不需要重新編譯的機動性。
12.4 角色
一個安全角色是一組用戶的邏輯名稱。當應用發布時，角色就部署在web應用的運行時環境中
了。在基于安全屬性的請求到來時，servlet引擎就會執行公共安全或程序級安全。安全請求在以
下的一些情況中會產生：
1）開發者給用戶群配置了一個安全角色。
2）開發者把一個安全角色配置給一個安全域中的一個主要名稱。
12.5 驗證
web客戶端可以用以下的一些機制驗證用戶：
.HTTP Basic Authentication
.HTTP Digest Authentication
.HTTPS Client Authentication
.Form Based Authentication
12.5.1 HTTP Basic Authentication
HTTP Basic Authentication是基于用戶名和密碼的驗證機制，是在HTTP/1.0規范中定義的。web
服務要求客戶端驗證用戶，web服務用一個realm字符串作為請求的一部分，用戶通過這個realm
字符串被驗證。realm字符串不會和任何安全域相關聯?？蛻舳双@得用戶名稱和密碼發送到服務
端。然后服務端用一個特殊的realm去驗證該用戶。
Basic Authentication 不是安全的驗證協議。用戶的密碼是用base64編碼的，服務端是不能夠識
別的。一些附加的安全措施可以被使用，這些協議有：HTTPS安全傳輸協議或網絡安全標準（如
IPSEC協議、VPN策略）。
12.5.2 HTTP Digest Authentication
和HTTP Basic Authentication一樣，HTTP Digest Authentication 也是驗證用戶名和密碼的。然而
這種驗證是把密碼加密傳輸的，要比Basic Authentication的base64編碼要安全的多。Digest
Authentication 沒有被廣泛的運用，建議servlet引擎支持這種驗證，但不是必須的。
12.5.3 Form Based Authentication
web應用部署描述文件包含登陸表單和錯誤頁面。登陸表單必須包含用戶名和用戶密碼字段，這
兩個字段必須以j_username和j_password命名。當一個用戶要訪問一個被保護的資源時，引擎就
會驗證該用戶信息，如果該用戶驗證通過就會調用保護的資源，如果沒有驗證通過，以下的步驟
就會發生：
1）登陸表單被送到客戶端，啟動這個驗證的URL路徑將被引擎保存。
2）用戶被要求填寫用戶名和密碼
3）客戶端重新post表單到服務端
4）引擎嘗試著重新去驗證該用戶的信息
5）如果驗證有失敗，響應被設置為401的錯誤頁面將被返回
6）如果驗證成功，如果該訪問的資源在一個授權角色中，將進一步驗證。
7）如果用戶是授權用戶，客戶端將用保存的URL路徑重新定向到訪問的資源。
發送到驗證失敗的用戶的錯誤頁面包含了失敗的信息。
Form Based Authentication 和 Basic Authentication 有一樣的弊端，密碼是用簡單的文本傳輸
的，不能夠被服務端驗證。附加的一些協議可以增強這部分功能。如HTTPS傳輸協議，或網路安
全標準（如IPSEC協議或VPN策略）。
12.5.3.1 登陸表單的一些注意事項
登陸的表單和跟蹤session的URL實現上是有限制的。
登陸表單只能在cookies或SSL跟蹤session的方式下才能使用。
登陸表單要進行驗證的話，表單的action就必須為j_security_check。這個約束使得登陸表單訪問
的資源沒有問題，也避免了把表單外的字段提交進請求中。
在HTML頁面中登陸表單的一個例子如下：
<form method="POST" action="j_security_check" >
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>
當登陸表單因為HTTP請求被調用時，原始的請求參數必須被引擎存儲，在驗證成功后重新定向
請求的資源。
如果用登陸表單的用戶被驗證通過，創建了一個session,當session超時或調用了失效方法，使得
登陸者推出了。后續來的請求就必須重新對用戶進行驗證。
12.5.4 HTTPS Client Authentication
用HTTPS驗證用戶是很強的驗證機制。這個驗證需要用戶擁有一個公共鑰匙（PKC）。servlet引
擎不需要支持HTTPS協議。
12.6 驗證信息的跟蹤
基本的身份驗證實在運行時環境中進行的：
1）確認一個登陸驗證機制或策略已經配置在web應用中。
2）把需驗證的信息發往一個容器中的所有應用。
3）當一個安全域被刪除時，用戶的請求就需要重新驗證。

posted on 2007-08-20 17:52 朱巖 閱讀(374) 評論(0)  編輯  收藏 所屬分類: servlet文章