实战防止重复提交(token)应用思路及过程

我这里只考虑了直接使用struts API的情况,使用自定义的token生成机制与此类似。

产生重复提交的两种情况：
1.用户操作完成后，点后退，返回jsp页面，再次提交。
2.用户操作完成后，刷新当前页。

简单回想下token的使用：
1.生成token，并保存到HttpSession中;
2.限制重复提交的jsp页面要从session中get这个token，并提交到servlet（或者struts action）；
3.servlet（或者struts action）中比较HttpSession中保存的token和jsp页面提交来的token是否内容相同。如果相同，则同意提交；否则，操作为重复提交，拒绝该此操作。

常规的实现方法中，是由struts的action的子类先做下预处理：生成token，然后在jsp中get之。


有个遗留的系统，表现层这块用的struts，不知道什么原因没有处理“重复提交”这个问题，系统如果在生产系统上运行的话，不知道要出多大的乱子呢，应该是比想到的结果还要糟糕。下面就赶紧解决这个BUG。

目前系统代码大约5万行，用常规的方法恐怕不行，因为现在为每个需要防止重复提交的jsp做个预处理的action是不可能的：
1.要修改很多jsp的提交路径，原来是直接跳转到jsp的.
2.要修改struts的配置文件,现在的配置文件已经很多了。


解决办法：
在跳转到jsp之前生成token，才能解决这个问题。什么机制可以处理这种转发呢？想来想去，突然想到了filter。
正好filter可以捕获到jsp的跳转，这样在filter中添加生成token的逻辑即可。
web.xml中指定需要做防止重复提交处理的jsp即可，或者自己指定配置格式自己读取。


实施：
1.生成token可以使用struts的TokenProcessor，当然也可以定义自己的token生成机制。
2.如果使用struts来生成token，则注意jsp中获取token时用的名称，要到TokenProcessor中查一下。
3.保存到jsp中的hidden的名称，也要看下struts action中isTokenValid()方法中是怎样比较token的。

适用于全新的系统或者遗忘重复提交限制的遗留系统。

全新的系统不一定非要这么做。