安全差不多是迷信。實際上它並不存在，總體上人類的子民也沒有體驗到它。避免危險並不比直面危險更安全。人生或者是一個勇敢的冒險，或者什麼也不是。
——Helen Keller
你是你聲稱的那個人嗎？因爲你 就是 那個人，相對於我的應用程序來說你是誰？
如果你完全地瞭解以上所述，那麼你就知道認證和授權的區別。 當你深入到應用程序的工作方式中去時，這並不簡單。在應用程序的目的和本質方面和你希望使用的支撐體系結構上，有許多問題需要回答。
我們首先看看認證。 我們將採用0、1世界外的例子，而使用人羣互動的例子。 讓我們假定你坐在一個擁擠的咖啡店的桌子旁邊，還有兩把椅子。 你正在讀報紙，沒和其他人打交道，所剩無幾的椅子中的一張就在你的桌子邊。有人端了一杯咖啡來了，問你他能不能坐在你的桌子旁邊，因爲還有一個空位。你說，“當然可以了。如果你願意讀我報紙的話，我已經讀完了運動和娛樂部分。”你此刻正在和一個匿名用戶共享信息。
時間流轉，你啜飲着咖啡，幾乎同時，你和你的同座把眼光從報紙上移開，擡起頭。短暫的尷尬後，陌生人說“感謝你這個座位，今天這裏很擁擠，我需要坐一會。我的名字叫Dean。”Dean 不再是匿名了，你現在知道了他的一些情況。到這裏你需要決定是否信任他，並且就分享一張桌子和報紙來說，知道這個名字就足夠了。你們聊得很愉快。
幾天以後，你到該咖啡店，定了你常喝的咖啡，坐下來讀報紙。幾分鐘後Dean來了，雖然這時候店裏不是很擠，他來到你桌子旁邊，拿了另一種報紙和你分享。你們安靜地坐着讀報，交換了一些看法，彼此更瞭解了。以後，這成了常事兒，只要你們同時都在咖啡店，就一起坐一下，喝咖啡、聊天。在幾周內你們交換個人信息和詳細情況，你知道了Dean的很多信息，所以當你見到他，你和他之間的交往就更個人化，比之Dean是一個完全陌生人的情況，障礙更少。你可能買咖啡，或者Dean 可能再拿起一塊脆餅。你現在從陌生人中知道了Dean，任何時候他和你同桌都會受到歡迎。他被“認證”爲Dean，並且“授權”成爲一個可以和你分享桌子、報紙、和共同聊天的人。
在上面的場景中，你做了好幾個決定：你決定讓別人共享你的空間和信息；進而，你決定把這個決定施用到某個特定的人，並且基於他是誰和他是做什麼的來和他交往。現在來和Web應用比較一下。
在我們的“咖啡店”Web應用中，我們有一個給所有用戶（那些要求坐在桌子邊，分享報紙的陌生人）提供信息的網站。來客給我們一些細節和請求，我們就提供更多信息。
到這裏，我們已經決定了應該具備“安全”級別是，一個名字，因爲該來客並不是要求借一千美金，而我們也不打算借給他。隨着我們決定分享更多信息，我們知道誰是“Dean”了，並且因爲除了他的名字以外，我們知道他的更多情況，我們已經基於他到底是“誰”，來“授權”給他，使他可以分享更多的信息。如果另一個人請求坐在你桌子旁邊，他或者她也得通過和Dean同樣得步驟。
在這章中，我們要揭示對於應用程序的一般和特殊的領域，使用不同的方法去實現安全策略。涉及下列四個方面：
n 一個簡單的登錄/註銷認證策略——這是一個輕量級的安全模型，因爲它安全性比較低，本質上非常普通。這是個非常基本的模型，並不基於容器，並且可以擴展、縮放。
n 把域認證和Struts集成起來——這種更一般性和更具有“工業強度”，基於容器的認證的變化，就如同我們咖啡店的例子是一個會員制情況：任何進來的人都必須根據一個可理解的，被同意的政策，進行認證，然後由管理部門發給胸卡。當Dean請求坐在你桌子旁的時候，你已經知道他的名字，並且確信他是這個咖啡店的會員。
n 防止一組用戶訪問個別的字段——這與第一次和某人見面相似。當你更瞭解他們以後，他們就可以訪問更多信息。即使在你的桌子旁邊坐了許多人，他們可以使用關於回話的上下文的不同信息。
n 防止某些分組的用戶訪問頁面的某些區域——和上面字段級別的方法類似，但這是在頁面級別上。
n 使用Struts保護 Action 避免未授權的訪問。你不想讓咖啡店裏的陌生人在你的杯子裏喝一口，或者在你的甜餅上咬一口！我們已經想出了幾個方法來找到用各種機制來防護 Actions。
本章中的方法給用戶可選擇的方法——從很簡單到相當複雜——控制訪問，保護信息並指導用戶。雖然認證和授權通常是用來實現以防止有害的或者惡意的用戶， 但是，把這些策略看作是“指導”特定用戶到更可用和更相關的信息的方法，這是明智的。
多數情況下用戶不是惡意的，他們只是尋找最有密切關係的信息，這種情況下授權和認證就是服務於此的，可被接受的標準。
7.1 Tomcat 域認證和Struts
Tomcat domain authentication and Struts
◆ 問題
如何把域認證和Struts集成。
◆ 背景
就Web應用來說，安全是個熱門話題。許多企業級的項目把敏感的商業邏輯和處理過程暴露給瀏覽器，這沒有什麼不尋常的。重要的是要防止惡意的或者“錯亂”的用戶訪問到這種信息。
Tomcat 和其他servlet 容器具有很好的在域的級別上認證的系統，該系統可以與數據庫或者普通文件相集成來進行認證用戶並通過分配給用戶的“角色”來建立對不同區域進行訪問的級別。這一系統是Servlet 2.2 規範的一部分：
當前對於servlet容器中的用戶認證，有四個獨立機制。
n HTTP Basic——這是到目前爲止實現的最簡單的認證類型。當瀏覽器向一個受容器保護的區域發出請求的時候，會彈出一個系統級的認證對話框，要求用戶填入一個用戶名和口令（許多基於web的郵件應用程序的用戶會立刻認出這個對話框）。這個對話框是通過從Web容器返回的一個響應“401unauthorized”消息觸發的，該消息從符合HTTP 協議的任何瀏覽器中觸發該對話框。該登錄和口令信息經由Base64認證送回到服務器。一旦這個信息被處理，在Web容器的配置當中設置的訪問級別就會授予給對該頁面的請求以及所有對被該Web容器
保護的頁面的請求。HTTP Basic 極爲便於設置，對它的支持也是普遍的，但是它的外觀是固定的，並且雖然它是Base64編碼的，但是這不是一個安全的加密方法。
n HTTP 表單——把這個認證類型當作是HTTP Basic認證再多一個“友好”的界面。代替系統級別的對話框的是，用戶被顯示一個HTML頁面，帶有登錄和密碼文本框，這包括一個HTML 表單（不屬於Struts），上面帶有特定的表單和字段的名字，以便把收集的信息發送給服務器。如果認證失敗，會顯示一個特定的錯誤頁面。注意很重要的一點是，僅當一個會話是用cookie或者用HTTPS被維護時，該方法才應該被實現。
n HTTPS 客戶端——這是通過一個Secure Sockets Layer （安全的插座層）進行的HTTP認證。所有的數據是使用公鑰密碼轉送的，並且開發者不必知道實現該系統的加密方法。這種方法需要從權威機構頒發的證書，例如VeriSign。更多關於這種認證的信息可以在這章最後的方法中找到。
n HTTP 摘要——這和HTTP Basic 認證方法一樣，只是口令除了被編碼外，還被加密。這提供了比Basic 認證方法更多的安全性，但只在Internet Explorer 5和更新的版本上被支持。並非所有的servlet 容器實現了這個方法，因爲它不是servlet 規範強制要求的。
這個方法將討論Basic 和 基於表單的認證，並把他們集成到Struts框架中。本章的其他方法將於此展開。
一個servlet 容器可以使用用戶名和分配給用戶的角色，把整個應用程序或者應用程序的一部分從用戶那裏保護起來，這個定義是在web 應用程序和servlet 容器的配置文件中創建的。Servlet 容器可以被配置成使用任何類型的可用的持久層， 從一個簡單的XML 文件到一個開源數據庫，或者符合Servlet 安全模型的完全功能的LDAP。在容器或在應用程序級別上，看哪一個適用，通過該應用程序被保護的目錄和頁面，被定義在web.xml文件裏面。如果你打算加固一個或者許多應用程序的安全性，你有一致的和明確的方法可以完成這一任務。
對於Struts, 使用這個方法的安全性，是從該框架外面被訪問的。使用Basic 認證可以使整個應用程序具有安全性。當使用基於表單的機制時，創建不被容器的配置所保護的目錄很重要，因爲任何servlets、圖片、CSS文件、或者HTML頁面不會被顯示，如果他們在應用程序的安全區域裏面，並且，多數情況下，你並不希望他們這樣。
◆ 方法
這裏討論了兩個方法。第一個是HTTP Basic 認證方法，它打開一個提示對話框，上面有登錄和密碼輸入字段，類似圖7.1中所示窗口。
這種方法避開了任何HTML 代碼並且一旦Tomcat 判定了你是誰和你有什麼角色就能立即裝載索引或者指定的歡迎文件。對於我們的第二個方法（HTTP基於表單的認證），你需要使用標準HTML 建立一個登錄和登錄錯誤
頁面，當任何受保護的頁面被一個未被授權用戶請求的時候，登錄頁面被請求，並且顯示指定的歡迎文件。如果該用戶認證失敗，你已經創建的頁面就會被髮送給瀏覽器。
我們必須首先決定我們希望保護什麼。如果你希望保護整個應用程序直到用戶被知道的時候才能被訪問，你必須使用Basic 方法，因爲它使用一個警告框並且不需要HTML 頁面、圖片、或者鏈接來做這一工作。如果我們希望使用表單方法，那麼必須創建兩個簡單的HTML 或者JSP 頁面，並且任何我們想在這些頁面上使用的文件（比如圖片、包含文件等等）也都要被放在一個非保護的區域以備用。
圖7.1 Basic 認證所使用的對話框。
注意
這個方法顯示怎樣使用普通文件認證。更多健壯的應用程序很容易被改造，但這是在Struts 方法之外了。許多資料來源有關於怎樣把特定的數據源配置到容器系統的信息。
第一步，打開在應用程序的Web-INF 目錄下的web.xml文件。找到在</web-app>標籤處的文件末尾並且在它前面插入以下信息（根據你的目錄需要取捨）
Basic 和表單類型兩者都在清單7.1中顯示如下：
清單7.1 在 web.xml 文件中的 Basic 認證
</taglib>
<!--Security for entire application-->
<security-constraint>
<web-resource-collection>
<web-resource-name>My web application</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>applicationuser</role-name>
<!--more roles can be added here -->
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
以上所述方法保護整個目錄，但是沒有定製的登錄或者錯誤屏幕提供。要提供登錄和錯誤屏幕，指定被保護的目錄和文件至關緊要，如同在清單7.2中所示：
清單 7.2 在web.xml 文件中的表單認證清單
</taglib>
<!--Security for application with custom log-in and error pages -->
<security-constraint>
<web-resource-collection>
<web-resource-name>My Custom Page Application</web-resource-name>
<url-pattern>/index.jsp</url-pattern>
<url-pattern>/pages/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
<!--more roles can be added here -->
<role-name>customuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<!--These are the two pages that must be created, if you attach
images, css, or include files it is important that they be in a
non-protected area or your results will not be what you intend -->
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
</web-app>
下一步，讓我們看一下在{Tomcat-目錄}/conf/folder目錄下的server.xml 文件。它被重重地註釋了，但是我們要找到在默認文件中，<engine>和<logger>標籤以後的部分。 對於普通文件域認證，取消該行的註釋：
<Realm className="org.apache.catalina.realm.MemoryRealm"/>
確信其他的任何域標籤被註解掉。注意當使用Tomcat 4.1+時，這個取消註釋的步驟沒有必要，因爲UserDatabaseRealm 是作爲默認激活的。現在已經準備好在tomcat-users .xml 文件中命名你的用戶了，也在{Tomcat-目錄}/conf/folder目錄中。清單7.3 演示了一個例子 tomcat-users.xml 文件，當中爲基於表單的登錄創建了幾個用戶，在上述清單7.2列出的web.xml 文件中有描述：
清單7.3 使用基於表單認證的 tomcat-users.xml 文件
<?xml version="1.0" encoding="utf-8"?>
<tomcat-users>
<role rolename="customuser"/>
<user username="aguy" password="thisPassword" roles="customuser"/>
<!-- you may comma delimit more roles in the "roles" attribute-->
<user username="anotherguy" password="thisGuysPwd" roles="customuser"/>
</tomcat-users>
最後，讓我們看看在清單7.3和7.4中的JSP 登錄和錯誤頁面。這裏使用的HTML 表單中的粗體變量名是被Web容器識別出並且必須被使用的。
清單7.4 用於基於表單的認證 Login.html
<html>
<head>
<title>My Log In Page</title>
</head>
<body>
<form action="j_security_check">
<table style="width: 50%">
<tr>
<td>Username:</td>
<td><input type="text" name="j_username" /></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password" /></td>
</tr>
<td> </td>
<td><input type="submit" value="Login" /></td>
</tr>
</table>
</form>
</body>
</html>
清單7.5 用於處理上述登錄頁面的任何登錄錯誤的error.html 頁面
<html>
<head>
<title>Log in error</title>
</head>
<body>
<p style="font-size: 125%; color: red">Log-In Error</p>
<p>The user name and/or password are incorrect.</p>
<p><a href="login.html">try again</a></p>
</body>
</html>
◆ 討論
也許有這樣一個情況，你僅僅希望保護Action，而不是——或者說除了——保護個別的頁面。這可以通過在<web-resource-collection/>中增加如下xml標籤實現：
<url-pattern>*.do</url-pattern>
這個實現保護了你方法，但是因爲沒有輔助的模式匹配，存在一個安全漏洞，因爲用戶可能會直接敲入一個URL——http://www.mysite.com/pages/myFooPage.jsp 並且可能訪問它。
這是個討論選擇解決這個特別問題的好地方：
1 把所有JSPs放置在WEB-INF之下。
2 用一個限制條件把*.jsp保護起來，限制條件保證沒有用戶擁有使用這些jsp的許可，藉此阻止直接存取jsp。
雖然和用一個數據庫可以完成的事情比起來，單調文件安全的侷限是明顯的，但是它其實信賴於所創建的應用程序的規模和範圍。隨着更多的角色和域被需要，有可能要在某些角色被創建的時候，保護網站的區域以限制這些角色。這在和本方法相關的的方法中加以說明和擴展。
最後，你也許想通過列出在WEB-INF目錄內的一些或者全部JSP文件來使整個網站安全。這種保密類型允許你很容易地使用*.do 安全限制條件，因爲僅有那些你希望保護的文件可以通過Struts Action訪問。請參考“最優方法：使用容器保護資源”中的細節。
◆ 相關
n 7.2—處理註銷
n 7.4—使用容器使動作映射安全
n 7.5—定製動作映射安全
n 7.6—保護頁面上的區域
n 7.7—保護字段
——Helen Keller
你是你聲稱的那個人嗎？因爲你 就是 那個人，相對於我的應用程序來說你是誰？
如果你完全地瞭解以上所述，那麼你就知道認證和授權的區別。 當你深入到應用程序的工作方式中去時，這並不簡單。在應用程序的目的和本質方面和你希望使用的支撐體系結構上，有許多問題需要回答。
我們首先看看認證。 我們將採用0、1世界外的例子，而使用人羣互動的例子。 讓我們假定你坐在一個擁擠的咖啡店的桌子旁邊，還有兩把椅子。 你正在讀報紙，沒和其他人打交道，所剩無幾的椅子中的一張就在你的桌子邊。有人端了一杯咖啡來了，問你他能不能坐在你的桌子旁邊，因爲還有一個空位。你說，“當然可以了。如果你願意讀我報紙的話，我已經讀完了運動和娛樂部分。”你此刻正在和一個匿名用戶共享信息。
時間流轉，你啜飲着咖啡，幾乎同時，你和你的同座把眼光從報紙上移開，擡起頭。短暫的尷尬後，陌生人說“感謝你這個座位，今天這裏很擁擠，我需要坐一會。我的名字叫Dean。”Dean 不再是匿名了，你現在知道了他的一些情況。到這裏你需要決定是否信任他，並且就分享一張桌子和報紙來說，知道這個名字就足夠了。你們聊得很愉快。
幾天以後，你到該咖啡店，定了你常喝的咖啡，坐下來讀報紙。幾分鐘後Dean來了，雖然這時候店裏不是很擠，他來到你桌子旁邊，拿了另一種報紙和你分享。你們安靜地坐着讀報，交換了一些看法，彼此更瞭解了。以後，這成了常事兒，只要你們同時都在咖啡店，就一起坐一下，喝咖啡、聊天。在幾周內你們交換個人信息和詳細情況，你知道了Dean的很多信息，所以當你見到他，你和他之間的交往就更個人化，比之Dean是一個完全陌生人的情況，障礙更少。你可能買咖啡，或者Dean 可能再拿起一塊脆餅。你現在從陌生人中知道了Dean，任何時候他和你同桌都會受到歡迎。他被“認證”爲Dean，並且“授權”成爲一個可以和你分享桌子、報紙、和共同聊天的人。
在上面的場景中，你做了好幾個決定：你決定讓別人共享你的空間和信息；進而，你決定把這個決定施用到某個特定的人，並且基於他是誰和他是做什麼的來和他交往。現在來和Web應用比較一下。
在我們的“咖啡店”Web應用中，我們有一個給所有用戶（那些要求坐在桌子邊，分享報紙的陌生人）提供信息的網站。來客給我們一些細節和請求，我們就提供更多信息。
到這裏，我們已經決定了應該具備“安全”級別是，一個名字，因爲該來客並不是要求借一千美金，而我們也不打算借給他。隨着我們決定分享更多信息，我們知道誰是“Dean”了，並且因爲除了他的名字以外，我們知道他的更多情況，我們已經基於他到底是“誰”，來“授權”給他，使他可以分享更多的信息。如果另一個人請求坐在你桌子旁邊，他或者她也得通過和Dean同樣得步驟。
在這章中，我們要揭示對於應用程序的一般和特殊的領域，使用不同的方法去實現安全策略。涉及下列四個方面：
n 一個簡單的登錄/註銷認證策略——這是一個輕量級的安全模型，因爲它安全性比較低，本質上非常普通。這是個非常基本的模型，並不基於容器，並且可以擴展、縮放。
n 把域認證和Struts集成起來——這種更一般性和更具有“工業強度”，基於容器的認證的變化，就如同我們咖啡店的例子是一個會員制情況：任何進來的人都必須根據一個可理解的，被同意的政策，進行認證，然後由管理部門發給胸卡。當Dean請求坐在你桌子旁的時候，你已經知道他的名字，並且確信他是這個咖啡店的會員。
n 防止一組用戶訪問個別的字段——這與第一次和某人見面相似。當你更瞭解他們以後，他們就可以訪問更多信息。即使在你的桌子旁邊坐了許多人，他們可以使用關於回話的上下文的不同信息。
n 防止某些分組的用戶訪問頁面的某些區域——和上面字段級別的方法類似，但這是在頁面級別上。
n 使用Struts保護 Action 避免未授權的訪問。你不想讓咖啡店裏的陌生人在你的杯子裏喝一口，或者在你的甜餅上咬一口！我們已經想出了幾個方法來找到用各種機制來防護 Actions。
本章中的方法給用戶可選擇的方法——從很簡單到相當複雜——控制訪問，保護信息並指導用戶。雖然認證和授權通常是用來實現以防止有害的或者惡意的用戶， 但是，把這些策略看作是“指導”特定用戶到更可用和更相關的信息的方法，這是明智的。
多數情況下用戶不是惡意的，他們只是尋找最有密切關係的信息，這種情況下授權和認證就是服務於此的，可被接受的標準。
7.1 Tomcat 域認證和Struts
Tomcat domain authentication and Struts
◆ 問題
如何把域認證和Struts集成。
◆ 背景
就Web應用來說，安全是個熱門話題。許多企業級的項目把敏感的商業邏輯和處理過程暴露給瀏覽器，這沒有什麼不尋常的。重要的是要防止惡意的或者“錯亂”的用戶訪問到這種信息。
Tomcat 和其他servlet 容器具有很好的在域的級別上認證的系統，該系統可以與數據庫或者普通文件相集成來進行認證用戶並通過分配給用戶的“角色”來建立對不同區域進行訪問的級別。這一系統是Servlet 2.2 規範的一部分：
當前對於servlet容器中的用戶認證，有四個獨立機制。
n HTTP Basic——這是到目前爲止實現的最簡單的認證類型。當瀏覽器向一個受容器保護的區域發出請求的時候，會彈出一個系統級的認證對話框，要求用戶填入一個用戶名和口令（許多基於web的郵件應用程序的用戶會立刻認出這個對話框）。這個對話框是通過從Web容器返回的一個響應“401unauthorized”消息觸發的，該消息從符合HTTP 協議的任何瀏覽器中觸發該對話框。該登錄和口令信息經由Base64認證送回到服務器。一旦這個信息被處理，在Web容器的配置當中設置的訪問級別就會授予給對該頁面的請求以及所有對被該Web容器
保護的頁面的請求。HTTP Basic 極爲便於設置，對它的支持也是普遍的，但是它的外觀是固定的，並且雖然它是Base64編碼的，但是這不是一個安全的加密方法。
n HTTP 表單——把這個認證類型當作是HTTP Basic認證再多一個“友好”的界面。代替系統級別的對話框的是，用戶被顯示一個HTML頁面，帶有登錄和密碼文本框，這包括一個HTML 表單（不屬於Struts），上面帶有特定的表單和字段的名字，以便把收集的信息發送給服務器。如果認證失敗，會顯示一個特定的錯誤頁面。注意很重要的一點是，僅當一個會話是用cookie或者用HTTPS被維護時，該方法才應該被實現。
n HTTPS 客戶端——這是通過一個Secure Sockets Layer （安全的插座層）進行的HTTP認證。所有的數據是使用公鑰密碼轉送的，並且開發者不必知道實現該系統的加密方法。這種方法需要從權威機構頒發的證書，例如VeriSign。更多關於這種認證的信息可以在這章最後的方法中找到。
n HTTP 摘要——這和HTTP Basic 認證方法一樣，只是口令除了被編碼外，還被加密。這提供了比Basic 認證方法更多的安全性，但只在Internet Explorer 5和更新的版本上被支持。並非所有的servlet 容器實現了這個方法，因爲它不是servlet 規範強制要求的。
這個方法將討論Basic 和 基於表單的認證，並把他們集成到Struts框架中。本章的其他方法將於此展開。
一個servlet 容器可以使用用戶名和分配給用戶的角色，把整個應用程序或者應用程序的一部分從用戶那裏保護起來，這個定義是在web 應用程序和servlet 容器的配置文件中創建的。Servlet 容器可以被配置成使用任何類型的可用的持久層， 從一個簡單的XML 文件到一個開源數據庫，或者符合Servlet 安全模型的完全功能的LDAP。在容器或在應用程序級別上，看哪一個適用，通過該應用程序被保護的目錄和頁面，被定義在web.xml文件裏面。如果你打算加固一個或者許多應用程序的安全性，你有一致的和明確的方法可以完成這一任務。
對於Struts, 使用這個方法的安全性，是從該框架外面被訪問的。使用Basic 認證可以使整個應用程序具有安全性。當使用基於表單的機制時，創建不被容器的配置所保護的目錄很重要，因爲任何servlets、圖片、CSS文件、或者HTML頁面不會被顯示，如果他們在應用程序的安全區域裏面，並且，多數情況下，你並不希望他們這樣。
◆ 方法
這裏討論了兩個方法。第一個是HTTP Basic 認證方法，它打開一個提示對話框，上面有登錄和密碼輸入字段，類似圖7.1中所示窗口。
這種方法避開了任何HTML 代碼並且一旦Tomcat 判定了你是誰和你有什麼角色就能立即裝載索引或者指定的歡迎文件。對於我們的第二個方法（HTTP基於表單的認證），你需要使用標準HTML 建立一個登錄和登錄錯誤
頁面，當任何受保護的頁面被一個未被授權用戶請求的時候，登錄頁面被請求，並且顯示指定的歡迎文件。如果該用戶認證失敗，你已經創建的頁面就會被髮送給瀏覽器。
我們必須首先決定我們希望保護什麼。如果你希望保護整個應用程序直到用戶被知道的時候才能被訪問，你必須使用Basic 方法，因爲它使用一個警告框並且不需要HTML 頁面、圖片、或者鏈接來做這一工作。如果我們希望使用表單方法，那麼必須創建兩個簡單的HTML 或者JSP 頁面，並且任何我們想在這些頁面上使用的文件（比如圖片、包含文件等等）也都要被放在一個非保護的區域以備用。
圖7.1 Basic 認證所使用的對話框。
注意
這個方法顯示怎樣使用普通文件認證。更多健壯的應用程序很容易被改造，但這是在Struts 方法之外了。許多資料來源有關於怎樣把特定的數據源配置到容器系統的信息。
第一步，打開在應用程序的Web-INF 目錄下的web.xml文件。找到在</web-app>標籤處的文件末尾並且在它前面插入以下信息（根據你的目錄需要取捨）
Basic 和表單類型兩者都在清單7.1中顯示如下：
清單7.1 在 web.xml 文件中的 Basic 認證
</taglib>
<!--Security for entire application-->
<security-constraint>
<web-resource-collection>
<web-resource-name>My web application</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>applicationuser</role-name>
<!--more roles can be added here -->
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
以上所述方法保護整個目錄，但是沒有定製的登錄或者錯誤屏幕提供。要提供登錄和錯誤屏幕，指定被保護的目錄和文件至關緊要，如同在清單7.2中所示：
清單 7.2 在web.xml 文件中的表單認證清單
</taglib>
<!--Security for application with custom log-in and error pages -->
<security-constraint>
<web-resource-collection>
<web-resource-name>My Custom Page Application</web-resource-name>
<url-pattern>/index.jsp</url-pattern>
<url-pattern>/pages/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
<!--more roles can be added here -->
<role-name>customuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<!--These are the two pages that must be created, if you attach
images, css, or include files it is important that they be in a
non-protected area or your results will not be what you intend -->
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
</web-app>
下一步，讓我們看一下在{Tomcat-目錄}/conf/folder目錄下的server.xml 文件。它被重重地註釋了，但是我們要找到在默認文件中，<engine>和<logger>標籤以後的部分。 對於普通文件域認證，取消該行的註釋：
<Realm className="org.apache.catalina.realm.MemoryRealm"/>
確信其他的任何域標籤被註解掉。注意當使用Tomcat 4.1+時，這個取消註釋的步驟沒有必要，因爲UserDatabaseRealm 是作爲默認激活的。現在已經準備好在tomcat-users .xml 文件中命名你的用戶了，也在{Tomcat-目錄}/conf/folder目錄中。清單7.3 演示了一個例子 tomcat-users.xml 文件，當中爲基於表單的登錄創建了幾個用戶，在上述清單7.2列出的web.xml 文件中有描述：
清單7.3 使用基於表單認證的 tomcat-users.xml 文件
<?xml version="1.0" encoding="utf-8"?>
<tomcat-users>
<role rolename="customuser"/>
<user username="aguy" password="thisPassword" roles="customuser"/>
<!-- you may comma delimit more roles in the "roles" attribute-->
<user username="anotherguy" password="thisGuysPwd" roles="customuser"/>
</tomcat-users>
最後，讓我們看看在清單7.3和7.4中的JSP 登錄和錯誤頁面。這裏使用的HTML 表單中的粗體變量名是被Web容器識別出並且必須被使用的。
清單7.4 用於基於表單的認證 Login.html
<html>
<head>
<title>My Log In Page</title>
</head>
<body>
<form action="j_security_check">
<table style="width: 50%">
<tr>
<td>Username:</td>
<td><input type="text" name="j_username" /></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password" /></td>
</tr>
<td> </td>
<td><input type="submit" value="Login" /></td>
</tr>
</table>
</form>
</body>
</html>
清單7.5 用於處理上述登錄頁面的任何登錄錯誤的error.html 頁面
<html>
<head>
<title>Log in error</title>
</head>
<body>
<p style="font-size: 125%; color: red">Log-In Error</p>
<p>The user name and/or password are incorrect.</p>
<p><a href="login.html">try again</a></p>
</body>
</html>
◆ 討論
也許有這樣一個情況，你僅僅希望保護Action，而不是——或者說除了——保護個別的頁面。這可以通過在<web-resource-collection/>中增加如下xml標籤實現：
<url-pattern>*.do</url-pattern>
這個實現保護了你方法，但是因爲沒有輔助的模式匹配，存在一個安全漏洞，因爲用戶可能會直接敲入一個URL——http://www.mysite.com/pages/myFooPage.jsp 並且可能訪問它。
這是個討論選擇解決這個特別問題的好地方：
1 把所有JSPs放置在WEB-INF之下。
2 用一個限制條件把*.jsp保護起來，限制條件保證沒有用戶擁有使用這些jsp的許可，藉此阻止直接存取jsp。
雖然和用一個數據庫可以完成的事情比起來，單調文件安全的侷限是明顯的，但是它其實信賴於所創建的應用程序的規模和範圍。隨着更多的角色和域被需要，有可能要在某些角色被創建的時候，保護網站的區域以限制這些角色。這在和本方法相關的的方法中加以說明和擴展。
最後，你也許想通過列出在WEB-INF目錄內的一些或者全部JSP文件來使整個網站安全。這種保密類型允許你很容易地使用*.do 安全限制條件，因爲僅有那些你希望保護的文件可以通過Struts Action訪問。請參考“最優方法：使用容器保護資源”中的細節。
◆ 相關
n 7.2—處理註銷
n 7.4—使用容器使動作映射安全
n 7.5—定製動作映射安全
n 7.6—保護頁面上的區域
n 7.7—保護字段
