重複送出、重複重新整理、防止後退的問題以及處理方式（轉帖）

重複送出、重複重新整理、防止後退的問題以及處理方式

一。前言

你在任何一個比較專業的BBS都會看到這樣的問題，即使你Google一下，也會發現有很多的人在關注和詢問，但大家給出的解決方法卻都是千差萬别，（有的人主張采用腳本來解決;有的則想重定向到别的頁面;有的則将此問題提升到Token的角度）為什麼會有如此大的差異呢？

二。問題場景

首先，我們應該先了解為什麼要處理這樣的問題？或者專業一點就是它适合的場景是什麼？（似乎隻有人來問沒有人來解釋）

1。重複送出、重複重新整理的場景

重複送出、重複重新整理都是來解決系統重複記錄的問題。也就是說某個人在多次的送出某條記錄（為什麼？也許是閑了沒有事情幹的;最有可能是使用者根本就不知道自己的送出結果是否已經執行了？！）。

但出現了這樣的問題并不見得就必須處理，要看你所開發的系統的類别而定。比如你接手的是某個資源管理系統，系統本身從需求的角度根本就不允許出現"重複"的記錄，在這樣需求的限制條件下，去執行重複的送出動作隻會引發“業務級異常”的産生，根本就不可能執行成功也就無所謂避免不避免的問題了。

2。防止後退的場景

了解了重複重新整理、重複送出的場景，我們來了解一下"防止後退"操作的原因是什麼？比如你在開發某個投票系統，它有很多的步驟，并且這些步驟之間是有聯系的，比如第一步會将某些資訊發送給第二步，第二步緩存了這些資訊，同時将自身的資訊發送給了第三步。。。。。等等，如果此時使用者處在第三步驟下，我們想象一下某個淘氣使用者的使用者點選了後退按鈕，此時螢幕出現了第二步驟的頁面，他再次的修改或者再次的送出，進入到下一個步驟（也就是第三步驟），錯誤就會在此産生？！什麼錯誤呢？最為典型的就是這樣的操作直接導緻了對于第一個步驟資訊的丢失！（如果這樣的資訊是依靠Request存放的話，當然你可以存放在Session或者更大的上下文環境中，但這不是個好主意！關于資訊存放的問題，下次在就這個問題詳細的讨論）

三。如何處理的問題

當然很多的系統（比如訂票系統從需求上本身是允許個人重複訂票的）是必須要避免重複重新整理、重複送出、以及防止後退的問題的，但即使是這樣的問題，也要區分如何處理以及在哪裡處理的（網上隻是告訴你如何處理，但很少去區分在哪裡處理的），顯然處理的方式無非是用戶端或者伺服器端兩種，而面對不同的位置處理的方式也是不同的，但有一點要事先聲明：任何用戶端（尤其是B/S端）的處理都是不可信任的，最好的也是最應該的是伺服器端的處理方法。

用戶端處理：

面對用戶端我們可以使用Javascript腳本來解決，如下

1。重複重新整理、重複送出

Ways One：設定一個變量，隻允許送出一次。

<script language="javascript">

    var checkSubmitFlg = false;

    function checkSubmit() {

      if (checkSubmitFlg == true) {

         return false;

      }

      checkSubmitFlg = true;

      return true;

   }

   document.ondblclick = function docondblclick() {

    window.event.returnValue = false;

   document.onclick = function doconclick() {

       if (checkSubmitFlg) {

         window.event.returnValue = false;

       }

</script>

<html:form action="myAction.do" method="post" οnsubmit="return checkSubmit();">

Way Two : 将送出按鈕或者image置為disable

  <html:form action="myAction.do" method="post" 

    οnsubmit="getElById('submitInput').disabled = true; return true;">  

  <html:image styleId="submitInput" src="images/ok_b.gif" border="0" />

  </html:form> 

2。防止使用者後退

這裡的方法是千姿百态，有的是更改浏覽器的曆史紀錄的，比如使用window.history.forward()方法;有的是“用新頁面的URL替換目前的曆史紀錄，這樣浏覽曆史記錄中就隻有一個頁面，後退按鈕永遠不會變為可用。”比如使用javascript:location.replace(this.href); event.returnValue=false;

2.伺服器端的處理（這裡隻說Struts架構的處理）

利用同步令牌（Token）機制來解決Web應用中重複送出的問題，Struts也給出了一個參考實作。

基本原理：

伺服器端在處理到達的請求之前，會将請求中包含的令牌值與儲存在目前使用者會話中的令牌值進行比較，

看是否比對。在處理完該請求後，且在答複發送給用戶端之前，将會産生一個新的令牌，該令牌除傳給

用戶端以外，也會将使用者會話中儲存的舊的令牌進行替換。這樣如果使用者回退到剛才的送出頁面并再次

送出的話，用戶端傳過來的令牌就和伺服器端的令牌不一緻，進而有效地防止了重複送出的發生。

if (isTokenValid(request, true)) {

    // your code here

    return mapping.findForward("success");

} else {

    saveToken(request);

    return mapping.findForward("submitagain");

}

Struts根據使用者會話ID和目前系統時間來生成一個唯一（對于每個會話）令牌的，具體實作可以參考

TokenProcessor類中的generateToken()方法。

1. //驗證事務控制令牌,<html:form >會自動根據session中辨別生成一個隐含input代表令牌，防止兩次送出

2. 在action中：

       //<input type="hidden" name="org.apache.struts.taglib.html.TOKEN" 

       //  value="6aa35341f25184fd996c4c918255c3ae">

       if (!isTokenValid(request))

           errors.add(ActionErrors.GLOBAL_ERROR,

                      new ActionError("error.transaction.token"));

       resetToken(request); //删除session中的令牌

3. action有這樣的一個方法生成令牌

   protected String generateToken(HttpServletRequest request) {

       HttpSession session = request.getSession();

       try {

           byte id[] = session.getId().getBytes();

           byte now[] =

               new Long(System.currentTimeMillis()).toString().getBytes();

           MessageDigest md = MessageDigest.getInstance("MD5");

           md.update(id);

           md.update(now);

           return (toHex(md.digest()));

       } catch (IllegalStateException e) {

           return (null);

       } catch (NoSuchAlgorithmException e) {

   } 

總結

對于重複送出、重複重新整理、防止後退等等都是屬于系統為避免重複記錄而需要解決的問題，在用戶端去處理需要針對每一種的可能提出相應的解決方案，然而在伺服器端看來隻不過是對于資料真實性的檢驗問題，基于令牌的處理就是一勞永逸的方法。

同時我們也看到，從不同的角度去看待問題，其解決的方法也是不同的。用戶端更追求的是使用者的操作，而服務端則将注意力放在了資料的處理上，是以在某個對于伺服器端看似容易的問題上，用用戶端來解決卻麻煩了很多！反之依然。是以在某些問題的處理上我們需要綜合考慮和平衡，是用用戶端來解決？還是用伺服器端來處理？