首页 > 代码库 > struts2令牌(token)内部原理

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一致。

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

struts2令牌(token)内部原理