屏蔽后退按钮

《屏蔽后退按钮》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、在JSP页面加下面清除缓存代码试下看看： <% response.setHeader("Pragma","No-cache"); response.setHeader("Cache-Control","no-cache"); response.setDateHeader("Expires",0); %>1、加个防重复提交代码，Struts里面有的2、Action中跳转时，不要使用mapping.findForward()方式跳转，跳转时候，用returnnewActionForward("URL",true);3、在页面上加上判断session，为空，则sess

2、ion失效2、当开发有密码登陆的系统时，用户退出系统以后，有些页面是不应该让用户使用的，但是由于动态缓存，用户可以点击浏览器的后退按钮去访问一些不应该访问的内容。可能会不安全。其实不是必须清除缓存,退出登陆后清除保存该用户信息的session就可以.既然这个系统是要求登陆后才有权限使用.那么该系统的每一个动作都应该检查是否已经登陆.也就是检查保存登陆用户信息的session是否存在.退出登陆后把session清除,就算退回上一页面,那也根本无法操作系统.//javascript:window.histor

3、y.forward(1);dddd首先，作为开发人员，拦截是必须的，无论是安全拦截还是异常拦截。我们先分析为什么通过浏览器返回访问的原因：1.浏览器缓存  我们有时候会发现是退出系统了可是通过历史记录或者直接访问地址，最后一次操作的数据或显示的列表还在那里，一堆人在冒汗，说你系统不安全！  其实这时候并没有访问到系统，是本地的浏览器缓存在做怪。2.没

4、有做权限拦截  很多人在做程序的时候可能会忘记去注意权限分配了，有些功能是要求用户在登录状态下使用的，甚至是某个角色的用户才可以操作的。如果没有做这些限制，很容易被人利用，最简单的就是通过地址直接访问。这两个方面内容是造成问题出现的绝大部分原因.解决方案:1.禁止缓存如：jsp<%response.setHeader("Pragma","No-Cache");response.setHeader("Cache-Control","No-Cache");response.setDateHeader("Expires",0);%>2.利用session在页面进行拦截

5、如:jsp原码Stringuserid=(String)session.getValue("userid");if(userid==""

6、

7、userid==null)//判断指定session值的存在与否,来检查是否已经登录{ 跳转到提示页面}else{ 其他主体程序代码}利用以上两个方法同时使用，能够解决大部分问题，包括浏览器返回的问题。3.利用struts配置拦截器4.涉及权限的就不能简判断有没有登录了，应该取出用户的权限值（一般也建议放入session，避免频繁访问数据库）来判断是否可以执行，处理思路也和判断有无登录相同如：jspStringlevel=(

8、String)session.getValue("level");if(level==""

9、

10、level==null

11、

12、!level.equals("1"))//判断指定session值的存在与否并检查权限值{ 跳转到提示页面}else{ 其他主体程序代码}希望对大家有用，有写得不好的，请各位长辈指正。关键字:重复一。前言你在任何一个比较专业的BBS都会看到这样的问题，即使你Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别，（有的人主张采用脚本来解决;有的则想重定向到别的页面;有的则将此问题提升到Token的角度）为什么会有如

13、此大的差异呢？二。问题场景首先，我们应该先了解为什么要处理这样的问题？或者专业一点就是它适合的场景是什么？（似乎只有人来问没有人来解释）1。重复提交、重复刷新的场景重复提交、重复刷新都是来解决系统重复记录的问题。也就是说某个人在多次的提交某条记录（为什么？也许是闲了没有事情干的;最有可能是用户根本就不知道自己的提交结果是否已经执行了？！）。但出现了这样的问题并不见得就必须处理，要看你所开发的系统的类别而定。比如你接手的是某个资源管理系统，系统本身从需求的角度根本就不允许出现"重复"的记录，在这样需求的约束条件下，去执行重复的提交动作只会引发“业务级异常”的产生，

14、根本就不可能执行成功也就