摘要
在一個有密碼保護的Web應用當中，正確妥善的處理用戶退出過程并不僅僅只需要調(diào)用HttpSession對象的invalidate()方法，因為現(xiàn)在大部分瀏覽器上都有后退(Back)和前進(Forward)按鈕，允許用戶后退或前進到一個頁面。
在用戶退出一個Web應用之后，如果按了后退按鈕，瀏覽器把緩存中的頁面呈現(xiàn)給用戶，這會使用戶產(chǎn)生疑惑，他們會開始擔心他們的個人數(shù)據(jù)是否安全。
實際上，許多Web應用會彈出一個頁面，警告用戶退出時關閉整個瀏覽器，以此來阻止用戶點擊后退按鈕。還有一些使用JavaScript，但在某些客戶端瀏覽器中這卻不一定起作用。這些解決方案大多數(shù)實現(xiàn)都很笨拙，且不能保證在任何情況下都100%有效，同時，它還要求用戶有一定的操作經(jīng)驗。
這篇文章以簡單的程序示例闡述了正確解決用戶退出問題的方案。作者Kevin Le首先描述了一
一. JSP samples
為了更為有效地向您說明這個解決方案，本文將從展示一個Web應用logoutSampleJSP1中碰到的問題開始。這個示例代表了許多沒有正確解決退出過程的Web應用。logoutSampleJSP1包含一下JSP頁面：login.jsp, home.jsp, secure1.jsp, secure2.jsp, logout.jsp, loginAction.jsp, 和 logoutAction.jsp。其中頁面home.jsp, secure1.jsp, secure2.jsp, 和 logout.jsp是不允許未經(jīng)認證的用戶訪問的，也就是說，這些頁面包含了重要信息，在用戶登陸之前或者退出之后都不應該顯示在瀏覽器中。 login.jsp頁面包含了用于用戶輸入用戶名和密碼的form。logout.jsp頁面包含了要求用戶確認是否退出的form。 loginAction.jsp和logoutAction.jsp作為控制器分別包含了登陸和退出動作的代碼。
第二個Web示例應用logoutSampleJSP2展示了如何糾正示例logoutSampleJSP1中的問題。但是第二個示例logoutSampleJSP2自身也是有問題的。在特定情況下，退出問題依然存在。
第三個Web示例應用logoutSampleJSP3對logoutSampleJSP2進行了改進，比較妥善地解決了退出問題。
最后一個Web示例logoutSampleStruts展示了JakartaStruts如何優(yōu)雅地解決退出問題。
注意：本文所附示例在最新版本的Microsoft Internet Explorer (IE), Netscape Navigator, Mozilla, FireFox和Avant瀏覽器上測試通過。
二. Login action
Brian Pontarelli的經(jīng)典文章 《J2EE Security: Container Versus Custom》討論了不同的J2EE認證方法。文章同時指出，HTTP協(xié)議和基于form的認證方法并不能提供處理用戶退出問題的機制。因此，解決方法便是引入用戶自定義的安全實現(xiàn)機制，這就提供了更大的靈活性。
在用戶自定義的認證方法中，普遍采用的方法是從用戶提交的form中獲得用戶輸入的認證信息，然后到諸如LDAP (lightweight directory access protocol)或關系數(shù)據(jù)庫(relational database management system, RDBMS)的安全域中進行認證。如果用戶提供的認證信息是有效的，登陸動作在HttpSession對象中保存某個對象。HttpSession存在著保存的對象則表示用戶已經(jīng)登陸到Web應用當中。為了方便起見，本文所附的示例只在HttpSession中保存一個用戶名以表明用戶已經(jīng)登陸。清單1是從loginAction.jsp頁面中節(jié)選的一段代碼以此講解登陸動作：
Listing 1
//...
//initialize RequestDispatcher object; set forward to home page by default
RequestDispatcher rd = request.getRequestDispatcher( "home.jsp" );
//Prepare connection and statement
rs = stmt.executeQuery( "select password from USER where userName = '" + userName + "'" );
if (rs.next()) {
//Query only returns 1 record in the result set;
//Only 1 password per userName which is also the primary key
if (rs.getString( "password" ).equals(password)) { //If valid password
session.setAttribute( "User" , userName); //Saves username string in the session object
}
else { //Password does not match, i.e., invalid user password
request.setAttribute( "Error" , "Invalid password." );
rd = request.getRequestDispatcher( "login.jsp" );
}
} //No record in the result set, i.e., invalid username
else {
request.setAttribute( "Error" , "Invalid user name." );
rd = request.getRequestDispatcher( "login.jsp" );
}
}
//As a controller, loginAction.jsp finally either forwards to "login.jsp" or "home.jsp"
rd.forward(request, response);
//...
本文當中所附Web應用示例均以關系型數(shù)據(jù)庫作為安全域，但本問所講述的內(nèi)容同樣適用于其他任何類型的安全域。
三. Logout action
退出動作包含刪除用戶名以及調(diào)用用戶的HttpSession對象的invalidate()方法。清單2是從loginoutAction.jsp中節(jié)選的一段代碼，以此說明退出動作：
Listing 2
//...
session.removeAttribute( "User" );
session.invalidate();
//...
四. 阻止未經(jīng)認證訪問受保護的JSP頁面
從提交的form中獲取用戶提交的認證信息并經(jīng)過驗證后，登陸動作僅僅在HttpSession對象中寫入一個用戶名。退出動作則剛好相反，它從 HttpSession中刪除用戶名并調(diào)用HttpSession對象的invalidate()方法。為了使登陸和退出動作真正發(fā)揮作用，所有受保護的 JSP頁面必須首先驗證HttpSession中包含的用戶名，以便確認用戶當前是否已經(jīng)登陸。如果HttpSession中包含了用戶名，就說明用戶已經(jīng)登陸，Web應用會將剩余的JSP頁中的動態(tài)內(nèi)容發(fā)送給瀏覽器。否則，JSP頁將跳轉(zhuǎn)到登陸頁面，login.jsp。頁面home.jsp, secure1.jsp, secure2.jsp和 logout.jsp均包含清單3中的代碼段：
Listing 3
//...
String userName = (String) session.getAttribute( "User" );
if (null == userName) {
request.setAttribute( "Error" , "Session has ended. Please login." );
RequestDispatcher rd = request.getRequestDispatcher( "login.jsp" );
rd.forward(request, response);
}
//...
//Allow the rest of the dynamic content in this JSP to be served to the browser
//...
在這個代碼段中，程序從HttpSession中檢索username字符串。如果username字符串為空，Web應用則自動中止執(zhí)行當前頁面并跳轉(zhuǎn)到登陸頁，同時給出錯誤信息“Session has ended. Please log in.”；如果不為空，Web應用繼續(xù)執(zhí)行，把剩余的頁面提供給用戶，從而使JSP頁面的動態(tài)內(nèi)容成為服務對象。
五.運行l(wèi)ogoutSampleJSP1
運行l(wèi)ogoutSampleJSP1將會出現(xiàn)如下幾種情形：
• 如果用戶沒有登陸，Web應用將會正確中止受保護頁面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中動態(tài)內(nèi)容的執(zhí)行。也就是說，假如用戶并沒有登陸，但是在瀏覽器地址欄中直接敲入受保護JSP頁的地址試圖訪問，Web應用將自動跳轉(zhuǎn)到登陸頁面，同時顯示錯誤信息“Session has ended.Please log in.”
• 同樣的，當一個用戶已經(jīng)退出，Web應用將會正確中止受保護頁面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中動態(tài)內(nèi)容的執(zhí)行。也就是說，用戶退出以后，如果在瀏覽器地址欄中直接敲入受保護JSP頁的地址試圖訪問， Web應用將自動跳轉(zhuǎn)到登陸頁面，同時顯示錯誤信息“Session has ended.Please log in.”
• 用戶退出以后，如果點擊瀏覽器上的后退按鈕返回到先前的頁面，Web應用將不能正確保護受保護的JSP頁面——在Session銷毀后（用戶退出）受保護的JSP頁會重新顯示在瀏覽器中。然而，點擊該頁面上的任何鏈接，Web應用都會跳轉(zhuǎn)到登陸頁面，同時顯示錯誤信息“Session has ended.Please log in.”
六. 阻止瀏覽器緩存
上述問題的根源就在于現(xiàn)代大部分瀏覽器都有一個后退按鈕。當點擊后退按鈕時，默認情況下瀏覽器不會從Web服務器上重新獲取頁面，而是簡單的從瀏覽器緩存中重新載入頁面。這個問題并不僅限于基于 Java(JSP/servlets/Struts) 的Web應用當中，在基于PHP (Hypertext Preprocessor)、ASP、(Active Server Pages)、和.NET的Web應用中也同樣存在。
在用戶點擊后退按鈕之后，瀏覽器到Web服務器（一般來說）或者應用服務器（在java的情況下）再從服務器到瀏覽器這樣通常意義上的HTTP回路并沒有建立。僅僅只是用戶，瀏覽器和緩存之間進行了交互。所以即使受保護的JSP頁面，例如home.jsp, secure1.jsp, secure2.jsp和logout.jsp包含了清單3上的代碼，當點擊后退按鈕時，這些代碼也永遠不會執(zhí)行的。
緩存的好壞，真是仁者見仁智者見智。緩存事實上的確提供了一些便利，但這些便利通常只存在于靜態(tài)的HTML頁面或基于圖形或影像的頁面。而另一方面，Web應用通常是面向數(shù)據(jù)的。由于Web應用中的數(shù)據(jù)頻繁變更，所以與為了節(jié)省時間從緩存中讀取并顯示過期的數(shù)據(jù)相比，提供最新的數(shù)據(jù)顯得尤為重要！
幸運的是，HTTP頭信息“Expires”和“Cache-Control”為應用程序服務器提供了一個控制瀏覽器和代理服務器上緩存的機制。 HTTP頭信息Expires告訴代理服務器它的緩存頁面何時將過期。HTTP1.1規(guī)范中新定義的頭信息Cache-Control在Web應用當中可以通知瀏覽器不緩存任何頁面。當點擊后退按鈕時，瀏覽器發(fā)送Http請求道應用服務器以便獲取該頁面的最新拷貝。如下是使用Cache-Control的基本方法：
• no-cache:強制緩存從服務器上獲取該頁面的最新拷貝
• no-store: 在任何情況下緩存不保存該頁面
HTTP1.0規(guī)范中的Pragma:no-cache等同于HTTP1.1規(guī)范中的Cache-Control:no-cache，同樣可以包含在頭信息中。
通過使用HTTP頭信息的cache控制，第二個示例應用logoutSampleJSP2解決了logoutSampleJSP1的問題。 logoutSampleJSP2與logoutSampleJSP1不同表現(xiàn)在如下代碼段中，這一代碼段加入進所有受保護的頁面中：
//...
response.setHeader( "Cache-Control" , "no-cache" );
//Forces caches to obtain a new copy of the page from the origin server
response.setHeader( "Cache-Control" , "no-store" );
//Directs caches not to store the page under any circumstance
response.setDateHeader( "Expires" , 0);
//Causes the proxy cache to see the page as "stale"
response.setHeader( "Pragma" , "no-cache" );
//HTTP 1.0 backward compatibility
String userName = (String) session.getAttribute( "User" );
if (null == userName) {
request.setAttribute( "Error" , "Session has ended. Please login." );
RequestDispatcher rd = request.getRequestDispatcher( "login.jsp" );
rd.forward(request, response);
}
//...
通過設置頭信息和檢查HttpSession對象中的用戶名來確保瀏覽器不會緩存JSP頁面。同時，如果用戶未登陸，JSP頁面的動態(tài)內(nèi)容不會發(fā)送到瀏覽器，取而代之的將是登陸頁面login.jsp。
七. 運行l(wèi)ogoutSampleJSP2
運行Web示例應用logoutSampleJSP2后將會看到如下結(jié)果：
• 當用戶退出后試圖點擊后退按鈕，瀏覽器不會重新顯示受保護的頁面，它只會顯示登陸頁login.jsp同時給出提示信息Session has ended. Please log in.
• 然而，當按了后退按鈕返回的頁是處理用戶提交數(shù)據(jù)的頁面時，IE和Avant瀏覽器將彈出如下信息提示：
警告：頁面已過期
The page you requested was created using information you submitted in a form. This page is no longer available. As a security divcaution, Internet Explorer does not automatically resubmit your information for you.
Mozilla和FireFox瀏覽器將會顯示一個對話框，提示信息如下：
The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action from the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel.
在IE和Avant瀏覽器中選擇刷新或者在Mozilla和 FireFox瀏覽器中選擇重新發(fā)送數(shù)據(jù)后，前一個JSP頁面將重新顯示在瀏覽器中。顯然的，這病不是我們所想看到的因為它違背了logout動作的目的。發(fā)生這一現(xiàn)象時，很可能是一個惡意用戶在嘗試獲取其他用戶的數(shù)據(jù)。然而，這個問題僅僅出現(xiàn)在點擊后退按鈕后，瀏覽器返回到一個處理POST請求的頁面。
八. 記錄最后登陸時間
上述問題的發(fā)生是因為瀏覽器重新提交了其緩存中的數(shù)據(jù)。這本文的例子中，數(shù)據(jù)包含了用戶名和密碼。盡管IE瀏覽器給出了安全警告信息，但事實上瀏覽器此時起到了負面作用。
為了解決logoutSampleJSP2中出現(xiàn)的問題，logoutSampleJSP3的login.jsp除了包含username和 password的之外，還增加了一個稱作lastLogon的隱藏表單域，此表單域?qū)討B(tài)的被初始化為一個long型值。這個long型值是通過調(diào)用 System.currentTimeMillis()獲取到的自1970年1月1日以來的毫秒數(shù)。當login.jsp中的form提交時， loginAction.jsp首先將隱藏域中的值與用戶數(shù)據(jù)庫中的lastLogon值進行比較。只有當lastLogon表單域中的值大于數(shù)據(jù)庫中的值時Web應用才認為這是個有效的登陸。
為了驗證登陸，數(shù)據(jù)庫中l(wèi)astLogon字段必須用表單中的lastLogon值進行更新。上例中，當瀏覽器重復提交緩存中的數(shù)據(jù)時，表單中的lastLogon值不比數(shù)據(jù)庫中的lastLogon值大，因此，loginAction將跳轉(zhuǎn)到login.jsp頁面，并顯示如下錯誤信息“Session has ended.Please log in.”清單5是loginAction中節(jié)選的代碼段：
清單5
//...
RequestDispatcher rd = request.getRequestDispatcher( "home.jsp" );
//Forward to homepage by default
//...
if (rs.getString( "password" ).equals(password)) { //If valid password
long lastLogonDB = rs.getLong( "lastLogon" );
if (lastLogonForm ＞ lastLogonDB) {
session.setAttribute( "User" , userName);
//Saves username string in the session object
stmt.executeUpdate( "update USER set lastLogon= " + lastLogonForm + "
where userName = '" + userName + "'" );
}
else {
request.setAttribute( "Error" , "Session has ended. Please login." );
rd = request.getRequestDispatcher( "login.jsp" ); }
}
else { //Password does not match, i.e., invalid user password
request.setAttribute( "Error" , "Invalid password." );
rd = request.getRequestDispatcher( "login.jsp" );
}
//...
rd.forward(request, response);
//...
為了實現(xiàn)上述方法，你必須記錄每個用戶的最后登陸時間。對于采用關系型數(shù)據(jù)庫安全域來說，這點可以可以通過在某個表中加上lastLogin字段輕松實現(xiàn)。雖然對LDAP以及其他的安全域來說需要稍微動下腦筋，但最后登陸方法很顯然是可以實現(xiàn)的。
表示最后登陸時間的方法有很多。示例logoutSampleJSP3利用了自1970年1月1日以來的毫秒數(shù)。這個方法即使在許多人在不同瀏覽器中用一個用戶賬號登陸時也是可行的。
九. 運行l(wèi)ogoutSampleJSP3
運行示例logoutSampleJSP3將展示如何正確處理退出問題。一旦用戶退出，點擊瀏覽器上的后退按鈕在任何情況下都不會在瀏覽器中顯示受保護的JSP頁面。這個示例展示了如何正確處理退出問題而不需要對用戶進行額外的培訓。
為了使代碼更簡練有效，一些冗余的代碼可以剔除。一種途徑就是把清單4中的代碼寫到一個單獨的JSP頁中，其他JSP頁面可以通過標簽 進行使用 。
十. Struts框架下的退出實現(xiàn)
與直接使用JSP或JSP/servlets進行Web應用開發(fā)相比，另一個更好的可選方案是使用Struts。對于一個基于Struts的Web應用來說，添加一個處理退出問題的框架可以優(yōu)雅地不費氣力的實現(xiàn)。這歸功于Struts是采用MVC設計模式的，因此可以將模型和視圖代碼清晰的分離。另外， Java是一個面向?qū)ο蟮恼Z言，支持繼承，可以比JSP中的腳本更為容易地實現(xiàn)代碼重用。對于Struts來說，清單4中的代碼可以從JSP頁面中移植到 Action類的execute()方法中。
此外，我們還可以定義一個繼承Struts Action類的Action基類，其execute()方法中包含了類似清單4中的代碼。通過繼承，其他Action類可以繼承基本類中的通用邏輯來設置HTTP頭信息以及檢索HttpSession對象中的username字符串。這個Action基類是一個抽象類并定義了一個抽象方法 executeAction()。所有繼承自Action基類的子類都必須實現(xiàn)exectuteAction()方法而不是覆蓋它。通過繼承這一機制，所有繼承自Action基類的子類都不必再擔心退出代碼接口。（plumbing實在不知道怎么翻譯了，^+^，高手幫幫忙??！原文：With this inheritance hierarchy in place, all of the base Action's subclasses no longer need to worry about any plumbing logout code.）。他們將只包含正常的業(yè)務邏輯代碼。清單6是基類的部分代碼：
清單6
publicabstractclass BaseAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.setHeader( "Cache-Control" , "no-cache" );
//Forces caches to obtain a new copy of the page from the origin server
response.setHeader( "Cache-Control" , "no-store" );
//Directs caches not to store the page under any circumstance
response.setDateHeader( "Expires" , 0);
//Causes the proxy cache to see the page as "stale"
response.setHeader( "Pragma" , "no-cache" );
//HTTP 1.0 backward compatibility
if (!this.userIsLoggedIn(request)) {
ActionErrors errors = new ActionErrors();
errors.add( "error" , new ActionError( "logon.sessionEnded" ));
this.saveErrors(request, errors);
return mapping.findForward( "sessionEnded" );
}
return executeAction(mapping, form, request, response);
}
protectedabstract ActionForward executeAction(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException;
privateboolean userIsLoggedIn(HttpServletRequest request) {
if (request.getSession().getAttribute( "User" ) == null) {
return false;
}
return true;
}
}
清單6中的代碼與清單4中的很相像，唯一區(qū)別是用ActionMapping findForward替代了RequestDispatcher forward。清單6中，如果在HttpSession中未找到username字符串，ActionMapping對象將找到名為 sessionEnded的forward元素并跳轉(zhuǎn)到對應的path。如果找到了，子類通過實現(xiàn)executeAction()方法，將執(zhí)行他們自己的業(yè)務邏輯。因此，在struts-web.xml配置文件中為所有繼承自Action基類的子類聲明個一名為sessionEnded的forward元素并將其指向login.jsp是至關重要的。清單7以secure1 action闡明了這樣一個聲明：
清單7
＜action path= "/secure1"
type= "com.kevinhle.logoutSampleStruts.Secure1Action"
scope= "request" ＞
＜forward name= "success" path= "/WEB-INF/jsps/secure1.jsp" /＞
＜forward name= "sessionEnded" path= "/login.jsp" /＞
＜/action＞
繼承自BaseAction類的子類Secure1Action實現(xiàn)了executeAction()方法而不是覆蓋它。Secure1Action類不需要執(zhí)行任何退出代碼，如清單8：
清單8
publicclass Secure1Action extends BaseAction {
public ActionForward executeAction(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
return (mapping.findForward( "success" ));
}
}
上面的解決方案是如此的優(yōu)雅有效，它僅僅只需要定義一個基類而不需要額外的代碼工作。將通用的行為方法寫成一個繼承StrutsAction的基類是者的推薦的，而且這是許多Struts項目的共同經(jīng)驗。
十一. 局限性
上述解決方案對JSP或基于Struts的Web應用都是非常簡單而實用的，但它還是有某些局限。在我看來，這些局限并不是至關緊要的。
• 通過取消與瀏覽器后退按鈕有關的緩存機制，一旦用戶離開頁面而沒有對數(shù)據(jù)進行提交，那么頁面將會丟失所有輸入的數(shù)據(jù)。即使點擊瀏覽器的后退按鈕返回到剛才的頁面也無濟于事，因為瀏覽器會從服務器獲取新的空白頁面顯示出來。一種可能的方法并不是阻止這些JSP頁面包含數(shù)據(jù)數(shù)據(jù)表格。在基于JSP的解決方案當中，那些JSP頁面可以刪除在清單4中的代碼。在基于Struts的解決方案當中，Action類需要繼承自Struts的Action類而非 BaseAction類。
• 上面講述的方法在Opera瀏覽器中不能工作。事實上沒有適用于Opera瀏覽器的解決方案，因為Opera瀏覽器與2616 Hypertext Transfer Protocol—HTTP/1.1緊密相關。Section 13.13 of RFC 2616 states:
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.
History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
幸運的是，使用微軟的IE和基于 Mozilla的瀏覽器用戶多余Opera瀏覽器。上面講述的解決方案對大多數(shù)用戶來說還是有幫助的。另外，無論是否使用上述的解決方案，Opera瀏覽器仍然存在用戶退出問題，就Opera來說沒有任何改變。然而，正如RFC2616中所說，通過像上面一樣設置頭文件指令，當用戶點擊一個鏈接時， Opera瀏覽器不會從緩存中獲取頁面。
十二. 結(jié)論
這篇文章講述了處理退出問題的解決方案，盡管方案簡單的令人驚訝，但在所有情況下都能有效地工作。無論是對JSP還是Struts，所要做的不過是寫一段不超過50行的代碼以及一個記錄用戶最后登陸時間的方法。在有密碼保護的Web應用中使用這些方案能夠確保在任何情況下用戶的私人數(shù)據(jù)不致泄露，同時，也能增加用戶的經(jīng)驗。
