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
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp
_______________________________________________
QP mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp
