struts2令牌(token)内部原理

 

小菜最近接触了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一致。

小菜总是希望自己的文章能够帮助更多的人，因此写的有点啰嗦，大家见谅！