Java防止頁面刷新重複提交

Java防止頁面刷新重複提交，看了網上的，有幾種方法：

一、 在你的表單頁裏HEAD區加入這段代碼:
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, must-revalidate">
<META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 1997 08:21:57 GMT">
2 、生成一個令牌保存在用戶session中，在form中加一個hidden域，顯示該令
牌的值，form提交後從新生成一個新的令牌，將用戶提交的令牌和session
中的令牌比較，如相同則是重複提交
3 、在你的服務器端控件的代碼中使用Response.Redirect("selfPage")語句。可是大多的數都不使用這種方法。
方法還有不少。。。
4 、<input type="button" value="提交">

五、在JSP頁面的FORM表單中添加一個hidden域
<input type="hidden" name="url"value=<%=request.getRequestURL()%>>

在你的serverlet中添加以下語句
String url=request.getParameter("url");
response.sendRedirect(url);
我通常都是採用這樣的方法返回JSP頁面的,不太明白你說的重複刷新是什麼概念

六、 ajax 無刷新提交

7 、Web開發中防止瀏覽器的刷新鍵引發系統操做重複提交
怎麼解決呢？重定向能夠解決頁面刷新帶來的數據的重複提交的問題，咱們天然能夠利用重定向的方式來解決這個問題。可是struts的action裏面mapping.findword（）；跳轉的話，默認的是在工程文件夾裏面找要跳轉的頁面。這種狀況，怎麼解決呢？
修改struts－config.xml 文件， 在action裏面有一個redirect從新定向的屬性，struts中默認的是false，添加這個屬性，改爲true，在forword中寫上要跳轉頁面的絕對或者相對地址就好了
修改以下：
<action-mappings>
<action attribute="newsActionForm" name="newsActionForm"
input="/addnews.jsp" path="/newsAction" parameter="method"
scope="request" type="com.yongtree.news.action.NewsAction">
<forward name="list" path="/listnews.jsp" redirect="true"></forward>
<forward name="error" path="/addnews.jsp"></forward>
</action>
</action-mappings>

重複提交、重複刷新、防止後退的問題以及處理方式

1、前言
你在任何一個比較專業的BBS都會看到這樣的問題，即便你Google一下，也會發現有不少的人在關注和詢問，但你們給出的解決方法卻都是千差萬別，（有的人主張採用腳原本解決;有的則想重定向到別的頁面;有的則將此問題提高到Token的角度）爲何會有如此大的差別呢？

2、問題場景
首先，咱們應該先了解爲何要處理這樣的問題？或者專業一點就是它適合的場景是什麼？（彷佛只有人來問沒有人來解釋）

一、重複提交、重複刷新的場景
重複提交、重複刷新都是來解決系統重複記錄的問題。也就是說某我的在屢次的提交某條記錄（爲何？也許是閒了沒有事情乾的;最有多是用戶根本就不知道本身的提交結果是否已經執行了？！）。

但出現了這樣的問題並不見得就必須處理，要看你所開發的系統的類別而定。好比你接手的是某個資源管理系統，系統自己從需求的角度根本就不容許出現"重複"的記錄，在這樣需求的約束條件下，去執行重複的提交動做只會引起「業務級異常」的產生，根本就不可能執行成功也就無所謂避免不避免的問題了。

二、防止後退的場景
瞭解了重複刷新、重複提交的場景，咱們來了解一下"防止後退"操做的緣由是什麼？好比你在開發某個投票系統，它有不少的步驟，而且這些步驟之間是有聯繫的，好比第一步會將某些信息發送給第二步，第二步緩存了這些信息，同時將自身的信息發送給了第三步。。。。。等等，若是此時用戶處在第三步驟下，咱們想象一下某個淘氣用戶的用戶點擊了後退按鈕，此時屏幕出現了第二步驟的頁面，他再次的修改或者再次的提交，進入到下一個步驟（也就是第三步驟），錯誤就會在此產生？！什麼錯誤呢？最爲典型的就是這樣的操做直接致使了對於第一個步驟信息的丟失！（若是這樣的信息是依靠Request存放的話，固然你能夠存放在Session或者更大的上下文環境中，但這不是個好主意！關於信息存放的問題，下次在就這個問題詳細的討論）

3、如何處理的問題
固然不少的系統（好比訂票系統從需求上自己是容許我的重複訂票的）是必需要避免重複刷新、重複提交、以及防止後退的問題的，但即便是這樣的問題，也要區分如何處理以及在哪裏處理的（網上只是告訴你如何處理，但不多去區分在哪裏處理的），顯然處理的方式無非是客戶端或者服務器端兩種，而面對不一樣的位置處理的方式也是不一樣的，但有一點要事先聲明：任何客戶端（尤爲是B/S端）的處理都是不可信任的，最好的也是最應該的是服務器端的處理方法。

客戶端處理：
面對客戶端咱們可使用Javascript腳原本解決，以下

一、重複刷新、重複提交
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">

Way Two : 將提交按鈕或者image置爲disable
<html:form action="myAction.do" method="post"
onsubmit="getElById('submitInput').disabled = true; return true;">
<html:image styleId="submitInput" src="images/ok_b.gif" border="0" />
</html:form>

二、防止用戶後退
這裏的方法是千姿百態，有的是更改瀏覽器的歷史紀錄的，好比使用window.history.forward()方法;有的是「用新頁面的URL替換當前的歷史紀錄，這樣瀏覽歷史記錄中就只有一個頁面，後退按鈕永遠不會變爲可用。」好比使用javascript:location.replace(this.href); event.returnValue=false;

三、服務器端的處理（這裏只說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) {
return (null);
}
}

總結
對於重複提交、重複刷新、防止後退等等都是屬於系統爲避免重複記錄而須要解決的問題，在客戶端去處理須要針對每一種的可能提出相應的解決方案，然而在服務器端看來只不過是對於數據真實性的檢驗問題，基於令牌的處理就是一勞永逸的方法。

同時咱們也看到，從不一樣的角度去看待問題，其解決的方法也是不一樣的。客戶端更追求的是用戶的操做，而服務端則將注意力放在了數據的處理上，因此在某個對於服務器端看似容易的問題上，用客戶端來解決卻麻煩了不少！反之依然。因此在某些問題的處理上咱們須要綜合考慮和平衡，是用客戶端來解決？仍是用服務器端來處理？