Codeigniter sessions die

Question

After a little bit of use (25min - 1.5 hour) in my system, users experience a kick. For some reason my sessions are kind of dyeing. I think that the cookie on the client side somehow loses the session ID and creates a new one. I am saving my session data on Database.

This is my session conf:

        $config['sess_cookie_name']     = 'v2Session';
        $config['sess_expiration']      = 32400; //session will be 9 hours, for a shift.
        $config['sess_expire_on_close'] = FALSE;
        $config['sess_encrypt_cookie']  = TRUE;
        $config['sess_use_database']    = TRUE;
        $config['sess_table_name']      = 'ci_sessions';
        $config['sess_match_ip']        = TRUE;
        $config['sess_match_useragent'] = TRUE;
        $config['sess_time_to_update']  = 300;

Now, when I look in the DB I see multiple sessions for each user. Each kick means a new session and the old session is not deleted until it expires. When the session "detaches" the users need to login again.

Any help troubleshooting this will be appreciated.

EDIT:

So after some research I have noticed that the sessions die because the session_id that is saved in the cookie and the session_id that is saved in the database do not match. I suspect that this happens when the user loads 2 pages each on a different tab/window. One load happens just when the session updates the session_id and the second load (which kills the session) with the old session_id. The system looks for the session in the database and doesn't find it. Result: Kick from the system + mad user.

Has anybody experienced this? and does anyone have an idea on how to fix this?

Answer 1

Short answer.

Do not start session at multiple instances., just check for existing ones, if we are talking about Authorization, then kick the user to AuthLogin page if Session does not exist. Create a Auth class / library and let it handle things. If the session does not exist, it will ask to create another.

Those are not 'multiple' sessions, the unique Session ID is statistically random string with very strong entropy, hashed with MD5 for portability, and regenrated (by default) every five minutes)

-- Check here under How do Sessions work?

When you perform session_destroy, it destroys sessions (multiple or single) related to the user, from database and also expires the cookie. Yes, bad design, I know!

From your EDIT of question

So after some research I have noticed that the sessions die because the session_id that is saved in the cookie and the session_id that is saved in the database do not match. I suspect that this happens when the user loads 2 pages each on a different tab/window. One load happens just when the session updates the session_id and the second load (which kills the session) with the old session_id. The system looks for the session in the database and doesn't find it.

Opening page in multiple tabs = Refresh on single tab.

Are you setting Sessions without checking about their existence? Please share your script.

I will keep an eye on this answer until we have figured this.

Yes, I had similar issue, it turned out that I used to set sessions without checking if they already existed and everytime, I created them, they over-lapped the Session (cookie) in the browser and created another row in database. It sounds like you're facing the same issue?

Ugly hack

Set this as your config:

    $config['sess_cookie_name']     = 'v2Session';
    $config['sess_expiration']      = 32400; //session will be 9 hours, for a shift.
    $config['sess_expire_on_close'] = FALSE;
    $config['sess_encrypt_cookie']  = TRUE;
    $config['sess_use_database']    = TRUE;
    $config['sess_table_name']      = 'ci_sessions';
    $config['sess_match_ip']        = TRUE;
    $config['sess_match_useragent'] = TRUE;
    $config['sess_time_to_update']  = 32400; // Session will update in 9 hours.

This is one-of-a-kind issue... However, on analyzing that sessions are mis-matching with database, it clearly indicates that upon sess_time_to_update, database might not be updating the relevant id... However, this solution would still be an assumption unless you try it.