From k_taro.ishizaki ＠ sea.plala.or.jp Tue Mar 1 00:44:28 2011 From: k_taro.ishizaki ＠ sea.plala.or.jp (Kotaro Ishizaki) Date: Tue, 1 Mar 2011 00:44:28 +0900 Subject: [Wicket-ja-user 509] Re: =?iso-2022-jp?b?anNlc3Npb25pZBskQiROJSglaSE8GyhC?= In-Reply-To: <31420a81-596f-339a-8920-003723400d99@api105> References: <31420a81-596f-339a-8920-003723400d99@api105> Message-ID: 浅見様 石崎です。 問題となっているのは、初回アクセス時URLにJsessionIDが付与されてしまうことでしょうか？ その件についてはWicketの仕様と私は解釈しております。 以前にもJsessionIDがらみの話題があったようで うまいこと取り除くことも可能なようですね。 2008年7月あたりの過去ログが参考になりそうです。 以上です。 From t_yano ＠ me.com Tue Mar 1 12:56:19 2011 From: t_yano ＠ me.com (Tsutomu Yano) Date: Tue, 01 Mar 2011 12:56:19 +0900 Subject: [Wicket-ja-user 510] Re: =?iso-2022-jp?b?anNlc3Npb25pZBskQiROJSglaSE8GyhC?= In-Reply-To: References: <31420a81-596f-339a-8920-003723400d99@api105> Message-ID: <53F2EE38-8FEC-45AA-A7A8-1FBDB16DE9A3@me.com> 矢野です。 石崎さんの指摘を見て、そういえばそういう話した覚えがあるなあと思い出しました。たしかに2008/7月ごろにそういう話をしていました。 ページ全体がステートレスだと、セッションと結びついた段階で前リンクにjsessionidが付与されるのですね、そういえば。 具体的には次のURLのメールです。 http://sourceforge.jp/projects/wicket-ja/lists/archive/user/2008-July/000158.html このメールではBookmarkablePageをステートレスじゃなくす、という処理をしていますが、実際には、Wicketの仕様では「ページ上の全コンポーネントがステートレスだった場合のみステートレスページとして扱う」という動作をするので、どのコンポーネントでもいいから一つをステートレスじゃなくせば、ページはステートフルページになります。 --------------------------------------------------- 矢野　勉（やの　つとむ） 電子メール: t_yano ＠ me.com --------------------------------------------------- On 2011/03/01, at 0:44, Kotaro Ishizaki wrote: > 浅見様 > > 石崎です。 > > 問題となっているのは、初回アクセス時URLにJsessionIDが付与されてしまうことでしょうか？ > その件についてはWicketの仕様と私は解釈しております。 > > 以前にもJsessionIDがらみの話題があったようで > うまいこと取り除くことも可能なようですね。 > 2008年7月あたりの過去ログが参考になりそうです。 > > 以上です。 > > _______________________________________________ > Wicket-ja-user mailing list > Wicket-ja-user ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user From masaya.seko ＠ nifty.ne.jp Tue Mar 1 18:54:50 2011 From: masaya.seko ＠ nifty.ne.jp (Masaya seko) Date: Tue, 1 Mar 2011 18:54:50 +0900 (JST) Subject: [Wicket-ja-user 511] =?iso-2022-jp?b?GyRCJTslQyU3JWclczpGQDhALjhlJE4lWiE8JThBKzBcGyhC?= Message-ID: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> お世話になっております。世古と申します。 分からないことがあって困っております。 どなたかご存知の方が居られましたらご教授ください。 ■環境 Wicket 1.3.6 ■やりたいこと 以下の2点を行ないたいと考えております。 １．認証が必要なページ(以降「Aページ」とします)を表示した際に、ログイン画面を 　　出したい。ログイン画面でログインの操作を行なった後は、Aページに遷移したい 。 ２．CSRF対策として、ログイン後にセッションの再発行を行ないたい。 １については、hayasshさんのエントリ内に記載されている http://d.hatena.ne.jp/hayassh/20090415/1239797052と似た感じのことをしています 。 私はIAuthorizationStrategyとIUnauthorizedComponentInstantiationListenerを 使用しているため細部はことなりますが、「ログイン後は、Aページに遷移したい」の 部分については、continueToOriginalDestination()を使用しています。 ２については、ログイン成功時に以下のようにして行なっています (Wicket1.4のSession#replaceSession()と同じ処理)。 ---- Application.get().getSessionStore().invalidate(RequestCycle.get().getRequest() ); bind(); ---- ■困っていること 以下の操作を行なった際にPageExpiredErrorPageに遷移してしまいます。 (本当は、以下の３でAページを表示したい) １．認証が不要なページに存在する、Aページへのリンク(PageLinkコンポーネントを使 用)をクリック。 ２．ログイン画面が表示されるので、ログインの操作を行なう。 ３．PageExpiredErrorPageがブラウザに表示される ■分かっていること WebRequestCycleProcessor#resolve(final RequestCycle,final RequestParameters)内 の target = resolveRenderedPage(requestCycle, requestParameters);の呼び出し結果が nullとなった 結果PageExpiredErrorPageに遷移することが分かっています。 解析結果を踏まえますと、「セッションを作り直してしまった結果、URLと 遷移先ページの紐付けができない」という事象だと思われます。 よって遷移先(ページA)がブックマーク可能なページであればこの問題は発生 しないのですが、「認証が必要なページを全てブックマーク可能にする」というのは 解決策としてちょっと困りものです。 何か良い解決策は無いでしょうか？ 以上、よろしくおねがいします。 From shinyaokino ＠ gmail.com Wed Mar 2 12:03:11 2011 From: shinyaokino ＠ gmail.com (shinya okino) Date: Wed, 2 Mar 2011 12:03:11 +0900 Subject: [Wicket-ja-user 512] Re: =?iso-2022-jp?b?GyRCJTslQyU3JWclczpGQDhALjhlJE4lWiE8JTgbKEI=?= =?iso-2022-jp?b?GyRCQSswXBsoQg==?= In-Reply-To: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> References: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> Message-ID: 世古様 沖野です。 試していないのでうまくいくかわかりませんが、 以下のような方法が考えられます。 ログイン前に IUnauthorizedComponentInstantiationListener#onUnauthorizedInstantiation(Component) に認証が必要なページのインスタンスが渡されるのでそれを自分でSessionに保存します。 ログイン認証してセッション再発行後に continueToOriginalDestinationを使わずに 保存していたページのクラスを Component#setResponsePage(Class) に渡せば遷移できると思います。 2011年3月1日18:54 Masaya seko : > > お世話になっております。世古と申します。 > > 分からないことがあって困っております。 > どなたかご存知の方が居られましたらご教授ください。 > > ■環境 > Wicket 1.3.6 > > ■やりたいこと > 以下の2点を行ないたいと考えております。 > １．認証が必要なページ(以降「Aページ」とします)を表示した際に、ログイン画面を > 出したい。ログイン画面でログインの操作を行なった後は、Aページに遷移したい > 。 > ２．CSRF対策として、ログイン後にセッションの再発行を行ないたい。 > > １については、hayasshさんのエントリ内に記載されている > http://d.hatena.ne.jp/hayassh/20090415/1239797052と似た感じのことをしています > 。 > 私はIAuthorizationStrategyとIUnauthorizedComponentInstantiationListenerを > 使用しているため細部はことなりますが、「ログイン後は、Aページに遷移したい」の > 部分については、continueToOriginalDestination()を使用しています。 > > ２については、ログイン成功時に以下のようにして行なっています > (Wicket1.4のSession#replaceSession()と同じ処理)。 > ---- > Application.get().getSessionStore().invalidate(RequestCycle.get().getRequest() > ); > bind(); > ---- > > > ■困っていること > 以下の操作を行なった際にPageExpiredErrorPageに遷移してしまいます。 > (本当は、以下の３でAページを表示したい) > １．認証が不要なページに存在する、Aページへのリンク(PageLinkコンポーネントを使 > 用)をクリック。 > ２．ログイン画面が表示されるので、ログインの操作を行なう。 > ３．PageExpiredErrorPageがブラウザに表示される > > > ■分かっていること > WebRequestCycleProcessor#resolve(final RequestCycle,final RequestParameters)内 > の > target = resolveRenderedPage(requestCycle, requestParameters);の呼び出し結果が > nullとなった > 結果PageExpiredErrorPageに遷移することが分かっています。 > > 解析結果を踏まえますと、「セッションを作り直してしまった結果、URLと > 遷移先ページの紐付けができない」という事象だと思われます。 > よって遷移先(ページA)がブックマーク可能なページであればこの問題は発生 > しないのですが、「認証が必要なページを全てブックマーク可能にする」というのは > 解決策としてちょっと困りものです。 > > 何か良い解決策は無いでしょうか？ > > 以上、よろしくおねがいします。 > > _______________________________________________ > Wicket-ja-user mailing list > Wicket-ja-user ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user From masaya.seko ＠ nifty.ne.jp Fri Mar 4 07:18:39 2011 From: masaya.seko ＠ nifty.ne.jp (Masaya seko) Date: Fri, 4 Mar 2011 07:18:39 +0900 (JST) Subject: [Wicket-ja-user 513] Re: =?iso-2022-jp?b?GyRCJTslQyU3JWclczpGQDhALjhlJE4lWiE8JTgbKEI=?= =?iso-2022-jp?b?GyRCQSswXBsoQg==?= In-Reply-To: References: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> Message-ID: <14848272.12681299190719032.masaya.seko@nifty.ne.jp> 沖野様 世古です。 ご教授ありがとうございます。 実験してみたところ、以下の結果を得ました。 1.setResponsePage(final Class cls) :OK 2.setResponsePage(final Page page) :NG(ページのレンダリングに失敗する) 認証失敗時は、 IUnauthorizedComponentInstantiationListener#onUnauthorizedInstantiation(Compon ent) に渡されるPageクラスのインスタンスが不完全(Pageクラスのコンストラクタ内で認証 失敗の 例外が送出される)であるため「setResponsePage(final Page page)」の方は使用困難 なようですね。 setResponsePage(final Page page)が使用できた方が実装上の考慮が減って楽だったの ですが、 仕組み的になんともしがたそうな予感……。 setResponsePage(final Class cls)でどうにかするか、別の方法を考えるかちょっと検 討してみます。 回答ありがとうございました。 以上 ----- Original Message ----- >Date: Wed, 2 Mar 2011 12:03:11 +0900 >From: shinya okino >To: wicket-ja-user ＠ lists.sourceforge.jp >Subject: [Wicket-ja-user 512] Re: > セッション再生成後のページ遷移 > > >世古様 > >沖野です。 >試していないのでうまくいくかわかりませんが、 >以下のような方法が考えられます。 > >ログイン前に >IUnauthorizedComponentInstantiationListener#onUnauthorizedInstantiation(Compo nent) >に認証が必要なページのインスタンスが渡されるのでそれを自分でSessionに保存しま す。 > >ログイン認証してセッション再発行後に >continueToOriginalDestinationを使わずに >保存していたページのクラスを >Component#setResponsePage(Class) >に渡せば遷移できると思います。 > >2011年3月1日18:54 Masaya seko : >> >> お世話になっております。世古と申します。 >> >> 分からないことがあって困っております。 >> どなたかご存知の方が居られましたらご教授ください。 >> >> ■環境 >> Wicket 1.3.6 >> >> ■やりたいこと >> 以下の2点を行ないたいと考えております。 >> １．認証が必要なページ(以降「Aページ」とします)を表示した際に、ログイン画面 を >> 出したい。ログイン画面でログインの操作を行なった後は、Aページに遷移したい >> 。 >> ２．CSRF対策として、ログイン後にセッションの再発行を行ないたい。 >> >> １については、hayasshさんのエントリ内に記載されている >> http://d.hatena.ne.jp/hayassh/20090415/1239797052と似た感じのことをしていま す >> 。 >> 私はIAuthorizationStrategyとIUnauthorizedComponentInstantiationListenerを >> 使用しているため細部はことなりますが、「ログイン後は、Aページに遷移したい」 の >> 部分については、continueToOriginalDestination()を使用しています。 >> >> ２については、ログイン成功時に以下のようにして行なっています >> (Wicket1.4のSession#replaceSession()と同じ処理)。 >> ---- >> Application.get().getSessionStore().invalidate(RequestCycle.get().getReques t() >> ); >> bind(); >> ---- >> >> >> ■困っていること >> 以下の操作を行なった際にPageExpiredErrorPageに遷移してしまいます。 >> (本当は、以下の３でAページを表示したい) >> １．認証が不要なページに存在する、Aページへのリンク(PageLinkコンポーネント を使 >> 用)をクリック。 >> ２．ログイン画面が表示されるので、ログインの操作を行なう。 >> ３．PageExpiredErrorPageがブラウザに表示される >> >> >> ■分かっていること >> WebRequestCycleProcessor#resolve(final RequestCycle,final RequestParameters )内 >> の >> target = resolveRenderedPage(requestCycle, requestParameters);の呼び出し結 果が >> nullとなった >> 結果PageExpiredErrorPageに遷移することが分かっています。 >> >> 解析結果を踏まえますと、「セッションを作り直してしまった結果、URLと >> 遷移先ページの紐付けができない」という事象だと思われます。 >> よって遷移先(ページA)がブックマーク可能なページであればこの問題は発生 >> しないのですが、「認証が必要なページを全てブックマーク可能にする」というの は >> 解決策としてちょっと困りものです。 >> >> 何か良い解決策は無いでしょうか？ >> >> 以上、よろしくおねがいします。 >> >> _______________________________________________ >> Wicket-ja-user mailing list >> Wicket-ja-user ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user > >_______________________________________________ >Wicket-ja-user mailing list >Wicket-ja-user ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user From t_yano ＠ me.com Fri Mar 4 14:47:55 2011 From: t_yano ＠ me.com (Tsutomu Yano) Date: Fri, 04 Mar 2011 14:47:55 +0900 Subject: [Wicket-ja-user 514] Re: =?iso-2022-jp?b?GyRCJTslQyU3JWclczpGQDhALjhlJE4lWiE8JTgbKEI=?= =?iso-2022-jp?b?GyRCQSswXBsoQg==?= In-Reply-To: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> References: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> Message-ID: 矢野です。 　直接的な回答でないので恐縮なのですが…　 　おそらく、旧セッションの内容を新セッションに複製しないと、うまく動かないと思います。（Wicketとは関係なく）認証後も認証前のセッション情報を必要とするケースは多々あり、そういう場合はやはり内容の転写を行うようです。 　私はログイン有無とセッション維持とは別に管理してます。サーブレットコンテナでは、セッションIDって勝手に発行されてしまって制御がややこしいので、発行を自分で管理できるクッキーを自分で発行します。 　具体的には、ログイン成功時にはログインクッキーを発行し、ログイン要ページでは、そのクッキーが確認できない限りはログイン画面に差し戻す、というプログラムを作ります。実際にはもう少し細かい制御が必要ですけども（クッキーを作ってから、クッキーがブラウザに届くまでの間のページ制御に工夫が少し必要）、大枠としてはそういうことです。 　今回の件でも、同じHttpSessionを継続して使えていれば、SessionExpiredにならないわけですし。 　認証が必要なページではすべて、ログイン時に発行したクッキーが届いているかどうかを判定することで、不正な接続を排除できます。仮に誰かが何らかの方法でセッションIDを知ったとしても、ログインクッキーがない以上は認証後画面に入ることはできません。セッションフィクセーション攻撃には耐性があるはずです。 　Wicket独自の解決法ってわけでもないのでちょっとした逃げのようにも思えますが、セッション維持とログイン制御を分離できるので、なにかと便利です。実装もそれほどたいへんではありませんし。 　ちなみに、CSRF対策としては、Wicketが発番するページ番号をランダムにするといいです。Wicketでは仕組み上、ページ番号がわからないかぎり、フォームのポストは行えません。ページ番号をランダムにするには、SessionのnextPageId()をオーバーライドするだけなので、簡単にセキュリティ強化できます（デフォルトは１からの連番なので容易に推測できてしまいます）。 参考案として書きました。 --------------------------------------------------- 矢野　勉（やの　つとむ） 電子メール: t_yano ＠ me.com --------------------------------------------------- On 2011/03/01, at 18:54, Masaya seko wrote: > お世話になっております。世古と申します。 > > 分からないことがあって困っております。 > どなたかご存知の方が居られましたらご教授ください。 > > ■環境 > Wicket 1.3.6 > > ■やりたいこと > 以下の2点を行ないたいと考えております。 > １．認証が必要なページ(以降「Aページ」とします)を表示した際に、ログイン画面を > 　　出したい。ログイン画面でログインの操作を行なった後は、Aページに遷移したい > 。 > ２．CSRF対策として、ログイン後にセッションの再発行を行ないたい。 > > １については、hayasshさんのエントリ内に記載されている > http://d.hatena.ne.jp/hayassh/20090415/1239797052と似た感じのことをしています > 。 > 私はIAuthorizationStrategyとIUnauthorizedComponentInstantiationListenerを > 使用しているため細部はことなりますが、「ログイン後は、Aページに遷移したい」の > 部分については、continueToOriginalDestination()を使用しています。 > > ２については、ログイン成功時に以下のようにして行なっています > (Wicket1.4のSession#replaceSession()と同じ処理)。 > ---- > Application.get().getSessionStore().invalidate(RequestCycle.get().getRequest() > ); > bind(); > ---- > > > ■困っていること > 以下の操作を行なった際にPageExpiredErrorPageに遷移してしまいます。 > (本当は、以下の３でAページを表示したい) > １．認証が不要なページに存在する、Aページへのリンク(PageLinkコンポーネントを使 > 用)をクリック。 > ２．ログイン画面が表示されるので、ログインの操作を行なう。 > ３．PageExpiredErrorPageがブラウザに表示される > > > ■分かっていること > WebRequestCycleProcessor#resolve(final RequestCycle,final RequestParameters)内 > の > target = resolveRenderedPage(requestCycle, requestParameters);の呼び出し結果が > nullとなった > 結果PageExpiredErrorPageに遷移することが分かっています。 > > 解析結果を踏まえますと、「セッションを作り直してしまった結果、URLと > 遷移先ページの紐付けができない」という事象だと思われます。 > よって遷移先(ページA)がブックマーク可能なページであればこの問題は発生 > しないのですが、「認証が必要なページを全てブックマーク可能にする」というのは > 解決策としてちょっと困りものです。 > > 何か良い解決策は無いでしょうか？ > > 以上、よろしくおねがいします。 > > _______________________________________________ > Wicket-ja-user mailing list > Wicket-ja-user ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user From masaya.seko ＠ nifty.ne.jp Sun Mar 6 00:12:54 2011 From: masaya.seko ＠ nifty.ne.jp (Masaya seko) Date: Sun, 6 Mar 2011 00:12:54 +0900 (JST) Subject: [Wicket-ja-user 515] Re: =?iso-2022-jp?b?GyRCJTslQyU3JWclczpGQDhALjhlJE4lWiE8JTgbKEI=?= =?iso-2022-jp?b?GyRCQSswXBsoQg==?= In-Reply-To: References: <5200595.315031298973290651.masaya.seko@nifty.ne.jp> Message-ID: <31680130.318111299337974685.masaya.seko@nifty.ne.jp> 矢野様 世古です。 まず最初にお詫びを。 セッションの再作成は、セッションフィクセーション攻撃に関する対策ですよね。 CSRF対策と私が間違って書いてしまったがために、矢野様に両方の攻撃に対策を回答さ せてしまうことになってしまい、申し訳ありませんでした。 今回質問した主題はセッションフィクセーション攻撃だったのですが、別件でCSRF対策 についても検討していたため助かりました。 ありがとうございます。 では気を取り直しまして。 ■セッションの転写について セッションの転写に回避については調査した結果、「私が解決したい問題を解決するの は難しそうだ」という結論に至りました。 単純に古いセッションの情報を待避しておいて、新しいオブジェクトにコピーしても、 URLとPageの対応付けは動作しなかったです。 セッション破棄のタイミングで、ISessionStoreが破棄されるようで(HttpSessionBindi ngListenerを実装したクラスが存在しておりそのクラスが破棄の仕事をする)密接に関 係しているっぽいIPageMapも無効になり、結局私の望む挙動はさせられないという…… 。 ■セッションフィクセーション攻撃(ログイン時にクッキーを発行する手法) 「セッションIDを変えなきゃ」と思っていた私にはびっくりですが、仰るとおりセッシ ョンフィクセーション攻撃に耐性ありそうですね。 クッキーの使用を拒否していくるブラウザについては、何か対策(エラー画面を返すと か)を考えないといけないのでそこが悩みどころにはなりそうです。 ■CSRF対策(SessionのnextPageId()をオーバーライド) これもびっくりですが、確かに有効的に思えます。 普通のForm(StatelessFormみたいなの以外)を使う限り、POST先のURLにはPageIDが入り ますものね。 これは採用を前向きに考えます。 あとこれは余談です。 ■セッションフィクセーション攻撃(最近考えていた別解) 「URLを元にPageクラスのインスタンスを生成したあとにセッションを作り直せば、URL とPageの対応付けが失われてもいけるのでは」という発想の元、「ログイン成功時に、 セッションにフラグを立てておいて、遷移先ページのPage#onBeforeRender()あたりで セッションを作り直そうか」なんて案を仲間内で話し合っています。 実際にやってみると、動くには動くのですが、ちょっとどきどき(駄目なケースを見落 としてないか？という観点で)です。 以上 ----- Original Message ----- >From: Tsutomu Yano >Date: Fri, 04 Mar 2011 14:47:55 +0900 >To: wicket-ja-user ＠ lists.sourceforge.jp >Subject: [Wicket-ja-user 514] Re: > セッション再生成後のページ遷移 > > >矢野です。 > >　直接的な回答でないので恐縮なのですが…　 >　おそらく、旧セッションの内容を新セッションに複製しないと、うまく動かないと 思います。（Wicketとは関係なく）認証後も認証前のセッション情報を必要とするケー スは多々あり、そういう場合はやはり内容の転写を行うようです。 > >　私はログイン有無とセッション維持とは別に管理してます。サーブレットコンテナ では、セッションIDって勝手に発行されてしまって制御がややこしいので、発行を自分 で管理できるクッキーを自分で発行します。 > >　具体的には、ログイン成功時にはログインクッキーを発行し、ログイン要ページで は、そのクッキーが確認できない限りはログイン画面に差し戻す、というプログラムを 作ります。実際にはもう少し細かい制御が必要ですけども（クッキーを作ってから、ク ッキーがブラウザに届くまでの間のページ制御に工夫が少し必要）、大枠としてはそう いうことです。 >　今回の件でも、同じHttpSessionを継続して使えていれば、SessionExpiredにならな いわけですし。 > >　認証が必要なページではすべて、ログイン時に発行したクッキーが届いているかど うかを判定することで、不正な接続を排除できます。仮に誰かが何らかの方法でセッシ ョンIDを知ったとしても、ログインクッキーがない以上は認証後画面に入ることはでき ません。セッションフィクセーション攻撃には耐性があるはずです。 > >　Wicket独自の解決法ってわけでもないのでちょっとした逃げのようにも思えますが 、セッション維持とログイン制御を分離できるので、なにかと便利です。実装もそれほ どたいへんではありませんし。 > >　ちなみに、CSRF対策としては、Wicketが発番するページ番号をランダムにするとい いです。Wicketでは仕組み上、ページ番号がわからないかぎり、フォームのポストは行 えません。ページ番号をランダムにするには、SessionのnextPageId()をオーバーライ ドするだけなので、簡単にセキュリティ強化できます（デフォルトは１からの連番なの で容易に推測できてしまいます）。 > >参考案として書きました。 > >--------------------------------------------------- >矢野　勉（やの　つとむ） >電子メール: t_yano ＠ me.com >--------------------------------------------------- > >On 2011/03/01, at 18:54, Masaya seko wrote: > >> お世話になっております。世古と申します。 >> >> 分からないことがあって困っております。 >> どなたかご存知の方が居られましたらご教授ください。 >> >> ■環境 >> Wicket 1.3.6 >> >> ■やりたいこと >> 以下の2点を行ないたいと考えております。 >> １．認証が必要なページ(以降「Aページ」とします)を表示した際に、ログイン画面 を >> 　　出したい。ログイン画面でログインの操作を行なった後は、Aページに遷移した い >> 。 >> ２．CSRF対策として、ログイン後にセッションの再発行を行ないたい。 >> >> １については、hayasshさんのエントリ内に記載されている >> http://d.hatena.ne.jp/hayassh/20090415/1239797052と似た感じのことをしていま す >> 。 >> 私はIAuthorizationStrategyとIUnauthorizedComponentInstantiationListenerを >> 使用しているため細部はことなりますが、「ログイン後は、Aページに遷移したい」 の >> 部分については、continueToOriginalDestination()を使用しています。 >> >> ２については、ログイン成功時に以下のようにして行なっています >> (Wicket1.4のSession#replaceSession()と同じ処理)。 >> ---- >> Application.get().getSessionStore().invalidate(RequestCycle.get().getReques t() >> ); >> bind(); >> ---- >> >> >> ■困っていること >> 以下の操作を行なった際にPageExpiredErrorPageに遷移してしまいます。 >> (本当は、以下の３でAページを表示したい) >> １．認証が不要なページに存在する、Aページへのリンク(PageLinkコンポーネント を使 >> 用)をクリック。 >> ２．ログイン画面が表示されるので、ログインの操作を行なう。 >> ３．PageExpiredErrorPageがブラウザに表示される >> >> >> ■分かっていること >> WebRequestCycleProcessor#resolve(final RequestCycle,final RequestParameters )内 >> の >> target = resolveRenderedPage(requestCycle, requestParameters);の呼び出し結 果が >> nullとなった >> 結果PageExpiredErrorPageに遷移することが分かっています。 >> >> 解析結果を踏まえますと、「セッションを作り直してしまった結果、URLと >> 遷移先ページの紐付けができない」という事象だと思われます。 >> よって遷移先(ページA)がブックマーク可能なページであればこの問題は発生 >> しないのですが、「認証が必要なページを全てブックマーク可能にする」というの は >> 解決策としてちょっと困りものです。 >> >> 何か良い解決策は無いでしょうか？ >> >> 以上、よろしくおねがいします。 >> >> _______________________________________________ >> Wicket-ja-user mailing list >> Wicket-ja-user ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user > >_______________________________________________ >Wicket-ja-user mailing list >Wicket-ja-user ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user