| Baby Mamber
Join Date: Apr 2004
Posts: 2
|  One of the reasons people cannot login to mambo using IE
I noticed a very irritating bug in our development mambo environment, there was inability to login to our test mambo site when using IE6. Mozilla Firefox from the same machines was able to login! Not only that, but some IE6 machines managed to login all times, while the rest could not login at all (they were thrown back to the login page). A IE5.5 machine was tested and proved to be working.
As I've investigated in the web, similar problems existed and were reported but no certain solution had been given. So, i decided to devote my weekend in tracking down the problem. Here's what I've found, feel free to experiment and tell me if that solved your problems.
Go to classes/mambo.php, approx line 142 and change:
the line : setcookie( "sessioncookie", $session->getCookie(), time() + 43200, "/" );
into : setcookie( "sessioncookie", $session->getCookie(), time() + 2*86400, "/" );
----------------------------------------------------------------
I'll put a short analysis for everyone who's interested.
Debugging the core revealed that there was inability in IE6 to accept a cookie named "sessioncookie" (although it was a persistent cookie, instead), while Mozilla was correctly accepting it. However, IE6 did not behave consistent, since it was accepting the subsequent cookie "mosvisitor" (which IS a real session cookie, btw).
So, I went into the normal procedure of cursing Microsoft, etc etc about its new IE6 monster and dug the registry and the web. It's amazing what kind of extraterrestial bullshit one can find on the web these days - better than reading scifi!!!
In a few words nothing helped, lost my time and mood and got to work to reveal that the cookie was in fact rejected by IE6 because of incorrect expiration time. No connection with the notorious security of IE6 as I'd originally had suspected. Here's what's happening:
In a correctly set up computer system, the system clock among with timezone and dst settings produces the "local time". In such a situation, the hardware clock should be having GMT time. The concept is such, so there may be a universal reference point, that is the GMT time itself.
Back in our story, as I can see from my windows box, the settings allow to set timezone between GMT-12 and GMT+13 and optionally set dst. I may use them correctly (and set my hardware clock to GMT) or may misuse/ignore them (and set my hardware clock time to something other than GMT). However, regardless of our geographical position on earth and the way you and I will manage to accomplish set our correct local times, our hardware clocks will have a maximum ABSOLUTE possible difference of +13-(-12)+1=26h. My hardware clock may be 26h before or ahead of yours, and that second case is the worst, considering our little example below. (as a note, we ay that for the same moment of the planet, the local clocks of us two may display an absolute difference of up to 25h, with the assumption we have correct "local times")
Let's talk local times for a little. Suppose that I visit your website when my local clock says t. You may have a local time t' in the range of t +- 26h from me. You send me a cookie with duration of "time()+12*60*60" . If you are unlucky, t>=t'+12 and I junk your cookie. I cannot login to you. On the other hand, if you are +26h from me, local time, and give me +12h from that, the cookie will last +38h on my system - not exactly what you intended, either case, huh?
So, to avoid that mess, a synchronization with the GMT is required. This is how it is done in the HTTP protocol. Server reports its GMT time and the cookie expirations in GMT time as well. But what do the browsers do?
IE6 does store the GMT expiration time and checks it against the hardware (supposedly GMT) clock of the client. Mozilla rewrites the expiration time as expiration = client_local_time + cookie_GMT_expiration - server_GMT_time . It then checks the expiration against the local time. This works, seems to make more sense to the common user and does not have the requirement of the system clock being close to GMT.
To sum up, IE seems more succeptible to errors and this is exaclty what I've seen in practice. However I cannot blame microsoft - as far as I've seen they have not done something wrong, according to the specs. They could just do it better than the specs, just like Mozilla.
Now, to the mambo source. Although it's open source and fits better with mozilla, we have to do something about IE6. So, server machine must be correctly configured in terms of local time/timezone/dst. The only thing we can do is give IE6 some more time. I raise the interval from 12h to 48h. So, Mozilla should compute
expiration = client_local_time + cookie_GMT_expiration - server_GMT_time
= client_local_time + server_GMT_time + 48h - server_GMT_time
= 48h with respect to client time
and IE6 should compute
expiration = cookie_GMT_expiration
= server_GMT_time + 48h with respect to GMT time as thought at client side
As seen, too, in the IE6 case it is up to the correct server and client settings to approach the spec. We can cure he server, we cannot control the client. This is why I prefer the mozilla way.
Since server and client GMT times may differ +-26h under normal conditions, the margin of 48h allows the cookie to pass to all browsers. If client is too far away in the future, the cookie will be rejected in IE6, but not in mozilla. This was happening in my case, although the time difference was very marginal to let some IE6 systems set the cookie. The situation was also reproduced in IE5.5, although the initial observations on this browser tended to lead to the opposite direction. Phenomena deceive...
Of course, you may add more than two days if you wish to be safer. So, now that you know what I know you may run your tests and tell me if it is all OK. If you have the phpbb2 component from websmurf you may need to modify some session code there as well - just look for setcookie at includes\session.php. If it dows not work for you, please check for incorrect date/time/timezone/dst values/settings in server/client, whether you run PHP as a CGI in IIS and if you use a browser older or equal to than IE4 SP1. If you do so, it's time you start your own quest on the web. Enough spoken, time for action. |
Re: One of the reasons people cannot login to mambo using IE 
Re: What Do I Do Now??? 
Linear Mode
