繰り返し送信、繰り返し更新、バックオフ防止に関する問題と解決策の分析

1つ。序文<br />この種の質問は、どの専門掲示板でも見かけます。Google で検索しても、多くの人が注目し、質問していることがわかります。しかし、彼らが提示する解決策は非常に異なります。(スクリプトを使用して解決することを提唱する人もいれば、他のページにリダイレクトすることを望む人もいれば、トークンの観点から問題を提起する人もいます。) なぜ、これほど大きな違いがあるのでしょうか。
二。問題のシナリオ<br />まず、なぜこのような問題に対処する必要があるのかを理解する必要があります。あるいは、もっと専門的に言えば、どのようなシナリオに適していますか? （質問する人ばかりで説明に来る人はいないようです）
1.繰り返し送信と繰り返し更新のシナリオ繰り返し送信と繰り返し更新は、どちらもシステム内の重複レコードの問題を解決するためのものです。つまり、誰かがレコードを複数回送信します (なぜでしょうか? おそらく何もすることがないのでしょう。おそらく、ユーザーは送信の結果が実行されたかどうかさえ知らないのでしょう?!)。
ただし、このような問題に対処する必要はありません。開発しているシステムの種類によって異なります。たとえば、リソース管理システムを担当している場合、システム自体は需要の観点から「重複」レコードを許可しません。このような需要制約の下では、繰り返し送信アクションを実行すると「ビジネスレベルの例外」がトリガーされるだけで、正常に実行できなくなるため、問題を回避できるかどうかを心配する必要はありません。
2.後方への防止のシナリオ繰り返し更新と繰り返し送信のシナリオについて理解できたので、「後方への防止」操作の理由を理解しましょう。たとえば、投票システムを開発している場合、そのシステムには多くのステップがあり、これらのステップは互いに関連しています。たとえば、最初のステップでは特定の情報を 2 番目のステップに送信し、2 番目のステップではこの情報をキャッシュし、独自の情報を 3 番目のステップに送信します。。。。。待ってください、この時点でユーザーが 3 番目のステップにいる場合、いたずらなユーザーが戻るボタンをクリックし、2 番目のステップのページが画面に表示されたとします。彼は再度変更または送信し、次のステップ (つまり 3 番目のステップ) に入ります。ここでエラーが発生しますか? ！どうしたの？最も典型的なケースは、このような操作によって最初のステップに関する情報が直接失われることです。（このような情報がリクエストに格納されている場合、もちろんセッションやより大きなコンテキストに格納することもできますが、これは良い考えではありません！情報の保存の問題については、次回この問題について詳しく説明します）
三つ。問題への対処方法
もちろん、多くのシステム (たとえば、チケット予約システム自体では、個人が繰り返し予約を行うことができます) では、繰り返しの更新、繰り返しの送信を避け、バックオフの問題を防ぐ必要があります。しかし、そのような問題であっても、どのように処理するか、どこで処理するかを区別する必要があります (インターネットでは、処理方法のみが示され、どこで処理するかが区別されることはほとんどありません)。明らかに、処理方法はクライアント側とサーバー側の 2 つしかなく、処理方法は場所によって異なります。ただし、事前に述べておく必要があるのは、クライアント側 (特に B/S 側) での処理は信頼できないため、サーバー側で処理する方法が最も適切であるということです。
クライアント側の処理:
クライアントに直面したとき、次のようにJavascriptスクリプトを使用して解決できます。
1.繰り返し更新、繰り返し送信
方法 1: 送信を 1 回だけ許可するように変数を設定します。

コードをコピー

コードは次のとおりです。

<スクリプト言語="javascript">
var checkSubmitFlg = false;
関数 checkSubmit() {
チェック送信フラグが true の場合
false を返します。
}
チェック送信フラグ = true;
true を返します。
}
document.ondblclick = 関数 docondblclick() {
ウィンドウイベントの戻り値は false です。
}
document.onclick = 関数 doc {
if (チェック送信フラグ) {
ウィンドウイベントの戻り値は false です。
}
}
</スクリプト>
<html:form action="myAction.do" method="post" onsubmit="return checkSubmit();">
方法2: 送信ボタンまたは画像を無効にする
<html:form アクション="myAction.do" メソッド="post"
onsubmit=" getElById_r('submitInput').disabled = true; 戻り値 true;">
<html:image styleId="submitInput" src="images/ok_b.gif" border="0" />
</html:フォーム>

2.ユーザーが戻ることを防ぐ方法はたくさんあります。window.history.forward() メソッドを使用するなど、ブラウザの履歴を変更する方法や、現在の履歴を新しいページの URL に置き換えて、閲覧履歴に 1 ページだけ残り、戻るボタンが使用できなくなるようにするなどの方法があります。たとえば、javascript を使用します: location.replace(this.href); event.returnValue=false;

2. サーバー側の処理（ここではStrutsフレームワークの処理のみを説明します）
Struts は、同期トークンメカニズムを使用して Web アプリケーションでの繰り返し送信の問題を解決するためのリファレンス実装も提供します。
基本原則:
受信したリクエストを処理する前に、サーバーはリクエストに含まれるトークン値と現在のユーザーセッションに保存されているトークン値を比較します。
一致するかどうか確認してください。リクエストが処理され、応答がクライアントに送信される前に、新しいトークンが生成されます。クライアントに渡されるだけでなく、ユーザーセッションに保存されている古いトークンも置き換えられます。この方法では、ユーザーが前の送信ページに戻って再度送信すると、クライアントから送信されたトークンはサーバー上のトークンと一致しなくなり、重複した送信が効果的に防止されます。
if (isTokenValid(リクエスト、true)) {
// ここにコードを記述
マッピング.findForward("成功"); を返します。
} それ以外 {
saveToken(リクエスト);
マッピング.findForward("submitagain"); を返します。
}
Strutsは、ユーザーセッションIDと現在のシステム時間に基づいて、セッションごとに一意のトークンを生成します。具体的な実装については、
TokenProcessor クラスの generateToken() メソッド。
1. //トランザクション制御トークンを検証します。<html:form> は、セッション内の識別子に基づいて暗黙の入力代表トークンを自動的に生成し、二重送信を防ぎます。
2. アクションでは：

//<input type="hidden" name="org.apache.struts.taglib.html.TOKEN"
// 値="6aa35341f25184fd996c4c918255c3ae">
if (!isTokenValid(リクエスト))
エラー.add(ActionErrors.GLOBAL_ERROR,
新しい ActionError("error.transaction.token"));
resetToken(request); //セッション内のトークンを削除する
3. アクションにはトークンを生成するメソッドがある
保護された文字列generateToken(HttpServletRequestリクエスト) {
HttpSession セッション = request.getSession_r();
試す {
バイトID[] = session.getId_r().getBytes_r();
バイト現在[] =
新しい Long(System.currentTimeMillis()).toString().getBytes_r();
メッセージダイジェスト md = MessageDigest.getInstance_r("MD5");
md.update(id);
md.update(今);
戻り値 (toHex(md.digest()));
} キャッチ (IllegalStateException e) {
戻り値 (null);
} キャッチ (NoSuchAlgorithmException e) {
戻り値 (null);
}
}
まとめると、繰り返しの送信、繰り返しの更新、バックオフの防止はすべて、重複レコードを回避するためにシステムが解決する必要がある問題です。クライアント側でこれらを処理するには、それぞれの可能性に対応するソリューションを提案する必要があります。ただし、サーバー側から見ると、データの信頼性を検証するだけの問題です。トークンベースの処理は、一度限りの方法です。
同時に、問題をさまざまな角度から見ると、さまざまな解決策につながることもわかります。クライアントはユーザーの操作に重点を置いていますが、サーバーはデータの処理に重点を置いています。そのため、サーバーにとっては簡単に思える問題でも、クライアントにとっては解決がはるかに困難になります。逆もまた真なりです。では、特定の問題に対処する際には、総合的な考慮とバランスをとる必要がありますが、クライアントを利用して解決すべきでしょうか?それともサーバー側で処理されますか?

