i think a better way may be:
myapplication#init() {
setRootRequestMapper(new HttpsHandler(getRootRequestHandler(), httpsConfig));
}
that way it fits in nicely with the idea of bolt-on request mappers
and allows users more control.
-igor
On Sat, Jul 31, 2010 at 2:00 AM, Martin Grigorov <[email protected]> wrote:
> Hi,
>
> I'm re-introducing https request upgrading (ex. SwitchProtocolRequestTarget)
> in Wicket 1.5 -> SwitchProtocolRequestHandler.
> In 1.4 the user application has to register HttpsRequestCycleProcessor to be
> able to use this functionality. In 1.5 there is no IRequestCycleProcessor so
> we need another way to hook this functionality.
>
> Currently I'm considering these two options:
> 1) add setter and getter for HttpsConfig in
> org.apache.wicket.settings.ISecuritySettings. The default value for
> Settings#httpsConfig is 'null'. If the user app registers non-null https
> config then org.apache.wicket.request.cycle.RequestCycle.processRequest()
> will ask HttpsRequestChecker (new class with the logic
> from HttpsRequestCycleProcessor) to check the resolved IRequestHandler for
> page annotated with @RequireHttps and if there is such then it will replace
> the resolved request handler with SwitchProtocolRequestHandler
>
> In brief this option triggers https check only if there is non-null
> HttpsConfig in SecuritySettings
>
> 2) add setter and getter for HttpsConfig in
> org.apache.wicket.settings.ISecuritySettings. The default value for
> Settings#httpsConfig is 'new HttpsConfig()', i.e. default https port == 443.
> The user app can change the https settings, but cannot set 'null' value for
> HttpsConfig. Add HttpsRequestCycle which extends RequestCycle and *always*
> asks HttpsRequestChecker to do its work.
>
> In brief: the user app has to register this custom RequestCycle to be able
> to use @RequireHttps in its pages.
>
> Which of these two do you recommend ?
> Or maybe there is a third better one ?
>
> martin-g
>
