+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23)
+--- Thread: multiple session cookies with session library (/showthread.php?tid=55210)
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]Tom Vogt[/eluser]
There are a couple older topics on this, but I've applied all their proposed solutions to no effect.
CI generates multiple session cookies, all with the same name. That's a bug, and probably the cause of my Heisenberg logout issue where it randomly logs me out of my application and tells me the session is expired.
I'm using database sessions, I have useragent verification disabled, I've applied the AJAX fix posted here - still, I get up to 5 session cookies for cisession (yes, I've already removed the underscore as well).
WTF is going on?
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]skunkbad[/eluser]
I've been using CI for a few years, worked with all versions back to 1.6.X, and made at least a couple dozen applications. I've used just about every browser on Mac, Windows, Ubuntu, and Lubuntu, as well tested in iPad and Android. I've never had the problem you are saying you have. It's gotta be in your code or config, and not a CI bug. You'll need to do some debugging, share some code, or both. I'd suggest starting at re-installing your /system/ files. I've learned the hard way that a corrupt download can make for some craziness. Next, with a stock installation of CI, make a single controller to test the session. That would verify you don't have a problem with your server or browser. Once you're satisfied, then move on to debugging the actual creation of the cookie(s).
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]Tom Vogt[/eluser]
Any help appreciated.
There is one and only one place in the code where I call set_userdata:
Code:
public function login($User) {
$this->ci->session->set_userdata(array(
'user_id' => $User->getId(),
'client' => $this->ci->config->item('client')
));and my session config is:
Code:
$config['sess_cookie_name'] = 'cisession';
$config['sess_expiration'] = 7200;
$config['sess_expire_on_close'] = TRUE;
$config['sess_encrypt_cookie'] = TRUE;
$config['sess_use_database'] = TRUE;
$config['sess_table_name'] = 'ci_sessions';
$config['sess_match_ip'] = FALSE;
$config['sess_match_useragent'] = FALSE;
$config['sess_time_to_update'] = 300;My application is AJAX-heavy, and I'm using the URI routing feature quite a lot. I'm very certain that my download is not corrupt. I'm using CI 2.1.0
If anyone has a clue on where to start looking - let me know.
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]WanWizard[/eluser]
Getting multiple cookies is a side-effect of the way the session libary works: every time you update something it writes a new cookie.
This can lead to issues when you have a session rotation in the the middle of your request, because
"If multiple cookies of the same name match a given request URI, one is chosen by the browser.
The more specific the path, the higher the precedence. However precedence based on other attributes, including the domain, is unspecified, and may vary between browsers. This means that if you have set cookies of the same name against “.example.org” and “www.example.org”, you can’t be sure which one will be sent back."
This means a browser can pick any, and if you have 10 cookies for the session, and after number 6 the id is rotated, there is quite a large chance that the browser will pick the wrong one, and the next request goes out with an invalid cookie...
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]CroNiX[/eluser]
I wonder if this can be fixed by using a "queue" for session writes, where it would store all requests to write to the session and perform only one db write/issue one cookie when the session class __destructs for everything stored in the queue.
I do something similar for logging cron jobs performed. While processing the cron jobs it is storing everything that is performed in a class property (array) and when the cron job finishes and hits the __destruct(), it sends an email listing everything that was processed. Maybe something similar could work here as well.
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]skunkbad[/eluser]
So, is this only a problem when there are multiple ajax requests going on at the same time? I've never noticed any problems like sessions dropping for no reason, but my ajax usage is usally limited to one request at a time. Even when using the database to store CI sessions, you still have a session cookie as an identifier. It seems strange that nobody has ever fixed this. Sounds like it qualifies as a bug.
I've noticed that there are identical names for cookies to be set in the CI session, but never noticed that multiple cookies are set:
Code:
Set-Cookie: communityAuth=knu9s+laUsjy5yRBotw; path=/
communityAuth=1LdeyBDh8DFz0zwB6hw; path=/
communityAuth=H05qYyLqOjv6LRUVj; path=/
communityAuth=jUnxm+aiGuN6HTpmi; path=/multiple session cookies with session library - El Forum - 10-15-2012
[eluser]skunkbad[/eluser]
[quote author="CroNiX" date="1350329669"]I wonder if this can be fixed by using a "queue" for session writes, where it would store all requests to write to the session and perform only one db write/issue one cookie when the session class __destructs for everything stored in the queue.
I do something similar for logging cron jobs performed. While processing the cron jobs it is storing everything that is performed in a class property (array) and when the cron job finishes and hits the __destruct(), it sends an email listing everything that was processed. Maybe something similar could work here as well.[/quote]
This seems like a good solution. I was just looking at the session class, and if everytime it calls _set_cookie, the setcookie() params were stored in a private property (array), then on destruct the last array element could be used to set the cookie. This assumes the last call to _set_cookie() had the real cookie contents we want.
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]WanWizard[/eluser]
Just looked into the latest code, at some point they seem to have the rotation issue fixed (it now rotates in the constructor).
set_userdata() calls sess_write(), so every update of the session adds a new cookie to the list. What also can happen (but I haven't tested it), there's a maximum length of about 4Kb voor a line in the HTTP header. If you have a lot of duplicate cookies, this line can get very long. Perhaps that's the cause of the session being dropped? This problem can get worse if you store session data in the cookie...
I'm currently struggling with a PyroCMS install which suffers badly from this issue, and no Ajax in sight. I sometimes login, open a forum message, click on reply, and when I submit, the session is already gone. Drives me nuts...
p.s. just checked, every 'pyrocms' cookie adds over 600 bytes to the Set-Cookie header. More then 6 and it's over. This could be a possible cause, I'll see if I can reproduce the session loss by setting lots of cookies.
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]WanWizard[/eluser]
Did a quick test. Firefox and IE9 seems to be happy with large response headers, Chrome kills the connection when it recieves one, but on the next request re-uses the cookie already stored locally.
So this doesn't seem to be it.
multiple session cookies with session library - El Forum - 10-15-2012
[eluser]skunkbad[/eluser]
I don't know if you guys have the time to help work on a solution for 2.1.3, but I'll contribute time. I'd like to come up with a MY_Session. I've never had a problem with sessions, but I don't want to find out the hard way that I should have worked on this problem. I guess in a pinch I could just use the new CI v3.X session, but I'd like to not do that because of the change in license.