- PR -

戻るボタンの対応について。

1
投稿者投稿内容
KingSize
常連さん
会議室デビュー日: 2002/11/13
投稿数: 38
投稿日時: 2003-01-24 10:15
久しぶりに投稿させて頂きます。

現在、Strutsを使用してWebアプリケーションの開発の検証を行っています。
ブラウザの戻るボタンや２重リクエスト送信対策として、
http://www.ibm.com/jp/software/websphere/developer/j2ee/pdf/4_2.pdf
に載っていたgenerateToken()を使用して、検証を行なっていたのですが、
Tomcatのバージョンを4.0.6から4.1.18に変更したとたん、うまくいかなくなりました。

書き遅れましたが、その他の環境のバージョンは以下の通りです。
j2sdk1.4.1_01
struts1.1b3
apache2.0.43

戻るボタン対策の実装の流れは以下の通りです。
Action内でgenerateToken(request)→トークンをセッションに格納→遷移先JSPではセッションからトークンをとってきてhiddenとして埋め込み→そのJSPから呼び出されたAction内でセッションのトークンとhiddenのトークンを比較→新たなトークンを生成、セッションに格納。

うまくいかなくなったというのは、正常系の流れでトークンを比較した場合にイコールになっていたものが、イコールにならないというものです。

ちなみにhiddenにトークンを埋め込む部分はカスタムタグを使っています。

Tomcat4.1.6からタグのプーリング機能が追加されたみたいでそれが関係している気がするのですが、その機能自体、どんなものか(タグの何をプールするのか)よくわかっていません。

そこで
１．上記のタグプーリング機能について
２．一般的に用いられる戻るボタンやリクエスト２重送信対策
についてどなたかご教授願いないでしょうか？
よろしくお願いします。

[ メッセージ編集済み 編集者: クボタ 編集日時 2003-01-24 10:18 ]
ayum
常連さん
会議室デビュー日: 2002/03/28
投稿数: 44
お住まい・勤務地: 東京
投稿日時: 2003-01-24 14:32
Tomcat4.1.Xから、タグリブのインスタンスをプールするようになったのに加えて、
それまでとreleace()メソッドが呼ばれるタイミングが変わっています。

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=3163&forum=12&5

ただ、Strutsのorg.apache.struts.taglib.html.FormTagのソースを見てみると、
hiddenにトランザクショントークンをセットする部分は
releace()による初期化とは無関係なように思いますし、
インスタンスをプールしてフィールドの値に古いものが使い回されたとしても
トランザクショントークンをセットする部分に関しては
問題ないように思えました（他の部分はともかく）。
ので、Strutsのカスタムタグを使用してれば
そこに関してはインスタンスプーリングが問題になったりはしないような
印象も受けたのですが･･･。
私も実際に動かして確認したわけではないですが、
原因はタグリブのインスタンスのプーリングとは違うところにあるかもしれません。

ActionクラスのisTokenValid(HttpServletRequest)の実装は
（細かいことは色々やってますが）ほとんど単純にStringの比較なので、
とりあえずsession.getAttribute(Action.TRANSACTION_TOKEN_KEY)で取得できる
セッションにセットされたトークンと
request.getParameter(Constants.TOKEN_KEY)で取得できるそのリクエストのトークンが
同じかどうかSystem.outするなりして見てみてはいかがでしょうか?
KingSize
常連さん
会議室デビュー日: 2002/11/13
投稿数: 38
投稿日時: 2003-01-24 20:38
返事が遅くなってしまい申し訳ありません。

ログを出してみました。
あるJSPからサブミットすると

2003-01-24 19:59:30,421 INFO [Thread-8] (ChangeEndAction.java:39) -　formToken = a91c96906f6790c26377195254e27bd3
2003-01-24 19:59:30,421 INFO [Thread-8] (ChangeEndAction.java:40) - sessionToken = a91c96906f6790c26377195254e27bd3
2003-01-24 19:59:30,453 INFO [Thread-8] (ChangeEndAction.java:39) - formToken = a91c96906f6790c26377195254e27bd3
2003-01-24 19:59:30,468 INFO [Thread-8] (ChangeEndAction.java:40) - sessionToken = d1678c0714324a9ef31724212a6a47e9
となり、最後の2つのトークンが合っていないため、エラーとなります。
ところが、上と同じ状況でしばらく待っていると、(5秒くらい)

2003/01/24 20:02:02 org.apache.jk.common.ChannelSocket processConnection
情報: connection timeout reached

↑のようなログがTomcatのコンソールに吐き出されます。
これが出てからサブミットすると、
2003-01-24 20:02:05,109 INFO [Thread-8] (ChangeEndAction.java:39) - formToken = a2b59270d7fb26075a73f4ef65c5063f
2003-01-24 20:02:05,109 INFO [Thread-8] (ChangeEndAction.java:40) - sessionToken = a2b59270d7fb26075a73f4ef65c5063f
2003-01-24 20:02:05,125 INFO [Thread-8] (NoCacheTag.java:36) - doStartTag start.

となり、トークンが等しいので正常とみなされます。
Tomcat4.0.6で全く同じ状況を試すと

2003-01-24 20:27:00,828 INFO [Ajp13Processor[8009][3]] (ChangeEndAction.java:39) - formToken =　edb0422094afda4d24902a8e19114294
2003-01-24 20:27:00,828 INFO [Ajp13Processor[8009][3]] (ChangeEndAction.java:40) - sessionToken = edb0422094afda4d24902a8e19114294
2003-01-24 20:27:00,859 INFO [Ajp13Processor[8009][3]] (NoCacheTag.java:36) - doStartTag start.

というように正常に動作します。

JSPでしばらくすると吐き出されるログが明らかに怪しい気がするのですが．．．
それと吐き出されるログの量(エラーの場合サブミットしてから出されるログが多い)の違いも気になります。
また、ログの一部がバージョンによって違うのも何か関係あるのでしょうか？
よろしくご教授お願いします。
1

スキルアップ／キャリアアップ（JOB@IT）