Web ページの更新防止、重複送信、逆送信防止ソリューション、送信後に送信ボタンを無効にする (ほとんどの人がこれを実行します)
顧客が送信後に F5 キーを押して更新するとどうなりますか?
セッションの使用
送信されたページがデータベースによって処理される前に:
セッション("ok")=trueの場合
response.write "エラー、送信中"
レスポンス終了
終了の場合
データが処理されたら、session("ok")=false を変更します。
データ処理が成功して更新された直後に別のページにリダイレクトするのは確かに問題です。ジャンプページを使用してこのページを閉じることができます。パラメータデータ条件によって制御されている場合は、簡単に実行できるはずです。window.location の値を直接変更し、すべてのパラメータを変更できます。これでほぼ完了です。
デメリット: ユーザーがあるページから別のページに移動すると、クライアントコードで location.history をクリアする必要があるため、Response.Redirect を単純に使用しても機能しなくなります。このメソッドは、すべてのアクセスレコードではなく、最後のアクセス履歴レコードをクリアすることに注意してください。戻るボタンをクリックし、もう一度戻るボタンをクリックすると、現在開いているページがこのページの前のページであることがわかります。 (もちろん、これはクライアント側で JavaScript が有効になっていることを前提としています。)
顧客が押し返した場合はどうなりますか?

ウェブページが戻らないようにする - キャッシュを無効にするデータベースに追加しているときに、戻ることを許可していて、ページが更新された場合、追加操作が再度実行されます。これは間違いなく必要なことではありません。インターネット上のキャッシュを禁止する多くのコードと同様に、それらは信頼できない場合があります。現時点では、操作ページに追加し、ウェブページでリダイレクトする新しいページを指定してから、[戻る] をクリックして、前の操作ページに戻らないかどうかを確認するだけです。実際、この履歴は削除されています。
平均価格:
レスポンス.バッファ = True
Response.ExpiresAbsolute = Now() - 1
レスポンス.有効期限 = 0
Response.CacheControl = "キャッシュなし"
ASP.NET:
レスポンス.Buffer=true;
Response.ExpiresAbsolute=DateTime.Now.AddSeconds(-1);
レスポンス.Expires=0;
Response.CacheControl="キャッシュなし";
ブラウザの戻るボタンを「無効」にするにはどうすればいいでしょうか?または「ユーザーが戻るボタンをクリックして以前に表示したページに戻れないようにするにはどうすればよいですか？」
残念ながら、ブラウザの戻るボタンを無効にすることはできません。
Web ページが戻らないようにします - window.open を使用して、新しく開いたウィンドウにフォームページをポップアップし、送信をクリックした後にページを閉じます。送信を処理する ASP ページもポップアップを使用し、フォームのターゲットを設定し、window.open("XXX.asp","_blank") をクリックし、次に JS を使用してフォームを送信し、完了後に window.close() を実行します。
簡単に言えば、フォームが送信されると、新しいウィンドウがポップアップ表示され、現在のウィンドウが閉じられます。 window.open() によって開かれたウィンドウを縮小するにはどうすればよいでしょうか?どこに退避できますか?
ハハハ、意味不明なことたくさん言ってしまいました。どう対処すればいいか分かりますか？クライアント側スクリプトとサーバー側スクリプトを混在させます。

私は jsp の繰り返し送信に関するオンライン記事を読み、いくつかの方法を見つけました。
1 フォームページのHEAD領域に次のコードを追加します。
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, must-revalidate">
<META HTTP-EQUIV="有効期限" CONTENT="水曜日、1997 年 2 月 26 日 08:21:57 GMT">
2
トークンを生成し、ユーザーセッションに保存します。フォームに隠しフィールドを追加して、トークンの値を表示します。フォームが送信されると、新しいトークンが再生成されます。ユーザーが送信したトークンとセッション
比較内のトークンは同じ場合は繰り返されます。
3
サーバー側コントロールのコードで Response.Redirect("selfPage") ステートメントを使用します。しかし、ほとんどの数字ではこのアプローチは使用されません。
他にもたくさんの方法があります。。。
4
<input type="button" value="送信" onclick="this.disabled=true;this.form.submit()">
5
JSPページのFORMフォームに隠しフィールドを追加する
<input type="hidden" name="url"value=<%=request.getRequestURL_r()%>>

