Thread

Thanks Jonathan Angel. Removing the ‘_’ worked for me.

Is the general confusion here around how cookies work?

I think the op brings up some interesting points, but the e-debate seemed to get pretty heated.

Honestly, there’s so many problems with cookies in general (like security), I just prefer to never rely on them 😊

In general: Yes. And in how that reflects on how you should configure CI and use sessions.

Now that browsers are slowly implementing much needed security features, those with sloppy configs now start complaining that their application no longer works. And guess who’s fault it is?

It’s like with any other piece of code you write and feature you use: understand it thoroughly before using it, use it properly, and don’t make any assumptions about the environment, as it may change.

I had problems with CI sessions, the server was just refusing to set any cookies. The generic PHP cookie operation was working well, but CI was unable to set any cookie, including session one.
I found that PHP core configuration option “output_buffering” in php.ini must be:

output_buffering = On

for CI to be able to set cookies.

This is not related to CI, but to HTTP specifications.

If you don’t use output buffering, cookies (or any HTTP header for that matter) have to be send before you start sending output. If not, PHP throws a notice error (headers already send).

If you had suspected CI, you didn’t see the error. So make sure you have all error reporting active and display errors enabled in your development environment to spot such errors.

Back to CI:

The session library sets the session cookie every time your call sess_write(), which gets called when you update session data. This can happen anywhere in your application flow.
However, CI uses the Output class to buffer all output, compress it if needed, and send it out. Which only happens after your controller is finished and has returned control to the front controller.

So even with output buffering off this is not an issue, unless your application generates output that bypasses the output class (i.e. every echo or print statement). In a CI app, this is not-done!

Hi,

I have a weird problem and I don’t know if it has something to do with the computer itself or if it’s how I’ve implemented the authentication.
I’m using CI 1.7.2 using the built in session class and it all works fine for the majority of users, except one user who can’t seem to keep his session alive.
He’s on Win XP and tried both Chrome and IE7.

So basically he logs in and as soon as it redirects him to the home page, it logs him out.
I can see that the session info is being created in the sessions table, but Chrome and IE7 can’t seem to authenticate against it.

So eventually we tried Firefox on his machine and it works!

So does anyone have any idea, why it’s not working for Chrome and IE7?

And the ‘majority of users’ don’t have problems with IE7 or Chrome? Or do they all use other browsers?

He’s the only one that’s got the issue. I’ve tried to use Chrome and IE7 (VM fusion) on my mac and the site auth works fine.

was facing same problem of session with IE 8. Many threads suggested for underscore, timezone difference. Real problem is timezone difference. CI creates cookie with server time and IE checks expiry related to client timezone. And here issues comes. You can not change time zone of online server to match clients from all over world. The better solution is change cookie / session expiry time. By default it is two hours. Change it to 24 hours and problem will be solved.

In config.php file change value of following variable

from two hours

$config[‘sess_expiration’]    = 7200;

to 24 hours

$config[‘sess_expiration’]    = 3600 * 24;

check http://www.cogitsolutions.com/blog/2011/06/codeignitor-ie-session-problem/

By default it is two hours. Change it to 24 hours and problem will be solved.

While this will probably solve the problem, it’s not ideal.  I don’t know of any other actual solutions to the problem though.

FWIW, the two extreme time zones on Earth differ by 26 hours, but I doubt you are likely to have a server in one and a client in the other.

The timestamp of a cookie in the headers is specified in GMT, which browsers convert to local time before verification.

The problem here is that CI allows you to define the time as either server- or gmt time in your configuration (which is ok), but the session library uses this value to determine the value of now (not ok!). So if you have set your config to local time, and the difference between your local time and GMT is 6 hours, your session cookie timestamp will be 6 hours off.

This needs to be fixed in the session library (always use GMT for the cookie expiry timestamp). This is a know issue for ages, but apparently nobody has fixed it yet, since it’s still present in reactor.

While this will probably solve the problem, it’s not ideal.  I don’t know of any other actual solutions to the problem though.

FWIW, the two extreme time zones on Earth differ by 26 hours, but I doubt you are likely to have a server in one and a client in the other.

I know this is not idea but as I see this is only solution without editing core files. In config there is option to close session when browser is closed. We can set that to make it more secure. I did not try that whether it actually works or not but seems it should work.

thanks for time zone info. One should change it from 24 to 26 but mostly that may not required because most of the servers are US based. Also most of the site are targeted for specific territory only.

It should indeed be fixed by Ellislab or the reactor team.

This bug has been there for years, but appearantly hasn’t bothered anyone enough to complain about it…

For those looking for a fix, I have resolved my problem:

I took a few minutes to diagnose the same problems described with CI Sessions and DX Auth.

First, I synchronized both server and client time (both where wrong). Temporarily the problem subsided; however, it mysteriously stopped storing the session. So.. I checked the database and no session or login attempt was being recorded.

Second, I began reading this and other discussions and found that by removing the underscore (_) in the CI config.php file, the problem was resolved.

Original:

$config['sess_cookie_name'] = 'ci_session';

Modification:

$config['sess_cookie_name'] = 'cisession';

I no longer have a problem with sessions in IE8 on WinXP.

For those that attempt to resolve their problem using these methods, please post your results, good or bad.  By the way… uber-fan of CI.

I tried this and it worked im using a windows 7 with IE8.
It’s incredible how many people still use that piece of crap.
Thanks for your help :lol:

I’ve proposed removing the underscore in the core via a pull request and it was rejected by Derek Jones himself stating that an underscore is valid in cookie names.  So, it’s not likely to get fixed, even though it solves many peoples problems, ‘valid’ or not.