資源描述：
《使用struts的token機制解決表單的重復(fù)提交》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。
1、使用Struts的Token機制解決表單的重復(fù)提交Struts的Token（令牌）機制能夠很好的解決表單重復(fù)提交的問題，基本原理是：服務(wù)器端在處理到達的請求之前，會將請求中包含的令牌值與保存在當(dāng)前用戶會話中的令牌值進行比較，看是否匹配。在處理完該請求后，且在答復(fù)發(fā)送給客戶端之前，將會產(chǎn)生一個新的令牌，該令牌除傳給客戶端以外，也會將用戶會話中保存的舊的令牌進行替換。這樣如果用戶回退到剛才的提交頁面并再次提交的話，客戶端傳過來的令牌就和服務(wù)器端的令牌不一致，從而有效地防止了重復(fù)提交的發(fā)生。這時其實也就是兩點，第一：
2、你需要在請求中有這個令牌值，請求中的令牌值如何保存，其實就和我們平時在頁面中保存一些信息是一樣的，通過隱藏字段來保存，保存的形式如：〈inputtype="hidden"name="org.apache.struts.taglib.html.TOKEN"value="6aa35341f25184fd996c4c918255c3ae"〉，這個value是TokenProcessor類中的generateToken()獲得的，是根據(jù)當(dāng)前用戶的sessionid和當(dāng)前時間的long值來計算的。第二：在客戶端提交后，我
3、們要根據(jù)判斷在請求中包含的值是否和服務(wù)器的令牌一致，因為服務(wù)器每次提交都會生成新的Token，所以，如果是重復(fù)提交，客戶端的Token值和服務(wù)器端的Token值就會不一致。下面就以在數(shù)據(jù)庫中插入一條數(shù)據(jù)來說明如何防止重復(fù)提交。在Action中的add方法中，我們需要將Token值明確的要求保存在頁面中，只需增加一條語句：saveToken(request);，如下所示：publicActionForwardadd(ActionMappingmapping,ActionFormform,HttpServletRe
4、questrequest,HttpServletResponseresponse)//前面的處理省略saveToken(request);returnmapping.findForward("add");}在Action的insert方法中，我們根據(jù)表單中的Token值與服務(wù)器端的Token值比較，如下所示：publicActionForwardinsert(ActionMappingmapping,ActionFormform,HttpServletRequestrequest,HttpServletResp
5、onseresponse)if(isTokenValid(request,true)){//表單不是重復(fù)提交//這里是保存數(shù)據(jù)的代碼}else{//表單重復(fù)提交saveToken(request);//其它的處理代碼}}2222222222222222222222222222222222222222222222222222222222222222222221。重復(fù)提交、重復(fù)刷新的場景重復(fù)提交、重復(fù)刷新都是來解決系統(tǒng)重復(fù)記錄的問題。也就是說某個人在多次的提交某條記錄（為什么？也許是閑了沒有事情干的;最有可能是用戶
6、根本就不知道自己的提交結(jié)果是否已經(jīng)執(zhí)行了？?。?。但出現(xiàn)了這樣的問題并不見得就必須處理，要看你所開發(fā)的系統(tǒng)的類別而定。比如你接手的是某個資源管理系統(tǒng)，系統(tǒng)本身從需求的角度根本就不允許出現(xiàn)"重復(fù)"的記錄，在這樣需求的約束條件下，去執(zhí)行重復(fù)的提交動作只會引發(fā)“業(yè)務(wù)級異?！钡漠a(chǎn)生，根本就不可能執(zhí)行成功也就無所謂避免不避免的問題了。2。防止后退的場景了解了重復(fù)刷新、重復(fù)提交的場景，我們來了解一下"防止后退"操作的原因是什么？比如你在開發(fā)某個投票系統(tǒng)，它有很多的步驟，并且這些步驟之間是有聯(lián)系的，比如第一步會將某些信息發(fā)送給
7、第二步，第二步緩存了這些信息，同時將自身的信息發(fā)送給了第三步。。。。。等等，如果此時用戶處在第三步驟下，我們想象一下某個淘氣用戶的用戶點擊了后退按鈕，此時屏幕出現(xiàn)了第二步驟的頁面，他再次的修改或者再次的提交，進入到下一個步驟（也就是第三步驟），錯誤就會在此產(chǎn)生？！什么錯誤呢？最為典型的就是這樣的操作直接導(dǎo)致了對于第一個步驟信息的丟失?。ㄈ绻@樣的信息是依靠Request存放的話，當(dāng)然你可以存放在Session或者更大的上下文環(huán)境中，但這不是個好主意！關(guān)于信息存放的問題，下次在就這個問題詳細的討論）三。如何處理的
8、問題當(dāng)然很多的系統(tǒng)（比如訂票系統(tǒng)從需求上本身是允許個人重復(fù)訂票的）是必須要避免重復(fù)刷新、重復(fù)提交、以及防止后退的問題的，但即使是這樣的問題，也要區(qū)分如何處理以及在哪里處理的（網(wǎng)上只是告訴你如何處理，但很少去區(qū)分在哪里處理的），顯然處理的方式無非是客戶端或者服務(wù)器端兩種，而面對不同的位置處理的方式也是不同的，但有一點要事先聲明：任何客戶端（尤其是B/S端）的處理都是不可信任的，最好的也是
