0
votes

I have a web application, in which i give an option of logging out. On logout the session is distroyed ie. deleted by sess_destroy() in system>libraries>Session.php.

but whenever the user logs out, token corresponding to user is deleted but instead new token is created in session table without any userdata.

Following is the flow it goes through when i redirect the user to login page again, the flow goes like this,

logout -> __construct() in login page -> __construct() in CI_Controller ->initialize() in Loader.php -> _ci_autoloader() in Loader.php -> $autoload['libraries'] in autoload.php -> __construct() in Session.php ->

if ( ! $this->sess_read()) {
        $this->sess_create();
      } else {
        $this->sess_update();
      } 

then in sess_read(),

        $session = $this->CI->input->cookie($this->sess_cookie_name);
        // No cookie?  Goodbye cruel world!...
        if ($session === FALSE)
        {
            log_message('debug', 'A session cookie was not found.');
            return FALSE;
        }

hence another it goes in sess_create(),and creates another session,

$this->userdata = array(
                            'session_id'    => md5(uniqid($sessid, TRUE)),
                            'ip_address'    => $this->CI->input->ip_address(),
                            'user_agent'    => substr($this->CI->input->user_agent(), 0, 120),
                            'last_activity' => $this->now,
                            'user_data'     => ''
                            );

when the sessions is created, it is assigned to the cookie, when the session is destroyed that cookie is deleted. but as soon as new page is loaded and session library is loaded along with it, it inserts new row in session table.

which increases the size of database, i would appreciate a suggestion by the community on this matter. also is anyone else facing the same issue?

p.s. I am using CI2

session destry,

function sess_destroy()
    {
        // Kill the session DB row
        if ($this->sess_use_database === TRUE && isset($this->userdata['session_id']))
        {
            $this->CI->db->where('session_id', $this->userdata['session_id']);
            $this->CI->db->delete($this->sess_table_name);
        }

        // Kill the cookie
        setcookie(
                    $this->sess_cookie_name,
                    addslashes(serialize(array())),
                    ($this->now - 31500000),
                    $this->cookie_path,
                    $this->cookie_domain,
                    0
                );

        // Kill session data
        $this->userdata = array();
    }
1
Please show us how you destroy your session - Lithilion
@Lithilion please check the updated code. Thank you - shellbot
I assume that you destroy the session and data and redirect to a "Logged out" page or the index. Could it be that you start a new session there? - Lithilion
yes when the user logs out, i redirect user to login page. There when the control flow goes to autoload.php the session library is loaded and in session's construct, another session is started without any data. - shellbot

1 Answers

0
votes

This is not unexpected in CI as Sessions are created/update whenever a visitor accesses anything that uses the session library. The fact that those sessions are "empty" (because the user is not logged in) is a little bit irrelevant. You could periodically empty the sessions table (by deleting all sessions with no data) but the amount of space you'll salvage is not that much.

All the above said, if you want to prevent the behavior you're experiencing, instead of destroying the session, just unset its variables so that it becomes empty.

unset ($this->session->userdata);

That way, the user will keep having the same session cookie and the only change is that it'll loose the data it contains in the database, effectively logging the user out.

EDIT: I'm not particularly familiar with CI 2 as all my code is on CI3 now and anything I once had on CI2 is long gone. But it looks like you're going through some unnecesary hoops with the session management rather than fully relying on CI's built-in functionality, which may be a little bit sub-optimal