サーバーレットに次の文を追加します
文字列 url=request.getParameter_r("url");
レスポンスをリダイレクトします。
私は通常、この方法を使用して JSP ページに戻ります。繰り返し更新するというのはどういう意味なのかよくわかりません。
6 ajax 更新なし送信
7 Web 開発において、ブラウザの更新キーによってシステム操作が繰り返し送信されるのを防ぐにはどうすればよいでしょうか?リダイレクトは、ページの更新によってデータが繰り返し送信される問題を解決できます。当然、リダイレクトを使用してこの問題を解決できます。ただし、Struts アクションでマッピング.findword() を使用してジャンプする場合、デフォルトではプロジェクトフォルダー内でジャンプ先のページが検索されます。この状況をどう解決すればいいのでしょうか?
struts-config.xml ファイルを変更します。action にはリダイレクト属性があります。struts のデフォルト値は false です。この属性を追加し、true に変更します。forword にリダイレクトするページの絶対アドレスまたは相対アドレスを記述します。次のように変更します。
<アクションマッピング>
<アクション属性="newsActionForm" 名前="newsActionForm"
入力="/addnews.jsp" パス="/newsAction" パラメータ="メソッド"
スコープ="リクエスト" タイプ="com.yongtree.news.action.NewsAction">
<forward name="list" path="/listnews.jsp" redirect="true"></forward>
<forward name="error" path="/addnews.jsp"></forward>
</アクション>
</アクションマッピング>

ブラウザの戻るボタンを使用すると、以前にアクセスしたページに簡単に戻ることができるため、非常に便利です。ただし、ユーザーがページ訪問のスケジュールされた順序を乱さないように、この機能をオフにしなければならない場合もあります。この記事では、インターネット上で見つかるブラウザの戻るボタンを無効にするさまざまな解決策を紹介し、それぞれの長所と短所、適用可能な場面を分析します。
1. 概要

「ブラウザの戻るボタンを「無効」にするにはどうしたらいいですか？」や「ユーザーが戻るボタンをクリックして、以前に閲覧したページに戻れないようにするにはどうしたらいいですか？」という質問が多く寄せられています。この質問は、ASP フォーラムで最も多く寄せられる質問の 1 つでもあります。残念ながら、答えは非常に簡単です。ブラウザの戻るボタンを無効にすることはできません。
最初は、ブラウザの戻るボタンを無効にしたい人がいることに驚きました。その後、多くの人が戻るボタンを無効にしたいと考えていることがわかり、ほっとしました (ブラウザの進むボタンではなく、戻るボタンのみを無効にしたいと考えていました)。デフォルトでは、フォームを送信した後、ユーザーは「編集」ボタンを使用する代わりに戻るボタンを使用してフォームページに戻り、フォームを再度編集して送信し、データベースに新しいレコードを挿入できます。これは私たちが見たくないものです。
そこで私はこの状況を避ける方法を見つけることにしました。多くのウェブサイトを訪問し、そこで紹介されているさまざまな実装方法を参考にしました。 ASP プログラミングの Web サイトをよく訪れる方であれば、この記事で紹介したコンテンツのいくつかをご覧になったことがあるかもしれません。この記事の目的は、すべての可能な方法を皆さんに紹介し、その中から最良の方法を見つけることです。
2. キャッシュを無効にする私が見つけた多くの解決策の中で、ページキャッシュを無効にすることを提案するものがありました。具体的には、サーバー側スクリプトを次のように使用します。
<%
レスポンス.バッファ = True
Response.ExpiresAbsolute = Now() - 1
レスポンス.有効期限 = 0
Response.CacheControl = "キャッシュなし"
%>
この方法は非常に効果的です！ブラウザは、キャッシュからページを読み込むのではなく、サーバーに再度アクセスしてページをダウンロードするようになります。このアプローチを使用する場合、プログラマーの主なタスクは、ユーザーが戻るボタンからアクセスできないページをまだ表示できるかどうかを決定するセッションレベルの変数を作成することです。ブラウザにはページがキャッシュされていないため、ユーザーが戻るボタンをクリックすると、ブラウザはページを再度ダウンロードし、プログラムはセッション変数をチェックして、ユーザーがページを開くことを許可するかどうかを確認します。

たとえば、次のフォームがあるとします。

