Code Igniter Session problem

[eluser]Unknown[/eluser]
An attempt to resurrect this thread...lots of good info here

I'm having relatively the same issue. The site works fine in every browser except IE6, tested across multiple machines. Every page refresh IE6 starts a new session, and I cant seem to figure out why. I've tried all of the mentioned solutions except the E_ALL method (probably next), the time on my server is correct, no invalid characters. Anymore ideas?

[eluser]Jan van Casteren[/eluser]
Are you still waiting for the answer? I think I have the solution, because I struggled with the same this week, and I found the solution today: you should not only check your servers clock, but also your own! Seems that smart browser like Firefox don't rely on end user's clocks, but IE7 does (at least in my case), so IE6 probably does so as well.

[eluser]wicahyanto[/eluser]
Just doing little experiment with my computer clock, It seem the problem is differences between our computer clock and server clock.

I set the cookie expire to default (sess_expiration = 7200) , I change my computer clock 1 hour faster then test the session function on IE. The session session is still working fine.

I change my computer clock 3 hour faster than server clock, then the session function on IE didn't working. So I assume when differences between server clock and computer clock more than sess_expiration, our session will initialized as new session ... Just think to use native PHP session

[eluser]Unknown[/eluser]
Thank everyone for the info here.

This problem has been vexing me for some time now. I tried all manner of fixes to the session object but they just kept getting rejected by safari and firefox. Tonight when I went into my log directory to start tailing the log before another bout of debugging I noticed that the year part of the date was 0000. "That's odd," I said aloud, "I guess the server date is off. Config issue." and then went about some simple debugging.

After a bit I surfed the web again this time for "safari, firefox session codeigniter", then I hit this paydirt. Let me tell you all, it doesn't have to be that your server is out of sync. There can be something far worse. Like perhaps your server is old. Like mine, old as dirt. I'm using a PPC Mac for dev. It doesn't get much attention from the PHP world. That's how a bug in date formatting/calculation can crop up!

That's right, all this talk about time reminded me of that log file with the year of 0000 rather than 2009. It appears that somewhere in late september or early october mac updated the version of PHP (or I did?) to a new release that had a bug. PHP now believes it is year 0000 on the PPC build that I have. See the bug: http://bugs.php.net/bug.php?id=48276, which is fixed in CVS, and maybe in a final build, but I'm not so sure about messing with PHP on my system.

My fix is to just prepend the "20" and use date('y') instead of date('Y') to two calls in system/helpers/date_helper.php. Yes, it's a hack, but it gets session working (and lord knows what else) and I'm not expecting this app to run for 90 more years. I may not check this in and only have it run on my dev machine. Either way, thanks for pointing me in the right direction.

[eluser]RJ[/eluser]
Installing the new native session library overriding CI sessions immediately ironed out my issues. Maybe should be considered core?

[eluser]Stilly[/eluser]
if I am not wrong the new native session library does not support storing sessions in the database?

[eluser]Pavel M.[/eluser]
IE needs domain name for cookie:
config.php

Code:

$config['cookie_domain']    = ""; // Set to .your-domain.com for site-wide cookies

[eluser]WanWizard[/eluser]
And native PHP sessions automatically determine the cookie domain from the hostname if none is defined.

Swapping libraries is no solution for poor configuration!

[eluser]SitesByJoe[/eluser]
[quote author="Pavel M." date="1286296246"]IE needs domain name for cookie:
config.php

Code:

$config['cookie_domain']    = ""; // Set to .your-domain.com for site-wide cookies

[/quote]

Has this ever been verified? Even with 24 hours cookies, I still occasionally hear about IE session loss.

[eluser]WanWizard[/eluser]
All session solutions require proper configuration, and proper understanding of the cookie mechanism.

Most of the problems reported fall in the first category, a problem which is becoming bigger now that modern browsers implement a stricter enforcement of the cookie RFC. For example, you will see that browsers that enforce this RFC, will reject cookies with hostname 'localhost'. Also empty domains, or domains like ".com" will be rejected, and hostnames and/or domains that don't match the host/domain in the URL.

Second thing to understand is that sessions are implemented using a cookie. The cookie is sent to the browser in the HTTP header of the server reponse, and contains (at least) the session_id. When a new request to that same server is made, the cookie is sent back to the server in the HTTP header, where it is picked up by the application, which matches the session_id from the cookie with session data in whatever server side storage mechanism is chosen.

Knowing this, you have to be careful with anything that interferes with the normal request/response flow. In particular, redirects. A redirect interrupts the server response, which in some situations causes the cookie not to be send to the browser.
If this happens when the browser already has a valid cookie, there is no issue. If this happens when it's a new session, or when CI has just rotated the session_id (which by default happens every 300 seconds), you have an issue, because the session_id on the server doesn't match what you have on the client.

You have a similar issue with Ajax calls. The response of an Ajax call doesn't include a cookie. So if CI decides that it's time to rotate the session_id on an Ajax call, again the session_id on the server is updated, but the cookie in the browser still has the old session_id. So at the next page request, no valid session is found.

And then there are server side bugs. One well known one concerns IIS up to version 7, which deletes cookies from the HTTP header if that same header contains a "Location" redirect.

Also some browsers appear not to process/store cookies if the HTTP header contains a "Location" redirect.