JSFで２重Submit対策 - システム開発で思うところ

一般的な２重Submitは、hiddenで保持したトークンとサーバのセッションで保持しているトークンを比較する、というやり方だと思います。

さいきょうの二重サブミット対策 - Qiita

これは、これで正しいと思いますし、多くの人が知っているであろうやり方なので検索性も良いと思います。

ですが、Jakarta EE には ConversationScoped があります。

画面単位（タブ単位）でイイ感じに情報を管理してくれるスコープがありますので、それを前提としたやり方で試してみたいと思います。

「そもそもConversation自体が面倒なんですが」ということについては、以前の記事の「フォルダ単位で会話スコープを制御する」を使用する前提です。

vermeer.hatenablog.jp

やりたいこと

２重Submit不可のトリガーとなるアクションを操作したら、以降同アクションを操作したらエラーにする
エラー判定後の操作として、メッセージ出力または画面遷移先指定（もしくは２つの組み合わせ）を指定できるようにする
デフォルトは「何もしない」
アノテーションによって宣言的にする

仕様の補足

エラー判定後の操作

エラー画面への遷移だけでなく、メッセージ出力とした理由は、確認画面をそのまま流用できるようにして実装負担を減らせる仕組みを設けた方が良いだろうと思ったためです。

もちろん、エラーではなく「登録は完了しています」というようなメッセージにしてユーザー自身による２重登録防止にする、というやり方もあるでしょう。

画面遷移は、単純にエラー画面への遷移というだけでなくて f:viewActionで初期表示イベントによる操作が出来るので複雑なことも可能です。

具体的には、f:viewActionでアクションと紐づけをして、ケース分けから自画面とそれ以外の画面への振り分けや、ログ出力やエラー通知などをするイメージです。

アノテーションで宣言的

上述のように、複雑なロジックが必要なことは「遷移先画面の指定」で実現すると割り切って、あくまでアプリケーションの実装としてはアノテーションによる宣言のみです。

当初、細かい操作ができるようにした方が良いかなぁ、と考えて HandlerClassを設けて、それをInjetする方法も考えたのですが遷移先画面を任意で指定できるようにする上述のやり方であれば、結果として好きなように実装できると考えてこのやり方で落ち着きました。

また２重Submit対策はドメイン知識とは別の話なので、そういうものは極力「ロジック」に紛れ込まないようにする、つまり宣言的にしておく方が最適だと考えました。

デフォルトの挙動

２回目の操作時に「何もしない」をデフォルトとした理由は、プロダクトによって指針が大きく異なると考えたためです。

つまり、お試し実装の範疇では、固定的な実装はしない、としました。

もし、エラーメッセージを出力することをデフォルトにしたければ、@ExcuteOnceのmessageのデフォルト値でメッセージＩＤを指定するなり、ExecuteOnceInterceptorのメッセージ編集で定数値をしていするなりすれば良いでしょう。

エラー画面ＩＤの指定も同様の対応で対処可能です。

方式の補足

状態保持と更新

ExecuteOnceLifecycleでは、内部で状態を保持しています。
その場合のマルチスレッドによる本方式の安全性ですがこれは本クラスをConversationScopedとすることで考慮しています。

後発のリクエスト時にjavax.enterprise.context.BusyConversationExceptionがスローされる仕様になっています。（略）スレッドセーフの考慮は不要です。
パーフェクト Java EE P69

とあるように、EEの仕組みとして状態を安全に保持できる仕組みが設けられています。*1

したがって過度ではないSubmit とブラウザによる戻るで発生しうる2重Submitへの対応とは別に、過度なSubmit（極端な連打）による異常は、BusyConversationExceptionとスローするため不正な登録の実行は発生しません。 *2

会話スコープを任意のタイミングで終了する

上述の過去の記事の実装では、xhtmlのフォルダが変わった時「だけ」がConversationScopeの終了条件でした。

今回のように、同一フローを繰り返したい場合に困ってしまうということで @EndConversationというアノテーションで、任意のタイミングで終了できるようにしました。