<%
レスポンス.バッファ = True
Response.ExpiresAbsolute = Now() - 1
レスポンス.有効期限 = 0
Response.CacheControl = "キャッシュなし"
Len(Session("FirstTimeToPage")) > 0の場合
&single; ユーザーは現在のページにアクセスしており、再度アクセスしようとしています。
&single; セッション変数をクリアし、ユーザーをログインページにリダイレクトします。
セッション("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
レスポンス終了
終了条件
&single; プログラムがここで実行されると、ユーザーは現在のページを表示できることを意味します
&single; フォームの作成を始めましょう
%>
<フォームメソッド=投稿アクション="SomePage.asp">
<入力タイプ=送信>
</フォーム>

セッション変数 FirstTimeToPage を使用して、ユーザーが現在のページに初めてアクセスしたかどうかを確認します。初めてでない場合（つまり、Session("FirstTimeToPage") に値が含まれている場合）、セッション変数の値をクリアし、ユーザーを開始ページにリダイレクトします。したがって、フォームが送信されるとき (SompePage.asp が開かれるとき)、FirstTimeToPage に値を割り当てる必要があります。つまり、SomePage.asp に次のコードを追加する必要があります。
セッション("FirstTimeToPage") = "いいえ"
この方法では、SomePage.asp を開いたユーザーが [戻る] ボタンをクリックすると、ブラウザーはサーバーにページのダウンロードを再度要求します。サーバーは Session("FirstTimeToPage") に値が含まれていることを確認し、Session("FirstTimeToPage") をクリアしてユーザーを別のページにリダイレクトします。もちろん、これらすべてを行うには、ユーザーが Cookie を有効にする必要があります。そうでない場合、セッション変数は無効になります。 (この問題の詳細な説明については、「セッション変数が機能するには、Web 訪問者が Cookie を有効にする必要がありますか?」を参照してください。)
あるいは、クライアント側のコードを使用して、ブラウザが Web ページをキャッシュしないようにすることもできます。
<html>
<ヘッド>
<meta http-equiv="有効期限" CONTENT="0">
<meta http-equiv="キャッシュコントロール" CONTENT="キャッシュなし">
<meta http-equiv="プラグマ" CONTENT="キャッシュなし">
</head>
上記の方法を使用してブラウザが Web ページをキャッシュしないように強制する場合は、次の点に注意する必要があります。

「Pragma: no-cache」は、安全な接続を使用している場合にのみブラウザがページをキャッシュするのを防ぎます。保護されていないページの場合、「Pragma: no-cache」は「Expires: -1」と同じように扱われ、その場合、ブラウザは引き続きページをキャッシュしますが、すぐに期限切れとしてマークします。 IE 4 または 5 では、「Cache-Control」META HTTP-EQUIV タグは無視され、効果がありません。
実際のアプリケーションでは、これらすべてのコードを追加できます。ただし、この方法はすべてのブラウザで機能するわけではないため、推奨されません。しかし、イントラネット環境であれば、管理者はユーザーが使用するブラウザを制御できるため、この方法を使用する人もいると思います。
3. その他の方法

次に説明するアプローチは、ブラウザのキャッシュではなく、戻るボタン自体を中心にしたものです。参照する価値のある記事「戻るボタンの再配線」があります。しかし、この方法を使用すると、ユーザーが戻るボタンを 1 回クリックしても、以前にデータを入力したページは表示されず、2 回クリックするだけで済むことに気付きました。これは、多くの場合、頑固なユーザーが常に予防措置を回避する方法を見つけることができるため、望ましい効果ではありません。
戻るボタンを無効にする別の方法は、クライアント側の JavaScript を使用してツールバーのないウィンドウを開くことです。これにより、ユーザーが前のページに戻ることが難しくなりますが、不可能ではありません。より安全ですが、かなり面倒な方法は、フォームが送信されたときに新しいウィンドウを開き、同時にフォームを含むウィンドウを閉じることです。しかし、ユーザーがフォームを送信するたびに新しいウィンドウを開くことはできないため、このアプローチは真剣に検討する価値がないと思います。
では、ユーザーに再度アクセスしてほしくないページに JavaScript コードを追加できるでしょうか?このページに追加された JavaScript コードを使用すると、進むボタンをクリックする効果を生成し、ユーザーが戻るボタンをクリックすることによって生成されるアクションを相殺することができます。この機能を実装するために使用されるJavaScriptコードは次のとおりです。

図示のとおり:
<スクリプト言語="JavaScript">

</スクリプト>
繰り返しますが、このアプローチは機能しますが、「最善のアプローチ」とは程遠いものです。その後、あるページから別のページに移動するには location.replace を使用するという提案を誰かがしているのを見ました。この方法の原理は、現在の履歴レコードを新しいページの URL に置き換えて、閲覧履歴にページが 1 つだけ残り、[戻る] ボタンが使用できなくなるようにすることです。これは多くの人が求めているものかもしれないと思いますが、それでもあらゆる状況に最適なアプローチとは言えません。このアプローチを使用した例を以下に示します。
<A HREF="PageName.htm" onclick="javascript:location.replace(this.href);
event.returnValue=false;">このページに戻るためのリンクを無効にする</A>
このページへのバックリンクは禁止です！
このアプローチの欠点は、ユーザーがページ間を移動するたびにクライアント側コードで location.history をクリアする必要があるため、単純に Response.Redirect を使用するだけでは機能しなくなることです。また、この方法ではすべてのアクセスレコードがクリアされるのではなく、最後のアクセス履歴がクリアされることに注意してください。
上記のリンクをクリックすると、シンプルな HTML ページが開きます。もう一度戻るボタンをクリックすると、開いているのが現在のページではなく、このページの前のページであることがわかります。 (もちろん、ブラウザでクライアント側の JavaScript を有効にする必要があります。)
慎重に検索してみましたが、ブラウザの戻るボタンを完全に無効にする方法はまだ見つかりませんでした。ここで説明した方法はすべて、ユーザーが前のページに戻ることをさまざまな程度と方法で防ぐことができますが、それぞれに制限があります。戻るボタンを完全に無効にする方法はないので、最善の解決策はクライアント側スクリプトとサーバー側スクリプトを組み合わせることです。

<html>
<ヘッド>
<meta http-equiv="有効期限" CONTENT="0">
<meta http-equiv="キャッシュコントロール" CONTENT="キャッシュなし">
<meta http-equiv="プラグマ" CONTENT="キャッシュなし">
</head>
<スクリプト言語="JavaScript">

</スクリプト>
</html>
Asp.netは、バックオフとリフレッシュを防ぐために、単純な操作方法で繰り返しの送信とバックオフを防止します。
Page_Loadに追加
レスポンス.Cache.SetNoStore();
//セッションに保存されている変数「IsSubmit」は、送信が成功したかどうかを示すために使用されます。
if (!IsPostBack)
if (セッション["IsSubmit"]==null)
Session.Add("IsSubmit",false);
if ((bool)Session["IsSubmit"])
{
//フォームデータが正常に送信された場合は、"Session["IsSubmit"]"をfalseに設定します
セッション["IsSubmit"] = false;
//送信成功情報を表示
TextBox1.Text = " * 正常に送信されました!";
}
それ以外
それ以外の場合（送信されていない、またはページが更新されている場合）、情報は表示されません
TextBox1.Text = "";
レスポンス.End();
}
送信ボタンに追加
セッション["IsSubmit"] = true;
Response.Redirect ("このページ");

加えて：
1. 通常、この問題を解決するには、ビジネスレベルで判断（一意性）を行う必要があります
2. ページ読み込みイベントにResponse.CacheControl = "no-cache"と記述してキャッシュをクリアします。
3. 次のような人もいました。以前にもこのような問題に遭遇したことがあります。段階的に提出された人の履歴書で、1 ページ目を完了すると 2 ページ目にジャンプしました。ユーザーが戻るボタンを使用して最初のページに戻り、最初のページを再送信することを防ぐために、ユーザーが初めて最初のページを送信するときに、データベースに挿入されたレコードの自己増分 ID 番号がセッションに入れられます。ユーザーが 2 ページ目から 1 ページ目に戻り、再度ページを送信すると、セッション内の値を使用してデータベースをチェックします。ID が見つかった場合は、update ステートメントを使用して 1 ページ目のデータをデータベースに書き込みます。ID が見つからない場合は、insert ステートメントを使用します。

<<: CSSを使用してHTMLテキストボックス内のテキストの垂直方向の中央を制御する

>>: JavaScript の組み込み Date オブジェクトの詳細な説明