thanks I'll try that, it is possible that they go straight to the login page but unlikely so I should be ok.
On 29/mar/2011, at 18.31, Igor Vaynberg wrote: > simply call session.bind() in requestcycle.onendrequest() which will > make sure the session is bound on every request. > > you can still have a problem if the login page is the first page hit > by the user. can that be the case in your application? > > -igor > > > On Tue, Mar 29, 2011 at 5:38 AM, Phill <[email protected]> wrote: >> I'm running into this problem as described in the javadocs for >> HttpsRequestCycleProcessor: >> >> "Notes: According to servlet spec a cookie created on an https request is >> marked as secure, such cookies are not available for http requests. What >> this means is that a session started over https will not be propagated to >> further http calls because JSESSIONID cookie will be marked as secure and >> not available to http requests. This entails that unless a session is >> created and bound on http prior to using an https request any wicket pages >> or session values stored in the https session will not be available to >> further http requests. If your application requires a http->https->http >> interactions (such as the case where only a login page and my account pages >> are secure) you must make sure a session is created and stored in the http >> request prior to the first http->https redirect." >> >> When my users start a session via the sign-in page protected by >> @RequireHttps they are then redirected to a non-ssl but >> authorisation-protected page, but as there is no insecure session at that >> point they are bounced back to the sign-in page again. >> >> I would really appreciate some suggestions as to how others users deal with >> this issue i.e. how could I ensure that a session is created and stored in >> the http request prior to the first http->https redirect? >> >> I thought about having a non-ssl protected sign-in page which has an >> immediate javascript redirect to the ssl version but it doesn't seem very >> elegant. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
