On Mar 27, 2008, at 11:47 AM, Binger David wrote:
> 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?"

As both David and Maas suggest, you don't really do this... if a user
is authenticated over https then he should not be considered
authenticated on the same site over http... Maas suggests to terminate
the authenticated session over https when you switch to http. David
suggests the possibility (but not recommends) to "propagate" the https
authenticated session also to http. I believe there is little issue
with transmitting the session id cookie in the clear -- even if this is
eavesdropped, it should not be possible (at least not without a lot of
other additional trickery) for another client to hijack any server-side
session data (maybe David can confirm this?).

Before you embark on tricky performance optimizations of which protocol
to use for which resources, be aware that you may run into a number of
security constraints... the "same origin policy" imposes that resources
that do not have the same domain name, protocol and port should be
considered as coming from different origins (sites). This implies that
if you load a page over https and it loads javascript from the same
domain but using http, what that javascript may do on the page is very
limited... to start it would not be allowed to access the dom (thus no
client gizmo widget should work!).

mario