QP's Publisher sets cookies to "secure" if the authentication
happens over an https connection, so the client is not supposed
to deliver the same cookie over an http connection.
You could change that by overriding Publisher.fill_response()
on your SitePublisher.  Then your clients could remain
logged in after the "unsecure" redirect, but you should be
aware that you are transmitting the credentials of the session
in the clear if you take this approach.  Are you sure that
https is too slow for your application?


On Mar 26, 2008, at 6:43 PM, Tristan Short wrote:

> This relates to the recent post "How to unsecure qp pages?"
>
> Now that I can switch qp to deliver both secure and unsecure pages I
> get
> the following problem when using gizmo(qp) (and assume it exists in
> native qp too):
>
> Problem
> After JohnSmith authenticates securely over https I can readily get
> his
> User obj by calling get_user(). However, this only works on pages that
> are secured, i.e. accessed over https.  If a different page is
> actively
> unsecured and therefore accessed over http only, the anonymous User
> obj
> is returned by get_user() instead of the desired JohnSmith User obj.
> As
> soon as a secured page is accessed again JohnSmith is returned.
>
> Solution?
> Is there a way to easily get the authenticated user irrespective of
> whether or not the scheme is http or https after a secure login?
>
> BTW When the whole gizmo(qp) site is not secured (i.e.
> https_address= is
> not set in the SitePublisher configuration)  and thus the
> authentication
> is done over http, the get_user() method behaves as desired and
> returns
> the JohnSmith User obj for all the pages. I suppose that is a slightly
> obvious statement :-). But it does show that the authenticated User
> obj
> can be determined and retained under an http scheme.
>
> Tristan
>
>
>
> _______________________________________________
> QP mailing list
> QP@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/qp