Unstable CI Session - Githubissues

taranti555 commented 11 years ago

Sometimes CI cannot read its own cookie file, and keeps on changing session ID. This error is practically impossible to reproduce, but about 2% people, especially IE users complain about it. Me, personally have seen it only ones. I have tried everything I could think of: • Using DB for CI session; • Made sure that 4k space is not exceed; • Clearing browsers cookies manually; • Playing around with the settings in every possible pattern; This is the worst error in CI, which lead me to consider other frameworks. Please correct for v3.

tkaw220 commented 11 years ago

Examining PHP session cookie name and I fixed the problem by renaming CI session cookie to $config['sess_cookie_name'] = 'CISESSION';.

AkenRoberts commented 11 years ago

Underscores in cookie names were an issue for older versions of IE. Also, if you are using ajax, there is a known issue regarding session ID's being overwritten that is still in discussion.

If you have more information about what the underlying problem is, please provide it. If it's "practically impossible" to reproduce, you can't expect others to do it for you.

ckris commented 11 years ago

I found problem in Session intialization method with function register_shutdown_function(array($this, '_update_db')); when try to use session in third_party

taranti555 commented 11 years ago

I will try to test to see if the underscores are the problem but I doubt it. As I have said, I encountered these error ones on my PC and another time I managed to convince my website user to give me an access to his PC through teamviewer. Since the problem is rare, I had to pay this person, for him to give access to me for 15 minutes. My website traffic is over 100k, so people write me about his every day and it’s not only on this website. Same goes for all of my other websites. One of the things I have checked for is trying different browsers. All of the seemed to not have been working. Chrome, Safari, Mozzila, IE and Opera. However, for some reason the problem also disappears with 24 hours by itself. So usually, I recommend to my users, to come back next day. That has lead me to believe that the problem may be in cookie expiration time but in that case why do clearing all browsers cache not helping to solve the problem.

narfbg commented 11 years ago

People please ... stop the cookie-name madness - this has never been a real problem! Even microsoft.com has cookies with with underscores all over the place and nobody has faced an issue with it. Just because changing a cookie name from f_oo to foo has fixed a problem for somebody, it doesn't mean that the underscore is the issue - a change from f_oo to b_ar would've fixed it as well.

These are the problems with session cookies:

