如何解决点击网页后退提示警告的问题
//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应用示例均以关系型数据库作为安全域，但本问所讲述的内容同样适用于其他任何类型的安全域。
三、Logout action
退出动作包含删除用户名以及调用用户的HttpSession对象的invalidate()方法。清单2是从loginoutAction.jsp中节选的一段代码，以此说明退出动作：
清单2
session.invalidate();四、阻止未经认证访问受保护的JSP页面
从提交的form中获取用户提交的认证信息并经过验证后，登陆动作仅仅在HttpSession对象中写入一个用户名。退出动作则刚好相反，它从HttpSession中删除用户名并调用HttpSession对象的invalidate()方法。为了使登陆和退出动作真正发挥作用，所有受保护的JSP页面必须首先验证HttpSession中包含的用户名，以便确认用户当前是否已经登陆。如果HttpSession中包含了用户名，就说明用户已经登陆，Web应用会将剩余的JSP页中的动态内容发送给浏览器。否则，JSP页将跳转到登陆页面，login.jsp。页面home.jsp, secure1.jsp, secure2.jsp和 logout.jsp均包含清单3中的代码段：
清单3
if (null == userName) {在这个代码段中，程序从HttpSession中检索username字符串。如果username字符串为空，Web应用则自动中止执行当前页面并跳转到登陆页，同时给出错误信息“Session has ended. Please log in.”；如果不为空，Web应用继续执行，把剩余的页面提供给用户，从而使JSP页面的动态内容成为服务对象。
五、运行logoutSampleJSP1
运行logoutSampleJSP1将会出现如下几种情形：
◆如果用户没有登陆，Web应用将会正确中止受保护页面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中动态内容的执行。也就是说，假如用户并没有登陆，但是在浏览器地址栏中直接敲入受保护JSP页的地址试图访问，Web应用将自动跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”?
◆同样的，当一个用户已经退出，Web应用将会正确中止受保护页面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中动态内容的执行。也就是说，用户退出以后，如果在浏览器地址栏中直接敲入受保护JSP页的地址试图访问，Web应用将自动跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”?
◆用户退出以后，如果点击浏览器上的后退按钮返回到先前的页面，Web应用将不能正确保护受保护的JSP页面——在Session销毁后（用户退出）受保护的JSP页会重新显示在浏览器中。然而，点击该页面上的任何链接，Web应用都会跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”
六、阻止浏览器缓存
上述问题的根源就在于现代大部分浏览器都有一个后退按钮。当点击后退按钮时，默认情况下浏览器不会从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上的代码，当点击后退按钮时，这些代码也永远不会执行的。
缓存的好坏，真是仁者见仁智者见智。缓存事实上的确提供了一些便利，但这些便利通常只存在于静态的HTML页面或基于图形或影像的页面。而另一方面，Web应用通常是面向数据的。由于Web应用中的数据频繁变更，所以与为了节省时间从缓存中读取并显示过期的数据相比，提供最新的数据显得尤为重要！
幸运的是，HTTP头信息“Expires”和“Cache-Control”为应用程序服务器提供了一个控制浏览器和代理服务器上缓存的机制。HTTP头信息Expires告诉代理服务器它的缓存页面何时将过期。HTTP1.1规范中新定义的头信息Cache-Control在Web应用当中可以通知浏览器不缓存任何页面。当点击后退按钮时，浏览器发送Http请求道应用服务器以便获取该页面的最新拷贝。如下是使用Cache-Control的基本方法：
◆no-cache：强制缓存从服务器上获取该页面的最新拷贝；
◆no-store：在任何情况下缓存不保存该页面。
HTTP1.0规范中的Pragma:no-cache等同于HTTP1.1规范中的Cache-Control:no-cache，同样可以包含在头信息中。
通过使用HTTP头信息的cache控制，第二个示例应用logoutSampleJSP2解决了logoutSampleJSP1的问题。logoutSampleJSP2与logoutSampleJSP1不同表现在如下代码段中，这一代码段加入进所有受保护的页面中：
清单4
//Forces caches to obtain a new copy of the page from the origin server通过设置头信息和检查HttpSession对象中的用户名来确保浏览器不会缓存JSP页面。同时，如果用户未登陆，JSP页面的动态内容不会发送到浏览器，取而代之的将是登陆页面login.jsp。
七、运行logoutSampleJSP2
运行Web示例应用logoutSampleJSP2后将会看到如下结果：
◆当用户退出后试图点击后退按钮，浏览器不会重新显示受保护的页面，它只会显示登陆页login.jsp同时给出提示信息Session has ended. Please log in.?
◆然而，当按了后退按钮返回的页是处理用户提交数据的页面时，IE和Avant浏览器将弹出如下信息提示：
警告：页面已过期
//Forward to homepage by default为了实现上述方法，你必须记录每个用户的最后登陆时间。对于采用关系型数据库安全域来说，这点可以可以通过在某个表中加上lastLogin字段轻松实现。虽然对LDAP以及其他的安全域来说需要稍微动下脑筋，但最后登陆方法很显然是可以实现的。
表示最后登陆时间的方法有很多。示例logoutSampleJSP3利用了自1970年1月1日以来的毫秒数。这个方法即使在许多人在不同浏览器中用一个用户账号登陆时也是可行的。
九、运行logoutSampleJSP3
运行示例logoutSampleJSP3将展示如何正确处理退出问题。一旦用户退出，点击浏览器上的后退按钮在任何情况下都不会在浏览器中显示受保护的JSP页面。这个示例展示了如何正确处理退出问题而不需要对用户进行额外的培训。
为了使代码更简练有效，一些冗余的代码可以剔除。一种途径就是把清单4中的代码写到一个单独的JSP页中，其他JSP页面可以通过标签 进行使用 。
十、Struts框架下的退出实现
与直接使用JSP或JSP/servlets进行Web应用开发相比，另一个更好的可选方案是使用Struts。对于一个基于Struts的Web应用来说，添加一个处理退出问题的框架可以优雅地不费气力的实现。这归功于Struts是采用MVC设计模式的，因此可以将模型和视图代码清晰的分离。另外，Java是一个面向对象的语言，支持继承，可以比JSP中的脚本更为容易地实现代码重用。对于Struts来说，清单4中的代码可以从JSP页面中移植到Action类的execute()方法中。
此外，我们还可以定义一个继承Struts Action类的Action基类，其execute()方法中包含了类似清单4中的代码。通过继承，其他Action类可以继承基本类中的通用逻辑来设置HTTP头信息以及检索HttpSession对象中的username字符串。这个Action基类是一个抽象类并定义了一个抽象方法executeAction()。所有继承自Action基类的子类都必须实现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.）。他们将只包含正常的业务逻辑代码。清单6是基类的部分代码：
清单6
//Forces caches to obtain a new copy of the page from the origin serverif (!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中的很相像，唯一区别是用ActionMapping findForward替代了RequestDispatcher forward。清单6中，如果在HttpSession中未找到username字符串，ActionMapping对象将找到名为sessionEnded的forward元素并跳转到对应的path。如果找到了，子类通过实现executeAction()方法，将执行他们自己的业务逻辑。因此，在struts-web.xml配置文件中为所有继承自Action基类的子类声明个一名为sessionEnded的forward元素并将其指向login.jsp是至关重要的。清单7以secure1 action阐明了这样一个声明：
清单7
type= "com.kevinhle.logoutSampleStruts.Secure1Action"继承自BaseAction类的子类Secure1Action实现了executeAction()方法而不是覆盖它。Secure1Action类不需要执行任何退出代码，如清单8：
清单8
}上面的解决方案是如此的优雅有效，它仅仅只需要定义一个基类而不需要额外的代码工作。将通用的行为方法写成一个继承StrutsAction的基类是者的推荐的，而且这是许多Struts项目的共同经验。
十一、局限性
上述解决方案对JSP或基于Struts的Web应用都是非常简单而实用的，但它还是有某些局限。在我看来，这些局限并不是至关紧要的。
◆通过取消与浏览器后退按钮有关的缓存机制，一旦用户离开页面而没有对数据进行提交，那么页面将会丢失所有输入的数据。即使点击浏览器的后退按钮返回到刚才的页面也无济于事，因为浏览器会从服务器获取新的空白页面显示出来。一种可能的方法并不是阻止这些JSP页面包含数据数据表格。在基于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浏览器。上面讲述的解决方案对大多数用户来说还是有帮助的。另外，无论是否使用上述的解决方案，Opera浏览器仍然存在用户退出问题，就Opera来说没有任何改变。然而，正如RFC2616中所说，通过像上面一样设置头文件指令，当用户点击一个链接时，Opera浏览器不会从缓存中获取页面。
十二、结论
这篇文章讲述了处理退出问题的解决方案，尽管方案简单的令人惊讶，但在所有情况下都能有效地工作。无论是对JSP还是Struts，所要做的不过是写一段不超过50行的代码以及一个记录用户最后登陆时间的方法。在有密码保护的Web应用中使用这些方案能够确保在任何情况下用户的私人数据不致泄露，同时，也能增加用户的经验。
