Session logout Problem -- db sessions

[eluser]Unknown[/eluser]
I am having a problem with my site where many users are logged out automatically after some time on the site. I have also experienced the bug occasionally on my own computer while working, but at first it was difficult to replicate.

Now, I have found a possible source of the problem, and I am wondering if you think this is a feasible source of the error. My guess is that $config['sess_time_to_update'] is at fault.

I find that I can quickly recreate the logout bug by by lowering my sess_time_to_update variable from 120 to 2.

Code:

$config['sess_time_to_update']     = 2;

Using selenium, I am able to bombard my site with page refreshes and then check when the user gets logged out. When selenium is set to refresh the page as fast as it can and update time = 2, I am able to immediately replicate the logout bug (i.e. the session gets logged out). However, if selenium is set to refresh slowly, or if I just refresh by hand, it is more difficult to get logged out (but it still can eventually happen).

Is it possible that when the session is being updated, another call is being made to get the current session, and these two database calls are having a collision or made in such a way that it is logging the user out?

e.g.
1) session starts getting updated in database
2) site redirects, calls to see if user's cookie agrees with what's in the database ... it doesn't because it hasn't been updated yet
3) user gets assigned a new cookie as "not logged in"

Other ideas on the problem or how to fix it? For now, I have just increased my sess_time_to_update to 600. Thanks!

[eluser]Stu Green[/eluser]
Is anyone getting this problem?

I'm having log out problems. Sometimes when working lots on a website with lots of page refreshes and posting data, I get logged out sometimes.

My settings are:

$config['sess_expiration'] = 3600;
$config['sess_encrypt_cookie']= TRUE;
$config['sess_use_database'] = TRUE;
$config['sess_match_ip'] = FALSE;
$config['sess_match_useragent'] = TRUE;
$config['sess_time_to_update'] = 1200;

[eluser]Cro_Crx[/eluser]
There's a lot of factors here, it would be good to get more information (specifics)...

Have you tested multiple browsers ?
What version of CI are you running ?
Are your database tables using transactions ?
Have you inspected the session information when these events occur ?
Are you storing your session cookies in the database or in files ? (sounds like database from above)
How much information are you storing in your cookies ? (File cookies only have 4k limits which sounds like a lot but when you have $config[‘sess_encrypt_cookie’]= TRUE; then it's not very much at all!

[eluser]Stu Green[/eluser]
Thanks for the reply, I'll have a look at the cookie limit thing and get back to you. In the mean time what do you mean by "tables using transactions?"

Thanks

[eluser]Cro_Crx[/eluser]
You only need to worry about the size limit of cookies if you aren't storing them in the database so as your config is set to use the database then you don't need to worry about it.

Transactions are used in databases to make sure that either all or none of the operations take place. So for example let's say you want to create a new user then log that you have created them. You'll need to insert a row into the users table and then insert a row into the log table. Transactions make sure that either both of these happen, if one of them fails for whatever reason then the other will be rolled back.

MySQL supports transactions, although the default storage engine MyISAM doesn't support them. You need to use InnoDB or another storage engine to get their benefits.

[eluser]Stu Green[/eluser]
Then the answer is no, not using transactions.

Am using the DB though for storage. Am running latest version of CI. Have tested in multiple browsers. The problem is intermittent I can't easily replicate it. Just wondered if anyone else is getting this problem.

[eluser]intractve[/eluser]
Battled with this problem for almost a week,
Problems live around any AJAX

I have posted a solution
http://ellislab.com/forums/viewthread/138823/

[eluser]BrianDHall[/eluser]
On the cookie size limit, I'm afraid this isn't exactly true if you are using the CI session implementation and storing in the database. CI by default still stuffs session info in the cookie even if it is in the database too, so getting it too big can still cause issues - but I don't think that's what is going on here.

I would recommend you try setting CI to use a database to store the session simply so you can keep track of it. Then when a person logs in you can see what data the session has (database id number, variable content, etc), then when you force a logout you can see what happened to sessions in the database.

It would be very helpful to know what happens - does the session still exist and the data gets lost, or is the old session there and the logged out person now has a fresh session?

That would narrow down the theoretical range of problems.

[eluser]yacman[/eluser]
natedogg, I made a mistake creating the dbsessions table and typed the lastactivity column as a timestamp, rather than an INT(10) column. This would cause all sessions to get wiped out by the random garbage collection (making it a random issue) with the db session.

You can always dig into the session controller and output debug statements, or turn debug statements on to see what's going on with the sessions controller:

/system/libraries/Session.php

_sess_gc() is what fires off when a probability occurs. Setting your config files debug level to 'debug' will start showing messages from each of the core libraries assisting you in seeing what is going on behind the scenes.