Search code examples
databasecodeignitersessionpyrocms

PyroCMS / Codeigniter : too many session entries in db

I'm using for a small website the pyrocms / codeigniter combo. after adding some content, i checked the db and saw that: multiple session id's

is this a normal behaviour? multiple session_ids for one user with the same ip? i can't imagine that this is correct.

my session config looks like:

$config['sess_cookie_name']     = 'pyrocms' . (ENVIRONMENT !== 'production' ? '_' . 

ENVIRONMENT : '');
$config['sess_expiration']      = 14400;
$config['sess_expire_on_close'] = true;
$config['sess_encrypt_cookie']  = true;
$config['sess_use_database']    = true;
// don't change anything but the 'ci_sessions' part of this. The MSM depends on the 'default_' prefix
$config['sess_table_name']      = 'default_ci_sessions';
$config['sess_match_ip']        = true;
$config['sess_match_useragent'] = true;
$config['sess_time_to_update']  = 300;

i did not change on line of code affecting the session class or something like that.

the red hat rows belong to a 15min cron-job. this is fine i think.

everytime a refresh the page two or three new session_entries are added...

Solution

  • Yes, this is normal. The CI session class automatically generates a new ID periodically. (Every 5 minutes, by default.) This is part of the security inherent in using CI sessions instead of native PHP sessions. Garbage collection will take care of this, you do not need to do anything.

    You can read more about the session id behavior in the CI manual. This is an excerpt copied from that page.

    The user's unique Session ID (this is a statistically random string with very strong entropy, hashed with MD5 for portability, and regenerated (by default) every five minutes)

    This behavior is by design. There is nothing to fix. The session class has built in garbage collection that deletes old entries as needed. I have many projects using code igniter for several years. This is what it does.

    If it really bothers you, you can alter the timeout in the main CI config file. Change the line

    $config['sess_time_to_update'] = 300 (the 5 minute refresh period)

    to a number greater than

    $config['sess_expiration'] (default 7200)

    This will cause the session to timeout before it is regenerated. This is inherently less secure in theory, but unless you are transacting sensitive data, it is probably irrelevant in practice.

    But again, this is by design as part of the many layers of CI sessions. These and other features are what make it better than PHP native sessions. You can turn on profiling and see that the overhead for these queries is negligible, especially in light of all the other optimizations the framework provides.