losing session variables on switch to https:
Moderator: General Moderators
losing session variables on switch to https:
At least, I believe that's what's happening. I haven't figured out how to replicate it myself on ANY of our own machines, or my own home... but a percentage of my users are having the problem, using similar setups to those we have here. The only consistent difference I can detect is that many of them seem to be using Windows XP, whereas all of our machines use Win2000. Nothing unusual about these peoples' security settings, etc.
Anyway, does anyone know WHY this would happen? Is it a server setting? Client setting? Is it an issue with the actual certificate itself? The physical server is not changing, but the protocol is, and as soon as that switch happens, people are losing data. Rather bad, it is.
Anyway, does anyone know WHY this would happen? Is it a server setting? Client setting? Is it an issue with the actual certificate itself? The physical server is not changing, but the protocol is, and as soon as that switch happens, people are losing data. Rather bad, it is.
The most important question is whether they are maintaining the session cookie.
In all likelihood, when you switch from http to https, the domain on the cookie (not to mention the secure/not-secure setting in the cookie) is changing.
Not only that, but in IE5.5sp2 and above (including IE6 on XP), IE wisely refuses to let you set third-party cookies.
In other words, site A - the HTTP site - says "here is a session cookie for site B", and IE says "go stuff yourself".
There are a number of reasons for that, all related to security.
The point is, you need to ensure that the session cookie gets set once they transition to the https side.
In all likelihood, when you switch from http to https, the domain on the cookie (not to mention the secure/not-secure setting in the cookie) is changing.
Not only that, but in IE5.5sp2 and above (including IE6 on XP), IE wisely refuses to let you set third-party cookies.
In other words, site A - the HTTP site - says "here is a session cookie for site B", and IE says "go stuff yourself".
There are a number of reasons for that, all related to security.
The point is, you need to ensure that the session cookie gets set once they transition to the https side.
Unfortunately, I'm not sure. I'll admit that I've only done a handfull of https programming with sessions, and they all occured IN https.Unipus wrote:Well, that all makes sense, but the question is: how? How do I set up the new session variables with the same values as the old?
Because some may have over-ridden the defaults which block third-party cookies. (cross-site cookies).Unipus wrote: And why is this only happening on SOME instances of IE6?
Others may be running older (not IE6, more like IE5) versions that dont have that protection.
Then perhaps it is a DNS issue - they may be resolving the DNS entries differently. Cookies work via DNS/domain, so check the NS resolution on each to see if they resolve the http/https domain differently.Unipus wrote:Nope. It's actually happening on similarly configured, IDENTICAL versions of the same browser (6.0.2800.1106). That's the part that makes me all confusedy... I'm still not sure where the problem really lies.
Aha. It appears to be an incredibly disparaging bug in PHP itself. That's somewhat reassuring, but also very worrisome. [/url]