maga****@hagan*****
maga****@hagan*****
2011年 4月 22日 (金) 22:50:00 JST
船田です。 ご意見ありがとうございます。 > この設定でリダイレクトは自動的に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