これで、入力→確認→完了　をサイクリックに行えるようになります。

ExceptionHandlerWrapper を使わないでも出来た

当初、メソッドに複数のInterceptorが適用される場合、ExecuteOnceInterceptorで対象メソッドを実行しなくても、別のInterceptorによって実行されるかもしれないと考えて、実行時例外によるハンドリングを検討しました。

結論としては、それは杞憂でした。InvocationContext#proceed()によって、Interceptorがchainされるので、優先度上位のInterceptorで InvocationContext#proceed()をcallしなければ、それ以降のInterceptorが適用されることはありませんでした。 *3

使用方法

２重Submitのトリガーとなるアクションに@ExecuteOnceを付与。

以降、@ExecuteOnceが付与されているメソッドは会話スコープが終了するまで実行できなくなります。

できることは @ExecuteOnceによるメッセージ制御か画面遷移のみです。

各パラメータを使用したパターンについては、実行結果で示します。

@ExecuteOnce
public String fwComplete() {
    return "complete.xhtml";
}

実装と実行画面とログ

２回目の操作を無視

何もしません。

デフォルト時の挙動です。このままだとユーザーは困るので、通常は遷移先画面かメッセージ出力をして、何をしたらよいのか誘導した方が良いでしょう。

@ExecuteOnce
public String fwCompleteWithDefault() {
    System.out.println(this.getClass().toString() + "::登録処理を実施");
    return "complete.xhtml";
}

f:id:vermeer-1977:20180512232455p:plain

f:id:vermeer-1977:20180512232150p:plain

f:id:vermeer-1977:20180512232645p:plain

f:id:vermeer-1977:20180512232555p:plain

１回目の「登録（何もしない）」では、問題なく完了画面へ遷移します。

f:id:vermeer-1977:20180512232810p:plain

f:id:vermeer-1977:20180512232834p:plain

「戻る」で前の画面に戻ります。

f:id:vermeer-1977:20180512233018p:plain

f:id:vermeer-1977:20180512233032p:plain

２回目の「登録（何もしない）」をクリックすると登録ログは更新されていきますが、画面は一切変化しないことが確認できます。

f:id:vermeer-1977:20180512233146p:plain

f:id:vermeer-1977:20180512233201p:plain

２回目の操作で完了画面へ遷移

これが一番オーソドックスだと思います。

２度目以降の入力は無視して、とにかく完了画面へ遷移します。

特にエラーメッセージも出力しません。

@ExecuteOnce(forwardPage = "complete.xhtml")
public String fwComplete() {
    System.out.println(this.getClass().toString() + "::登録処理を実施");
    return "complete.xhtml";
}

＜１回目の登録までは省略します＞

f:id:vermeer-1977:20180513083541p:plain

f:id:vermeer-1977:20180513083617p:plain

f:id:vermeer-1977:20180513083302p:plain

エラーメッセージあり

エラーメッセージのみを指定した場合、自分画面へ遷移してメッセージを出力します。

画面上に、継続して処理したい場合のルートの情報をメッセージに出力しないとユーザーは不安になるでしょう。

@ExecuteOnce(message = "メッセージ出力：既に登録済みです。重複登録を抑止しました。トップページへ戻ってください。")
public String fwCompleteWithMessage() {
    System.out.println(this.getClass().toString() + "::登録処理を実施");
    return "complete.xhtml";
}

＜１回目の登録までは省略します＞

f:id:vermeer-1977:20180513083808p:plain

f:id:vermeer-1977:20180513083929p:plain

f:id:vermeer-1977:20180513083956p:plain

エラー画面遷移

本例だと、完了画面とエラー画面の違いは少ないですが、メッセージ出力タグがあったりして少しだけ違いがあります。

完了画面とは別のシーケンスだったことを示したい場合は、メッセージで通知するよりもエラー画面を設けておいた方が１画面に複数仕様が混在しないので良いかもしれません。

デメリットは、画面レイアウトの変更をした際、完了画面とエラー画面の両方をメンテナンスしないといけないところでしょうか？

