1、在 JSP页面加下面清除缓存代码试下看看：1、 加个防重复提交代码，Struts 里面有的2、Action 中跳转时，不要使用 mapping.findForward()方式跳转，跳转时候，用return new ActionForward(“URL“,true);3、在页面上加上判断 session，为空，则 session失效2、 当开发有密码登陆的系统时，用户退出系统以后，有些页面是不应该让用户使用的，但是由于动态缓存，用户可以点击浏览器的后退按钮去访问一些不应该访问的内容。可能会不安全。其实不是必须清除缓存,退出登陆后清除保存该用户信息的 session就可以.既然这个系统是要求登陆后
2、才有权限使用.那么该系统的每一个动作都应该检查是否已经登陆.也就是检查保存登陆用户信息的 session是否存在.退出登陆后把 session清除,就算退回上一页面,那也根本无法操作系统./javascript:window.history.forward(1);dddd 首先，作为开发人员，拦截是必须的，无论是安全拦截还是异常拦截。 我们先分析为什么通过浏览器返回访问的原因： 1.浏览器缓存 我们有时候会发现是退出系统了可是通过历史记录或者直接访问地址，最后一次操作的数据或显示的列表还在那里，一堆人在冒汗，说你系统不安全！ 其实这时候并没有访问到系统，是本地的浏览器缓存在做怪。 2.没有做权
3、限拦截 很多人在做程序的时候可能会忘记去注意权限分配了，有些功能是要求用户在登录状态下使用的，甚至是某个角色的用户才可以操作的。如果没有做这些限制，很容易被人利用，最简单的就是通过地址直接访问。 这两个方面内容是造成问题出现的绝大部分原因. 解决方案: 1.禁止缓存 如：jsp 2.利用 session 在页面进行拦截 如:jsp 原码 String userid= (String)session.getValue(“userid“); if(userid=“|userid=null)/判断指定 session 值的存在与否 ,来检查是否已经登录 跳转到提示页面 else 其他主体程序代码 利
4、用以上两个方法同时使用，能够解决大部分问题，包括浏览器返回的问题。 3.利用 struts 配置拦截器 4.涉及权限的就不能简判断有没有登录了，应该取出用户的权限值（一般也建议放入session，避免频繁访问数据库）来判断是否可以执行，处理思路也和判断有无登录相同 如：jsp String level= (String)session.getValue(“level“); if(level=“|level=null|!level.equals(“1“)/判断指定 session 值的存在与否并检查权限值 跳转到提示页面 else 其他主体程序代码 希望对大家有用，有写得不好的，请各位长辈指正。
5、关键字: 重复 一。前言你在任何一个比较专业的 BBS都会看到这样的问题，即使你 Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别，（有的人主张采用脚本来解决;有的则想重定向到别的页面;有的则将此问题提升到 Token的角度）为什么会有如此大的差异呢？二。问题场景首先，我们应该先了解为什么要处理这样的问题？或者专业一点就是它适合的场景是什么？（似乎只有人来问没有人来解释）1。重复提交、重复刷新的场景重复提交、重复刷新都是来解决系统重复记录的问题。也就是说某个人在多次的提交某条记录（为什么？也许是闲了没有事情干的;最有可能是用户根本就不知道自己的提交结果是否已
6、经执行了？！）。但出现了这样的问题并不见得就必须处理，要看你所开发的系统的类别而定。比如你接手的是某个资源管理系统，系统本身从需求的角度根本就不允许出现“重复“的记录，在这样需求的约束条件下，去执行重复的提交动作只会引发“业务级异常”的产生，根本就不可能执行成功也就无所谓避免不避免的问题了。2。防止后退的场景了解了重复刷新、重复提交的场景，我们来了解一下“防止后退“操作的原因是什么？比如你在开发某个投票系统，它有很多的步骤，并且这些步骤之间是有联系的，比如第一步会将某些信息发送给第二步，第二步缓存了这些信息，同时将自身的信息发送给了第三步。等等，如果此时用户处在第三步骤下，我们想象一下某个淘气
7、用户的用户点击了后退按钮，此时屏幕出现了第二步骤的页面，他再次的修改或者再次的提交，进入到下一个步骤（也就是第三步骤），错误就会在此产生？！什么错误呢？最为典型的就是这样的操作直接导致了对于第一个步骤信息的丢失！（如果这样的信息是依靠 Request存放的话，当然你可以存放在 Session或者更大的上下文环境中，但这不是个好主意！关于信息存放的问题，下次在就这个问题详细的讨论）三。如何处理的问题当然很多的系统（比如订票系统从需求上本身是允许个人重复订票的）是必须要避免重复刷新、重复提交、以及防止后退的问题的，但即使是这样的问题，也要区分如何处理以及在哪里处理的（网上只是告诉你如何处理，但很少
8、去区分在哪里处理的），显然处理的方式无非是客户端或者服务器端两种，而面对不同的位置处理的方式也是不同的，但有一点要事先声明：任何客户端（尤其是 B/S端）的处理都是不可信任的，最好的也是最应该的是服务器端的处理方法。客户端处理：面对客户端我们可以使用 Javascript脚本来解决，如下1。重复刷新、重复提交Ways One：设置一个变量，只允许提交一次。var checkSubmitFlg = false;function checkSubmit() if (checkSubmitFlg = true) return false;checkSubmitFlg = true;return tr
9、ue;document.ondblclick = function docondblclick() window.event.returnValue = false;document.onclick = function doconclick() if (checkSubmitFlg) window.event.returnValue = false;Way Two : 将提交按钮或者 image置为 disable2。防止用户后退这里的方法是千姿百态，有的是更改浏览器的历史纪录的，比如使用window.history.forward()方法;有的是“用新页面的 URL替换当前的历史纪录，这样
10、浏览历史记录中就只有一个页面，后退按钮永远不会变为可用。”比如使用javascript:location.replace(this.href); event.returnValue=false;2.服务器端的处理（这里只说 Struts框架的处理）利用同步令牌（Token）机制来解决 Web应用中重复提交的问题，Struts 也给出了一个参考实现。基本原理：服务器端在处理到达的请求之前，会将请求中包含的令牌值与保存在当前用户会话中的令牌值进行比较，看是否匹配。在处理完该请求后，且在答复发送给客户端之前，将会产生一个新的令牌，该令牌除传给客户端以外，也会将用户会话中保存的旧的令牌进行替换。这样如
11、果用户回退到刚才的提交页面并再次提交的话，客户端传过来的令牌就和服务器端的令牌不一致，从而有效地防止了重复提交的发生。if (isTokenValid(request, true) / your code herereturn mapping.findForward(“success“); else saveToken(request);return mapping.findForward(“submitagain“);Struts根据用户会话 ID和当前系统时间来生成一个唯一（对于每个会话）令牌的，具体实现可以参考TokenProcessor类中的 generateToken()方法。1.
12、/验证事务控制令牌,会自动根据 session中标识生成一个隐含 input代表令牌，防止两次提交2. 在 action中：/if (!isTokenValid(request)errors.add(ActionErrors.GLOBAL_ERROR,new ActionError(“error.transaction.token“);resetToken(request); /删除 session中的令牌3. action有这样的一个方法生成令牌protected String generateToken(HttpServletRequest request) HttpSession ses
13、sion = request.getSession();try byte id = session.getId().getBytes();byte now =new Long(System.currentTimeMillis().toString().getBytes();MessageDigest md = MessageDigest.getInstance(“MD5“);md.update(id);md.update(now);return (toHex(md.digest(); catch (IllegalStateException e) return (null); catch (N
14、oSuchAlgorithmException e) return (null);总结对于重复提交、重复刷新、防止后退等等都是属于系统为避免重复记录而需要解决的问题，在客户端去处理需要针对每一种的可能提出相应的解决方案，然而在服务器端看来只不过是对于数据真实性的检验问题，基于令牌的处理就是一劳永逸的方法。同时我们也看到，从不同的角度去看待问题，其解决的方法也是不同的。客户端更追求的是用户的操作，而服务端则将注意力放在了数据的处理上，所以在某个对于服务器端看似容易的问题上，用客户端来解决却麻烦了很多！反之依然。所以在某些问题的处理上我们需要综合考虑和平衡，是用客户端来解决？还是用服务器端来处理？
15、=第一篇=结束=第二篇=开始=网页防刷新重复提交、防后退解决方法提交后禁用提交按钮（大部分人都是这样做的）如果客户提交后,按 F5刷新怎么办?使用 Session在提交的页面也就是数据库处理之前：if session(“ok“)=true thenresponse.write “错误，正在提交“response.endend if数据处理完后，修改 session(“ok“)=false。数据处理成功马上 Redirect到另外一个页面操作后刷新的确是个问题，你可以使用跳转页面、关闭本页面，如果是有参数据条件来控制的，那就应该好做了，可以直接修改 window.location的值，把参数全部
16、改掉，这样就差不多了。缺点：简单地运用 Response.Redirect将不再有效，因为用户从一个页面转到另一个页面，我们都必须用客户端代码清除 location.history。注意，这种方法清除的是最后一个访问历史记录，而不是全部的访问记录。 点击后退按钮，再点击后退按钮，你可以看到这时打开的是本页面之前的页面！（当然，这是在你的客户端启用了JavaScript功能的条件下。）如果客户按后退，怎么办？防止网页后退-禁止缓存我们在进行数据库添加操作的时候，如果允许后退，而正巧有刷新了页面，就会再次执行添加操作，无疑这不是我们需要的，像一般网上很多禁止缓存的代码，有时并不可靠，这时你只要在操
17、作的页面加上就可以了，在网页的里指定要定向的新页，再点后退，看是不是不会再退到刚才的操作页面了，实际上已经把这个历史给删除了ASP：Response.Buffer = True Response.ExpiresAbsolute = Now() - 1 Response.Expires = 0 Response.CacheControl = “no-cache“ASP.NET：Response.Buffer=true;Response.ExpiresAbsolute=DateTime.Now.AddSeconds(-1);Response.Expires=0;Response.CacheCont
18、rol=“no-cache“;究竟怎样才能“禁用“浏览器的后退按钮？或者“怎样才能防止用户点击后退按钮返回以前浏览过的页面？”遗憾的是，我们无法禁用浏览器的后退按钮。防止网页后退-新开窗口用 window.open弹出表单页面，点提交后关闭该页；处理提交的 ASP页也是用弹出，设定表单的 target,点提交时 window.open(“XXX.asp“,“_blank“),然后用 JS来提交表单，完成后 window.close()；简单的说，就是提交表单的时候弹出新窗口，关闭本窗口。对于 window.open()打开的窗口怎么后退？能后退到哪里去？呵呵，罗嗦了一堆废话，知道怎么处理了么？混合运用客户端脚本和服务器端脚本。=第二篇=结束=第三篇=开始=
