Subscribed unsubscribe Subscribe Subscribe

マルチウィンドウの問題

ショッピングカートの例を用いてシナリオを考えてみると、あるとすれば以下のような状況が多いのかな?と思いました。他のシナリオも当然あるとは思いますが。

1. ショッピングカートのアイテムを1つ入れる。
2. Ctrl+Nキーを押下して、キャッシュを引き継いだ画面を開く。(2枚ウィンドウが開いている状態)
3. 新しく開いたウィンドウで、アイテムを追加する。(Convesationスコープのカートにはアイテムが2つある。)
4. 新しく開いたウィンドウで「支払いボタン」を押下する。(Conversationスコープのカートからアイテムが消える。)
5. 間違えて、はじめから開いていたウィンドウで「支払いボタン」を押下する。(カートにはアイテムが入っていないので実害はない。pages.xmlでno-conversationを使うことで操作を抑止できる可能性が高そうな予感がしますし、通常のシステムの場合においては、ビジネスロジックでエラーとするはず。)

http://d.hatena.ne.jp/inabatch/20080405/1207325951

上記のシナリオであれば問題はないと思いますが、

  1. Ctrl+Nキーを押下して、同一Conversationを参照する画面を開く(2枚ウィンドウが開いている状態)
  2. 新しく開いたウィンドウで、商品をカートに追加する
  3. 新しく開いたウィンドウで「支払いボタン」を押して購入確認画面へ遷移する
  4. はじめから開いていたウィンドウで別の商品をカートに追加する
  5. 新しく開いたウィンドウで「購入」ボタンを押して購入処理を終了する

ようなシナリオだと、最後の購入でアプリケーション側でちゃんと検査をしていないと、購入確認画面に表示されている物と異なる内容で決済されてしまいます。

Seamの記事やリファレンスでは複数ウィンドウ、タブでも安全にパラレルで処理できるとよく書かれていますが、ブラウザの仕様上、セッションベースですとどうしても混ざってしまうケースもあるので、Seamを使っていればマルチウィンドウ問題は意識しなくてもOK!というように読み取られるとちょっと危険じゃないかな?と個人的には思います。実は脆弱性があるアプリケーションを量産しかねません。

Conversationではここまで対応してくれるけど、対応できない部分はあって、そういう場合はこういう風に対応すると防げるよ〜といった情報がもっと欲しいですね。

ところが、Conversation以前に、セッションを利用した場合に気を付けなければいけないポイントって、余り広く知られていない気がするのですよね。。。
セッション変数使用時の注意点でも紹介されてましたが、セッションを使ったフォーム処理にありがちな問題点で詳しく書かれています。

でも、こういった話は、Webアプリケーションの入門書とか入門記事にちゃんと書いておいて欲しいですね。