struts2令牌(token)内部原理

最近在项目中使用到struts2的token防重提交方法，但出现很多问题：

    在有防重页面填写资料时，不小心打开另一个有防重页面后（同一浏览器），填写资料的页面不能提交，后台提示tokenId 与sessionId不匹配，通过调试，发现tokenId在新打开页面时，发生了改变，目前还未找到解决方法解决这种情况。

  如下是在网上找了一些原理性的东西，记录于此。

来源：http://www.cnblogs.com/iyangyuan/archive/2013/05/05/3060488.html

小菜最近接触了struts2中的令牌知识，由于该知识点比较重要，因此想弄明白些，于是满怀信心的上网查阅资料，结果让小菜很无奈，网上的资料千篇一律，总结出来就一句话：“访问页面时，在页面产生一个token id，同时在服务器的session中保存一个同样的id，提交时判断如果相同怎么样不相同怎么样。。。”

    可能是小菜愚笨，实在是无法从这么精炼的描述中体会令牌的精髓。

    肤浅的那么一说，然后上来就是一堆代码，有时候对初学者的帮助可能不是很大，如果能够介绍一下其中的原理，无疑会加快读者学习速度。

    经过刻苦的研究，下面小菜来介绍一下，令牌究竟是如何做到防止界面刷新的。

    本文不涉及令牌具体用法，只讲原理。

    首先需要说明的是，在struts2框架中使用令牌基本上就是两步：

        l  在jsp页面中使用<s:token></s:token>标签，可以放在表单中任何位置，这个标签的作用就是在页面中产生一个token id，可以通过“查看源文件”的形式看到。为什么要放在表单中呢？因为这个是要提交到服务器的，要不然服务器怎么知道你的id是多少？

        l  在struts2核心配置文件中为token拦截器添加参数，来指明需要拦截哪些方法，例如：<interceptor-ref name="token"><param name="includeMethods">save</param></interceptor-ref>，指明拦截save方法。当然也可以用excludeMethods来声明不拦截哪些方法。

                  

令牌生成原理图：

    从图中可以看出，如果某个jsp页面中有token标签，那么无论是请求这个界面还是内部转发到这个界面，我们统一说成是“渲染界面”的时候，都会造成token id的产生或者更新。

    一定要搞清楚，这里是请求的jsp页面，此时可以产生令牌，但令牌不会起作用，因为它拦截的不是jsp，而是通过反射机制调用的方法。

 

令牌拦截原理图：

     从图中可以看出，令牌可以拦截的是Action中的方法。

     如果方法需要被拦截，会判断session中的token id和提交过来的token id是否相等。如果不相等，则直接跳转到预先配置好的界面，session中的token id不变；如果相等，则执行请求的方法，关键的一点是，此时session中的token id会被清空！这个步骤非常关键！

 

综上，关于令牌的使用，记住以下几点，基本可以应对各种复杂的令牌应用场景

 

    l  注意令牌的产生时机，它是在加载(或渲染)带有token标签的jsp页面时产生的，与请求或者转发无关，与方法是否被拦截无关。

    l  由于服务器端的token id是保存在session中的，因此不同的页面间可以共享，使用时注意，避免混乱。

    l  如果访问的方法属于被拦截的方法，验证通过之后，会清空session中的token id；如果验证不通过，session 中的token id不变，直到下一次加载(或渲染)带有token标签的jsp页面。

 

    再多啰嗦一些，为什么验证通过后要清空session中的token id呢？其实不难理解，从宏观上来思考，重复提交有一个必然的特征：它的token id是上一个。因此只要保证验证通过后session中保存的token id变化即可，清空是最直接的办法。要想通过验证，只有一个途径：重新加载(或渲染)带有token标签的jsp页面，使客户端的token id和服务器端的token id一致。