《研磨struts2》第十七章 防止重复提交 之 17.2 运用标签

《研磨struts2》第十七章 防止重复提交 之 17.2 使用标签

17.2??使用<s:token/>标签

17.2.1??使用<s:token/>标签入门

Token也被称做令牌，所以使用<s:token/>标签防止重复提交，也常被称做使用令牌防止重复提交。

1：修改页面

?????? <s:token/>标签的使用非常简单，只需要在提交页面的<s:form>标签内加上子标签<s:token/>就可以了。

如果把提交页面当做重复提交时返回的结果页面的话，通常还需要在这个页面上引用重复提交时的错误信息。重复提交的错误信息以动作错误信息的方式存在，所以我们只要用<s:actionerror/>标签来引用即可。示例代码如下：

?

图17.1 页面被重定向到指定的invalid.token结果

再看看控制台的输出，应该只有一次输出了，示例如下：

?

图16.2 使用令牌防止重复提交流程图

也许，有些朋友会说，既然struts.token隐藏域记录的值和session的struts.token属性记录的值一模一样，那么，在token拦截器运行的时候，比较的结果还可能不相等吗？

当然是可能的，因为token拦截器的作用在重复提交的时候才能显现出来。一起来分析分析，按照运行顺序，先后发生了如下的几件事情：

• 首先，用户访问页面，这时候，<s:token/>标签要向session写入struts.token属性，假设这个随机数为123456789。那么，<s:token/>标签也同时要向<s:form/>写入名为struts.token的隐藏域，它的值也是123456789。
• 然后，用户第一次提交这个页面，这时候，session中的struts.token属性和表单中的struts.token隐藏域的值都为123456789，判断为相等，所以token拦截器移除了session中的struts.token这个属性，整个防止重复提交的关键就在这步，然后继续运行execute方法，所以，这次提交是有效的。
• 在第一次请求还没有运行完，用户再一次提交了这个页面。这时候，session中已经没有了struts.token属性，已经在第一次请求时被token拦截器移除了，但是表单中仍有struts.token隐藏域，所以二者肯定不相等了，那么，这次请求就被认为是重复请求，重定向到invalid.token指定的Result。

  ?????? 补充说明：如果指定了<s:token/>标签的name属性，那么对session写入的属性名就不再是默认的struts.token，而是这个name值；同理对表单写入的隐藏域名也不再是默认的struts.token，也是这个name值了。在理解<s:token/>标签和token拦截器的作用时，基本不用理会struts.token.name隐藏域的作用。

  ?

  私塾在线网站原创《研磨struts2》系列

  转自请注明出处：【http://sishuok.com/forum/blogPost/list/0/4150.html】

  欢迎访问http://sishuok.com获取更多内容