jsp重複提出問題(インターネットから)

ネットを見ましたが、いくつかの方法があります.1あなたのフォームページに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を繰り返してあなたのサーバ端ハンドルのコードにReponse.Redirect(「selfPage」文)を使用する.しかし、多くの数はこの方法を使わない.方法はまだたくさんあります.4
5
JSPページのFORMフォームにhiddenドメイン<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> 

    、    、             

一.はじめに、どの比較専門のBBSでもこのような問題が見られます.Googleを使ってみても、多くの人が関心と質問をしていることが分かります.しかし、皆さんの解決方法は千差万別です.なぜこのような大きな違いがありますか?
二番目です.問題のシーンはまず、なぜこのような問題を解決しますか?あるいは専門的なポイントはその適当なシーンは何ですか?(説明する人がいないと聞きに来ただけのようです.)
1です.繰り返し提出、繰り返し更新するシーンの繰り返し提出、繰り返し更新は、システムの重複記録の問題を解決するためです.つまり、ある人が何度も何度も何度も記録を提出しています.
しかし、このような問題が発生したら必ず解決しなければならないとは限りません.あなたが開発したシステムの種類によって決められます.例えば、あなたが引き継ぐのはある資源管理システムです.システム自体は必要な角度から「重複」の記録が現れてはいけません.このような要求の制約の下で、重複した提出動作を実行すると、「業務レベル異常」が発生するだけで、成功することが不可能です.
2です.後退防止のシーンは繰り返し更新し、繰り返し提出するシーンが分かりました.「後退防止」の原因は何ですか?例えば、ある投票システムを開発しています.たくさんのステップがあります.そして、これらのステップの間には連絡があります.例えば、第一歩はいくつかの情報を第二ステップに送ります.第二ステップはこれらの情報をキャッシュして、自分の情報を第三ステップに送りました..など、この時、ユーザーが第三のステップである場合、あるいたずらっ子のユーザーが後退ボタンを押したことを想像します.この時、画面に第二のステップのページが現れました.彼は再度修正したり、または再度提出したりして、次のステップ(つまり第三のステップ)に進みます.エラーはここで発生しますか?何の間違いですか?最も典型的なのはこのような操作が直接に第一段階の情報をなくしてしまうことをもたらします.(このような情報がRequestによって保存されているなら、Sessionまたはより大きなコンテキスト環境において保存することもできますが、これはいい考えではありません.情報の保存については、次回はこの問題について詳細に議論します.)
三番目です.どのように処理するかという問題はもちろん多くのシステム(例えば、チケット予約システムは需要上、個人の重複予約が許されている)であり、繰り返し更新、繰り返し提出、後戻り防止の問題を避ける必要があります.しかし、このような問題でも、どのように処理するかとどこで処理するかを区別しなければなりません.明らかに処理の仕方はクライアントまたはサーバー端末の2つにすぎないが、異なる位置に対して処理の仕方も異なるが、事前に声明しなければならない点がある.どのクライアント(特に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" onsubmit="return checkSubmit();">

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>

 
2です.ユーザーの後退を防ぐ方法は多彩で、ブラウザの歴史記録を変更するものもあります.例えば、ウィンドウズ.ヒットマン.forwardを使う方法です.あるものは「現在の履歴を新しいページのURLに置き換える.このように履歴を見ると一つのページしかない.後退ボタンはいつまでも使えます.」例えば、javascript:location.replace(this.href)を使う.event.return Value=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クラスのgeneratoken()方法を参照することができる.
1.//検証トランザクション制御トークン、<>form>は自動的にsessionによって識別され、1つの暗黙的input代表トークンを生成し、2回の提出を防ぐ.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);
}
}

 
まとめは、繰り返し提出、繰り返し更新、後退防止などは、システムが繰り返し記録を回避するために解決すべき問題であり、クライアントで処理するには、それぞれの可能性に応じた解決策を提示する必要があるが、サーバ側から見ると、データの真実性を検証するための問題にすぎず、トークンによる処理は一苦労永逸の方法である.
同時に私達も異なった角度から問題を見て、その解決の方法も異なっていることを見ます.クライアントはユーザーの操作をより追求していますが、サーバー側はデータの処理に注意を払っていますので、サーバー側にとっては易しいような問題で、クライアントで解決するのは大変です.逆もまた然り.したがって、いくつかの問題の処理について総合的に考慮し、バランスを取る必要があります.クライアントで解決するのですか?それともサーバー側で処理しますか?