SSL Logins that lead to HTTP pages

How to manage sessions on multiple servers?

[ryan_b83]

Hello, I had a question regarding managing logins. In a situation where a user goes to a HTTPS page to login securly then posts to a script that processes the login. Then the user is logged in but the remaining pages are nolonger using SSL. How would this be done if the SSL server would have its own session, and the HTTP server would have its own session?

Thanks,
Ryan

[rocknbil]

When I swap from a secure to a non-secure server, I send the sessionid as a form or querystring variable and set a new cookie using that value. Same when I go back, this keeps the sessionid synchonized. This is a good question as I've always felt this is a "workaround."

[lexipixel]

rocknbil - Can this be done in a way that doesn't produce a "switching from secure to non-secure" or a "mixed (content)" warning?

The reason I ask is I find when I go on a site that uses https, and switches and I get the warning, I feel like there may be a security error (especially if money or financial info is involved)... I know it's a client side warning, but it breaks the flow and makes me pause to think "is this a redirect" or "is this a reseller framing my session for the actaul seller".

[jatar_k]

you would always get the error

anytime you post from secure to non secure you are 'breaking' the security.

The best bet would probably be to have the sites use the same database and manage the sessions there. You could add an id to the url for the redirect and then grab the corresponding data from the db.

though I guess if you use GET then it shouldn't give you the error anyway.

maybe just using GET for https to http is the way to go.

When you go from non secure to secure it doesn't matter.

[rocknbil]

Can this be done in a way that doesn't produce a "switching from secure to non-secure" or a "mixed (content)" warning?

Maybe I misunderstood the question - no, you cannot post out of a secure location. You can't even curl non-secure data without a warning.

What I meant was if you are tracking a session or (example) cart on a non-secure server, when you move to a secure server (or vice-versa) you lose track of that session because you can't read the non-secure cookie on the secure domain (or vice - versa.) So by sending a form value or query string for the sessionid, you can set a new cookie on the secure domain, then when you return to the non-secure domain you will be able to read the old one. Moving OFF the secure server has to be done by ordinary links.

At the first available opportunity I present all the links as non-https links - those won't kick secure warnings.