ソースを追ってみると、初回はHttpServletRequest#
isRequestedSessionIdFromCookie()
がfalseを返してHttpServlet#encodeURL()でjsessionidを付加してました。原因は初回アクセスはcookieが有効かどうかわからないからですね。
Servlet仕様で、セッションIDの格納先にCookieが使用できないクライアントを想定してURLへセッションIDを文字列付加しての送信もサポートすることを推奨してるから、だいたいどのフレームワークも同じ実装だと思います(いわゆるURLリライティング)。とりあえず、StrutsとTeedaはそうでした。
回避方法は、最初にアクセスするページの前にダミーページを用意してリダイレクトを行うことでcookie有効判定に通せばよさそうですね。
ひがさんのブログに書いてありました。
http://d.hatena.ne.jp/higayasuo/20080724/1216889790
Teedaでは、ダミーのhtmlとPageクラスを用意して、PageクラスのprerenderでHttpServletResponse#
sendRedirect()を呼び出すことでうまくいきました!
cookieが無効のクライアントをケアしないのであれば、Webサーバの設定等でにげれそうですね。
weblogicなら、weblogic.xmlのurl-rewriting-enabledをfalseに設定するとか、Apacheのmod_rewriteを使用するとか。
あとは、いけてないけど判定ロジックを部分を拡張するとかもありますね。
TeedaだとServletExternalContextImpl #encodeActionURL()を拡張すればよさそう。
ちなみにSSLにすれば、HTTPのボディだけじゃなくてヘッダも暗号化されるんだよね?
という疑問が沸いたので調べてみた。
じゃないとリファラとかでURLパラメータの方が危険性は高いと言っても、
ネットワークには平分で流れちゃうし。
SSLはTCP階層の暗号化なので、HTTPのヘッダもボディも暗号化されるようです。
GETパラメータももちろん暗号化されますね。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=1991&forum=12
0 件のコメント:
コメントを投稿