1

コマンドボタンをクリックし、ブラウザの戻るボタンを押してフォームに再度クリックすると、適切な例外をスローせずに2回目の送信が行われます...

さらに奇妙なことに、私が戻ってきたときのフォームID自体は異なります。これは、ある時点で「有効な」フォームIDが再生成されたことを意味します。

関連するコードは次のとおりです。アイデアはありますか？

<h:form id="accountActivationForm">
    <s:token/>
    <a4j:commandButton id="cancelActivateAccountButton"
        action="#{controller[cancelAction]}"
    image="/images/button-Cancel-gray.gif"
        reRender="#{reRenderList}"
        oncomplete="#{onCancelComplete}" />
        &#160;
    <a4j:commandButton id="activateAccountButton"
        action="#{controller[agreeAction]}"
        image="/images/button-i-agree-continue.gif"
        styleClass="activate-account-button"
        reRender="#{reRenderList}"
        oncomplete="#{onActivationComplete}"/>
</h:form>

明確化：

  • これを継承したので、できるだけ変更しないようにしています。（いくつかの場所で使用されています。）
  • 各アクションは、nullではなくビューを返します。私はこれを行ごとにステップスルーすることで確認しました。
  • 私の現在のテストケースでは、reRenderListは空です。
  • onActivationCompleteも空です。

テンプレートごとに、誰かがネストされたフォームでそれを作成したかどうかを確認します。これは、同僚がそれによって無関係の問題を抱えていたため、考えられる問題としてそれを排除するのに害はありませんでした。

4

1 に答える 1

2

はs:token、同じリクエストで送信ボタンを何度もイライラしてクリックするか、ウェブブラウザでリダイレクトされていない結果を更新するか、ブラウザの履歴にキャッシュされたページを再送信することで、二重/複数の送信を回避することになっています。

クライアントがブラウザの履歴で前後に移動するときに機能するということは、フォームを含むページがクライアントのブラウザの履歴にキャッシュされず、サーバー側から新しいものとして再度要求されることを意味します。それは確かに新しいトークンを返します。FirebugにあるようなHTTPトラッカーで自分で確認してください。

于 2010-05-23T11:13:57.390 に答える