jsp 重复提交问题

JSP重复提交问题的与解决策略

在Web开发中，JSP页面的表单重复提交是一个常见的问题。对于这个问题，有多种解决方案。

方法一：禁止浏览器缓存。在表单页的HEAD区域加入以下代码，可以禁止浏览器缓存页面，从而减少重复提交的可能性。

```bash

```

方法二：使用令牌验证。生成一个令牌保存在用户session中，并在form中添加一个hidden域来显示该令牌的值。在表单提交后，重新生成一个新的令牌，比较用户提交的令牌和session中的令牌，如果相同则是重复提交。

方法三：使用Response.Redirect("selfPage")语句。但这种方法在大多数情况下并不常用。

方法四：利用按钮提交后禁用。在JSP页面的FORM表单中添加一个按钮，点击后通过JavaScript禁用该按钮并提交表单，防止用户重复提交。

方法五：添加隐藏域并重定向。在JSP页面的FORM表单中添加一个隐藏域，保存当前页面的URL，然后在服务器端获取该URL并使用response.sendRedirect()方法进行重定向。这种方法可以有效地解决由于页面刷新带来的数据重复提交问题。

方法六：使用AJAX无刷新提交。AJAX技术可以在不刷新页面的情况下提交表单，从而减少重复提交的可能性。

对于防止浏览器的刷新键引起系统操作重复提交的问题，可以通过重定向解决。在struts的action中，可以通过修改struts-config.xml文件中的action配置，设置redirect属性为true，并重定向到要跳转的页面，以解决重复提交的问题。

关于重复提交、重复刷新、防止后退的问题以及处理方式，我们需要先了解为什么要处理这样的问题。重复提交和重复刷新主要是为了解决系统重复记录的问题。但在某些系统中，如资源管理系统，可能并不允许出现重复的记录，因此需要根据实际需求来决定是否处理重复提交问题。

处理JSP页面的重复提交问题需要根据具体情况选择合适的解决方案。以上提供的方法只是一些常见的解决方案，具体实现可能需要根据实际需求进行调整。理解场景背后的需求：防止后退引发的操作错误

在Web应用中，我们时常面临用户误操作的问题，如重复刷新、重复提交和点击后退按钮导致的流程错误。这些问题在投票系统、订票系统等需要多步骤且数据前后依赖的场景中尤为突出。想象一下，用户在某个步骤点击了后退按钮，返回到了之前的页面并进行了修改或提交，这可能导致前面步骤的数据丢失或产生其他错误。这种场景下的错误源于用户行为与预期流程的不匹配。

一、理解防止后退操作的重要性

在多步骤的Web应用中，每个步骤的数据和操作是相互关联的。当用户点击后退按钮时，如果页面设计不当或缺乏适当的控制机制，可能导致数据丢失、重复提交等问题。这不仅影响用户体验，还可能对系统造成不必要的负担。如何防止用户后退成为一个值得的问题。

二、客户端处理策略：使用JavaScript脚本控制用户行为

为了应对这一问题，我们可以在客户端使用JavaScript脚本来控制用户行为。例如，通过设置变量来限制表单提交次数，或使用disable属性禁用提交按钮或图片。还可以通过更改浏览器历史记录或使用新页面URL替换当前历史记录来禁用后退按钮。这些方法的优点是简单易行，但存在一定的局限性，如用户可能禁用JavaScript或绕过这些控制机制。

三、服务器端处理策略：使用同步令牌（Token）机制防止重复提交

除了客户端控制外，服务器端处理尤为重要。以Struts框架为例，可以利用同步令牌机制来解决Web应用中的重复提交问题。服务器在处理请求前，会检查请求中的令牌值与保存在用户会话中的令牌值是否匹配。处理完请求并生成新令牌后，该令牌不仅传给客户端，还会替换用户会话中的旧令牌。这样，即使用户回退到之前的提交页面并尝试提交，由于令牌不匹配，服务器会识别出这是重复提交并拒绝处理。这种方法的可靠性较高，因为它不受用户浏览器或客户端设置的影响。

在Struts框架中，对于用户的每一次请求，我们都需要进行细致的处理，特别是在处理表单提交时。为了保证数据的真实性和避免重复提交，我们常常会使用到一种叫做令牌的技术。

让我们看看这个代码片段：

```java

if (isTokenValid(request, true)) {

// your code here

return mapping.findForward("success");

} else {

saveToken(request);

return mapping.findForward("submitagain");

}

```

在这段代码中，我们首先会验证用户提交的令牌是否有效。如果令牌有效，那么我们会跳转到"success"页面；如果无效，我们会保存新的令牌并让用户重新提交。Struts框架会根据用户的会话ID和当前系统时间来生成一个唯一的令牌，这个令牌在每次会话中都是独一无二的。具体的实现可以参考`TokenProcessor`类中的`generateToken()`方法。

接下来，让我们深入一下令牌的验证和生成过程。在HTML表单中，我们会自动根据session中的标识生成一个隐含的input代表令牌，以防止用户两次提交相同的表单。在action中，我们会验证提交的令牌是否有效。如果令牌无效，我们会添加一个全局错误，并重置令牌。我们还会生成一个新的令牌供下次使用。令牌的生成过程是通过将用户的会话ID和当前系统时间进行MD5加密得到的。

对于重复提交、重复刷新、防止后退等问题，都是系统为了避免重复记录而需要解决的问题。在客户端，我们需要针对每一种可能提出相应的解决方案。而在服务器端看来，这些问题都只是数据真实性的检验问题。基于令牌的处理就是一种有效的解决方案。

从另一个角度看，客户端和服务端在处理这些问题时的角度和方法是不同的。客户端更关注用户的操作体验，而服务端则更注重数据的处理。在某些问题上，可能需要在客户端解决会相对麻烦，而在服务端解决则更为简单；反之亦然。在处理某些问题时，我们需要综合考虑和平衡，决定是在客户端解决还是服务端解决。

`cambrian.render('body')`这段代码可能是渲染网页主体的命令，但这并非Struts框架的核心内容，所以我们在这里不做深入。Struts框架的令牌机制为我们提供了一种有效的手段来确保数据的真实性和避免重复提交，使我们在处理表单提交等问题时更加得心应手。