この辺りはJSFのコンポーネントなり、テンプレートなりを使えば手間は減らせるかもしれません。

@ExecuteOnce(forwardPage = "error.xhtml", message = "エラー画面へ遷移：既に登録済みです。重複登録を抑止しました。新たに別の入力するか、トップページへ戻ってください。")
public String fwError() {
    System.out.println(this.getClass().toString() + "::登録処理を実施");
    return "complete.xhtml";
}

＜１回目の登録までは省略します＞

f:id:vermeer-1977:20180513084247p:plain

f:id:vermeer-1977:20180513084326p:plain

f:id:vermeer-1977:20180513084337p:plain

会話スコープが終わったらSubmit可能

本記事のテーマからは少しずれていますが、同一フォルダ内の遷移でもメソッドに@EndConversationを付与する事で会話スコープを終了できます。

通常フローの完了画面で「さらに入力」で、入力画面に戻ったら会話スコープが終了した後、新たに開始されます。

この時、同一フォルダの index.xhtmlですが @EndConversation の制御により、処理終了時に会話スコープは終了し、index.xhtmlの初期表示時に新たに会話スコープが開始されています。

これで、入力→確認→完了　のシーケンスをサイクリックに行えます。

@EndConversation
public String fwIndex() {
    return "index.xhtml";
}

＜完了画面の登録までは省略します＞

f:id:vermeer-1977:20180513084548p:plain

f:id:vermeer-1977:20180513084620p:plain

f:id:vermeer-1977:20180513084628p:plain

実装と仕組み

最優先のInterceptorで処理を行うことで、後続のInterceotorによって対象メソッドがcallされないようにします。

Annotation

デフォルト値は、空白とします。

意味としてはNullの方が良いのですが、Nullは設定できないので空白です。

@Target(value = {ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@InterceptorBinding
public @interface ExecuteOnce {

    @Nonbinding
    public String message() default "";

    @Nonbinding
    public String forwardPage() default "";
}

Interceptor

2回目以降の状態の場合は、通常フローの画面遷移をしないようにします。

ポイントになりそうなところにはコメントを入れました。

@Interceptor
@Priority(Interceptor.Priority.APPLICATION)
@ExecuteOnce
public class ExecuteOnceInterceptor {

    private final DoubleSubmitLifecycle doubleSubmitLifecycle;

    @Inject
    public ExecuteOnceInterceptor(DoubleSubmitLifecycle doubleSubmitLifecycle) {
        this.doubleSubmitLifecycle = doubleSubmitLifecycle;
    }

    @AroundInvoke
    public Object invoke(InvocationContext ic) throws Exception {
        System.out.println(this.getClass().toString() + "::開始");

        try {
            if (this.doubleSubmitLifecycle.isSubmitted()) {
                ExecuteOnce annotation = ic.getMethod().getAnnotation(ExecuteOnce.class);
                return this.toErrorPage(annotation);
            }
            Object result = ic.proceed();
            return result;
        } finally {
            this.doubleSubmitLifecycle.nextState();
            System.out.println(this.getClass().toString() + "::終了");
        }

    }

    //
    Object toErrorPage(ExecuteOnce annotation) {
        System.out.println(this.getClass().toString() + "::2重Submit処理");
        String message = annotation.message();
        if (Objects.equals(message, "") == false) {
            System.out.println("::2重Submit処理のメッセージ::" + message);

            //<h:messages /> にメッセージを出力
            FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(message));

            //リダイレクトしたときにメッセージがクリアされないようにする
            FacesContext.getCurrentInstance().getExternalContext().getFlash().setKeepMessages(true);
        }

        // エラーページを指定していない場合は自画面へ遷移
        String result = Objects.equals(annotation.forwardPage(), "")
                        ? FacesContext.getCurrentInstance().getViewRoot().getViewId()
                        : annotation.forwardPage();

        System.out.println("::2重Submit処理の遷移先::" + result);
        return result + "?faces-redirect=true";
    }

}