Tsutomu Yano
t_yano****@me*****
2011年 4月 24日 (日) 01:37:27 JST
矢野です。 インフラで解決できるならそれが理想だと思います。 WicketのHttpsRequestCycleProcessorの機能を使って解決したい、そして、Wicketにおけるその制御をする拡張ポイントはどこになるのか？という質問でしたら、checkSecureIncomingメソッドをオーバーライドすることになろうかと思います。 ただ、もとのcheckSecureIncomingメソッドの実装はパッケージプライベートなSwitchProtocolRequestTargetに強く依存しているので、SwitchProtocolRequestTargetのサブクラスをパッケージ名を一致させて継承して、なんとかすることになるんじゃないかな、とは、私もやってみて思いました。 で、この手の話題はWicket関連でも上がっていて、他の方のいうように、アプリケーションサーバ側で設定して解決しているようです。 例えば： http://apache-wicket.1842946.n4.nabble.com/Proxying-SSL-on-Apache-to-HTTP-on-Jetty-Wicket-td1892147.html など。 なお、SwitchProtocolRequestTargetがパッケージプライベートなのはともかく、SwitchProtocolRequestTarget.Protocolが外部参照不可なのは、もしかしたら、Wicket側の問題かもしれません。SwitchProtocolRequestTargetの設計意図として、リダイレクトさせたくない場合にはProtocol.PRESERVE_CURRENTをSwitchProtocolRequestTarget.requireProtocol(Protocol)に渡せ、という設計意図がなんとなく見えるのですが、実際にはそれが出来ないからです。もしそれができれば、比較的完結に、checkSecureIncomingを実装できそうな気がします。 --------------------------------------------------- 矢野 勉（やの つとむ） 電子メール: t_yano****@me***** --------------------------------------------------- On 2011/04/22, at 22:50, maga****@hagan***** wrote: > 船田です。 > > ご意見ありがとうございます。 > >> この設定でリダイレクトは自動的にhttps://securefrontend.example.com/redirectPathというURLになります。 > > https://によるリダイレクトでは > 同じ結果になるので意味がないと考えています。 > > 何らかの設定でポートフォワーディング的な動きをするなら、 > 内部ネットワークにHTTPSが走らないのでありかもしれません。 > > > Tomcatでは、 > server.xmlの設定でHTTP通信でもrequest.getScheme()を > HTTPSとすることが可能ですが、 > それが本当によいことなのか意見が割れているようです。 > > glassfishでも同じ議論がされていて > こちらも結論がでていません。 > > http://java.net/jira/browse/GLASSFISH-15409 > >> この構成の設定はアプリケーションサーバ側で吸収できないとおかしいので、Glassfishのコミュニティに聞くのが良いと思います。アプリケーションでやるべきではありません。 > > どちらの領域かと言われれば微妙だと思います。 > > この問題はWicket以外のフレームワークでは > あまり聞いたことがなくて > リダイレクトを多用するWicketの設計思想が > 裏目に出ているような感じがいたしましたのでこちらに投げさせていただきました。 > > > 以上。よろしくお願いいたします。 > > > >>> Webサーバをフロント、アプリケーションサーバをバックエンドにして >>> 内部の通信はすべてHTTPで行うという構成は >>> よくある環境だと思うのですが、どのように実装するのが正しいのでしょうか？ >> >> この構成の設定はアプリケーションサーバ側で吸収できないとおかしいので、Glassfishのコミュニティに聞くのが良いと思います。アプリケーションでやるべきではありません。 >> >> 例えばTomcatやJBossだとserver.xmlで以下のように設定できます。 >> >> <Connector protocol="HTTP/1.1" port="8080" address="${jboss.bind.address}" >> proxyHost="securefrontend.example.com" proxyPort="443" scheme="https" >> connectionTimeout="20000" redirectPort="443"/ > >> >> この設定でリダイレクトは自動的にhttps://securefrontend.example.com/redirectPathというURLになります。 >> >> Regards, >> -- >> //Takayoshi Kimura >> Senior Software Maintenance Engineer, JBoss >> >> _______________________________________________ >> Wicket-ja-user mailing list >> Wicke****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user >>> 船田と申します。 >>> >>> ロードバランサーをフロントにWebサーバを経由してアプリケーションサーバにglassfishという環境でWicket1.4.17を使用しています。 >>> >>> HTTPSによる通信はロードバランサーまでで、以降はプロトコルごとに >>> ポートを振り分けてHTTPで流しています。 >>> >>> http://xxx で始まるページから、@RequireHttpsを指定したPageに遷移して >>> https://xxx で始まるページを表示させようとしています。 >>> >>> Applicatioクラスでは、以下のように指定しました。 >>> >>> @Override >>> protected IRequestCycleProcessor newRequestCycleProcessor() { >>> return new HttpsRequestCycleProcessor(new HttpsConfig(80, 443)); >>> } >>> >>> >>> HTTPでHTTPSのページにアクセスしようとするので >>> Wicketは、このプロトコルで表示すべきページでないと判断し >>> https://xxx で始まるURLを生成してリダイレクトをかけようとします。 >>> >>> そして、 >>> >>> https://xxx で始まるリクエストは、ロードバランサーが >>> http://xxx に変換してバックエンドに流します。 >>> >>> 結果、 >>> >>> WicketにはHTTP通信で届き、 >>> Wicketがhttps:// でリダイレクト……という無限ループが発生します。 >>> >>> >>> >>> リダイレクトをかけているのは、 >>> SwitchProtocolRequestTargetというクラスです。 >>> >>> public static IRequestTarget requireProtocol(Protocol protocol, IRequestTarget target) >>> { >>> RequestCycle requestCycle = RequestCycle.get(); >>> WebRequest webRequest = (WebRequest)requestCycle.getRequest(); >>> HttpServletRequest request = webRequest.getHttpServletRequest(); >>> if (protocol == null || protocol == Protocol.PRESERVE_CURRENT || >>> request.getScheme().equals(protocol.toString().toLowerCase())) >>> { >>> return null; >>> } >>> else >>> { >>> return new SwitchProtocolRequestTarget(protocol, target); >>> } >>> } >>> >>> request.getScheme()で現在使用中のプロトコルをみています。 >>> glassfishが使用しているCoyoteRequestではsetScheme()が空実装なので事前に細工することもできません。 >>> >>> 回避策として >>> パッケージスコープであるSwitchProtocolRequestTargetを >>> 強引に継承して、localportを見て判断するようなコードを書きました。 >>> >>> switch (protocol) { >>> case HTTP: >>> port = HTTPの時に使用する内部ポート; >>> break; >>> case HTTPS: >>> port = HTTPSの時に使用する内部ポート; >>> break; >>> } >>> >>> if (protocol == null || protocol == Protocol.PRESERVE_CURRENT >>> || request.getLocalPort() == port) { >>> >>> >>> SwitchProtocolRequestTargetを呼び出している箇所も >>> Wicketが持っている拡張ポイントではないので、 >>> こういう書き方でよいのか悩んでいます。 >>> >>> >>> Webサーバをフロント、アプリケーションサーバをバックエンドにして >>> 内部の通信はすべてHTTPで行うという構成は >>> よくある環境だと思うのですが、どのように実装するのが正しいのでしょうか？ >>> >>> >>> 以上、よろしくおねがいします。 >>> >>> _______________________________________________ >>> Wicket-ja-user mailing list >>> Wicke****@lists***** >>> http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user > > _______________________________________________ > Wicket-ja-user mailing list > Wicke****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/wicket-ja-user