Concurrency:
- Partially solved by disabling ID regeneration on AJAX requests.
- SHOULD be solved by server-side locking. This is only easy to do with file storage, hence the new "native" Session driver, which does that by default.
- COULD be solved by switching AJAX calls to synchronous. i.e. in jQuery: $.ajaxSetup({async: false});
CodeIgniter's sanitizer dropping them due to erroneously detected "malicious" data.
Incorrect time settings on the client side (solved in PHP 5.5: https://github.com/php/php-src/pull/238).
Cookie name collisions, where you'd have 2 applications on the same domain send the same cookie name - this is where the cookie name change helps.

@ckris has found another known problem, which however didn't exist in 2.1.3 and is not related to this issue.

taranti555 commented 11 years ago

Thank you for you comment narfbg, but the thing is that none of the listed cases apply to my situation. I have simple login form <form class="login-form" action="/do_login" method="POST">, without any AJAX. In fact, ajax is used in many parts of the website, and I haven't experienced any troubles with session due to xhr requests.

All my websites have different cookie names and the time is set properly. I also use the latest version of NGINX for server side.

I am not sure how to check this: CodeIgniter's sanitizer dropping them due to erroneously detected "malicious" data.

TheDigitalOrchard commented 11 years ago

There's also an issue of session files being stored in the server's /tmp directory, which periodically can be purged. That used to happen on a server that I was managing all the time.

AkenRoberts commented 11 years ago

Microsoft themselves said that cookies were blocked for certain circumstances when an underscore was present. Clearly it was a problem for enough people that it became well-known (whether it was something that CI caused or not).

narfbg commented 11 years ago

@taranti555 You'll just have to dig in the Session code and your cookie data, I can't really give you any other tips.

@TheDigitalOrchard That's a configuration/environmental issue solved by changing session.save_path in php.ini. And it's an issue for PHP's session extension only anyway, it isn't necessarily related to this problem. Actually, it's highly unlikely as I doubt that @taranti555 uses the "native" driver.

@cryode That page talks about underscores in the hostname/domain part of a cookie, not the cookie name. And it's quite natural - the underscore isn't a valid hostname character. Still - it has nothing to do with underscores in the cookie name.

taranti555 commented 11 years ago

@narfbg It is hard to dig at all, if the error cannot be reproduced. CI sessions don't use PHP native sessions at all, but just in case, I checked that native sessions are working fine. To be honnest, I was trying to solve this problem during last two years and I have tried so many things that I've lost faith on the way. I will wait for CI v3 and should it not be solved there, I guess only two choices will be possible, eighter to change to a new framework or to use another session handling class.

narfbg commented 11 years ago

Wait ... you haven't actually checked if the problem is fixed in CI 3.0-dev?!

kakysha commented 11 years ago

@narfbg, having 3.0 (actually cloned two weeks ago), having issues with session cookie dropping. In log file there are lines "The session cookie data did not match what was expected.". Users also report on login credentials dropping at random time while browsing the site. Cant reproduce by myself, because everything is ok for me, no cookie droppping for about 2 months, but some users say that it can happen 5-6 times a day. They are using latest Chrome, my config is:

$config['sess_driver']          = 'cookie';
$config['sess_valid_drivers']   = array();
$config['sess_cookie_name']     = 'ci_session';
$config['sess_expiration']      = 0;
$config['sess_expire_on_close'] = FALSE;
$config['sess_encrypt_cookie']  = TRUE;
$config['sess_use_database']    = FALSE;
$config['sess_table_name']      = 'ci_sessions';
$config['sess_match_ip']        = FALSE;
$config['sess_match_useragent'] = FALSE;
$config['sess_time_to_update']  = 300;

$config['cookie_prefix']    = '';
$config['cookie_domain']    = '';
$config['cookie_path']      = '/';
$config['cookie_secure']    = FALSE;
$config['cookie_httponly']  = FALSE;

Seems like problem is in encryption... Switching to DB sessions cant help, because i need to store some sensitive data, so the encryption still will be in play. P.S. cookie size is about 500-600 bytes, encryption_key is 32 bytes long.

narfbg commented 11 years ago

@kakysha Obviously, if you can't reproduce it ... neither would I. You could try logging the cookie itself both at send and receive times and see what the mismatch is for your complaining visitors. I'd suggest you open a separate issue for that when you have more details.

elvispt commented 11 years ago

@kakysha I remember having a similar issue and I ended up finding the problem on the user agent string being reported by the browser. In the specific case, it was due to Firebug + FirePHP, depending if the user had Firebug opened or not. Firebug closed: 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0' Firebug opened, refresh on the same page: 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 FirePHP/0.7.2'

Hope it helps.

AkenRoberts commented 11 years ago

If you have sess_match_useragent disabled, that won't make a difference.

chadfurman commented 11 years ago

Make sure the cookie domain is set to something like:

$config['cookie_domain']    = '.mysite.com'; // the . is for a wildcard subdomain

XiaoningLiu commented 10 years ago

Hi guys, I found a helpful link for this problem!! It's an encryption bug of Codeigniter.

I am using code igniter 2.2 and got the same problem. Codeigniter sometimes will try to create a new session instead of using the current one. I opened 'sess_encrypt_cookie', 'sess_use_database' and 'global_xss_filtering'.

Finally I found this page: https://ellislab.com/forums/viewthread/237467/ . I think what the guy said is right. It's an encryption buy of Codeigniter!

By default, when set 'sess_encrypt_cookie', Codeigniter will encrypt the cookie data with base64. However, when browser sends the encrypted data back, Codeigniter's 'xss_filter' will remove some chars of that. o(╯□╰)o

It's strange that Codeiginter didn't solve the problem until now.

KalanaPerera commented 8 years ago

still this issue is there, version 2.2.1

narfbg commented 8 years ago

2.x is no longer supported.

errd commented 7 years ago

And what is conclusion to this long thread? How to eliminate this error? Updated to 3.1.5 this weekend and this is still issue for me.

narfbg commented 7 years ago

This was a bug report about CI2 and the "conclusion" is that we don't care about CI2 anymore.

Whatever issue you are experiencing is 100% not the same thing, but if you need help please post on our forums instead.

bcit-ci / CodeIgniter

Unstable CI Session #2384