@RequireHttps start session before redirect to secure page

[Phill <ph...@bicispace.com>]

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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: @RequireHttps start session before redirect to secure page

[Phill <ph...@bicispace.com>]

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 <ph...@bicispace.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: @RequireHttps start session before redirect to secure page

[Igor Vaynberg <ig...@gmail.com>]

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 <ph...@bicispace.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org