Managing user sessions

Team - relative novice - so please be patient!

I am using CI 2.2 on a LAMP installation (Ubuntu 14.02). Our website uses sessions and stores data in a mysql table. Certain user interactions have callbacks which I assume start new CI instances. What I am confused about is how I reconnect - if indeed this is possible - the new instances with the users current browser connection. The reason I want to do this is to use flashdata to pop up some information windows on their browser. Further I would like to be able to test whether they have a current browser connection and let my code behave accordingly. I have read about garbage collection of sessions which seems to suggest the session_id is not a guarantee of their session being open. We do user userdata to store small site-related array which includes a logged-in boolean. So if I test that and it says looged out, but the session still exists in my DB I would like to be a bit more certain abut what the enduser is or is not doing.

Can anyone shed some light for me - this must be a common problem with some common solutions!

Appreciated, Paul

It is very difficult to offer advice without being able to see the implementation code.

The existence of a record in the DB's session table is not an indication that the session is current. Expired sessions are removed from the DB when garbage collection (GC) occurs. Sessions that are "active" will not be removed from the table. How frequently GC happens depends on a couple of php.ini settings. But if CG does run it happens when the session class is instantiated.

When a session expires depends on the session $config settings, and to some extent, cookie config settings. So, if you add code to this thread please include those settings.

Hi Dave understood here are our current settings:

from /etc/php/5.6/apache2/php.ini
session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5

and from application/config/config.php
$config['sess_cookie_name'] = '*******';
$config['sess_expiration'] = 7200;
$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'] = false;
$config['sess_match_useragent'] = false;
#$config['sess_match_useragent'] = true;
$config['sess_time_to_update'] = 3600;

I am guessing these may be defaults.

If I set expire_on_close to true and then test the session when a new CI instrance is created and the user has closed their session can I assume safely they no longer have a browser open on our site?

As I mentioned earlier, we have a boolean value in userdata which I can test for "looged_in to our system or not" but what I really would like to know is if they are still browsing our site and have a current session open (albeit not logged in).

Hope you can see what I am getting at!

Cheers, Paul

If I set expire_on_close to true and then test the session when a new CI instrance is created and the user has closed their session can I assume safely they no longer have a browser open on our site?

The question is a non sequitur because creating a new CI instance means that a browser has sent a request to your server. Clearly somebody has a browser open on your site.

If the request comes from a user who previously established a session, and that session has expired (a.k.a. "closed") since the last request, then any data stored by the previous session is unavailable. It does not matter why the session expired - due to 'expire_on_close' or it timed out - expired is expired.

In your first post you state:

Code:

I would like to be able to test whether they have a current browser connection

You might have a mistaken idea about how browser and servers work together via HTTP. A browser sends an HTTP request and the web server sends a reply at which point the deal is done and the server forgets all about it. No kind of persistent connection exists. Web browsing is a stateless protocol.

You also stated the following in your first post:

I have read about garbage collection of sessions which seems to suggest the session_id is not a guarantee of their session being open.

I wonder, is this the main reason for your post? If so, you should know that your session won't be  "garbage collected" unless the session has expired. Rest assured that if your browser presents a valid session cookie to the server the server will be able to access data saved to that session. The caveat being you have to configure the CI session class correctly. It appears you have done that.

Dave many thanks - and I even had to look up non sequitur.
Unfortunately you have simply prompted me to probe a bit further, and try to get a better understanding from someone who knows.
1) If a new CI instance is associated with a browser what happens if our user clicks on a link in an email which then launches a class and method? Does this count as a GC trigger?
2) If browser comms are stateless what exactly is controlling expiry? Is CI somehow testing the cookie on a timer?
3) If a browser recives a rendered page after logging out from our site (effectively offering a login screen) can I still send flashdata to their screen? ie they still (I think) have an active session. If they have actually closed that browser tab and I try to send flashdata to their session_id as found in the DB, will it be queued for the next request?

I'm sorry if these are demonstrating my ignorance of this technology, but I hope to get much better very soon. Perhaps Iam just missing some vital building blocks ...

regards, Paul

1) If a new CI instance is associated with a browser what happens if our user clicks on a link in an email which then launches a class and method? Does this count as a GC trigger?

Maybe. Depends on when the session class is loaded. If session garbage collection runs (it doesn't always) it will happen when the session class is loaded i.e. $this->load->library('session');.

2) If browser comms are stateless what exactly is controlling expiry? Is CI somehow testing the cookie on a timer?

Sort of. Cookies are stored by the browser on the client's computer. When a cookie is created it is given a time (a timestamp) setting when it expires. (If set to 0, the cookie will expire when the browser closes.) An expired cookie is not used by the browser. IOW, the browser does the testing.

If the browser has non-expired cookies they are returned to the server with the other requested data. Access to session data is only allowed if one of the cookies is the session cookie that matches expected criteria.

3) If a browser recives a rendered page after logging out from our site (effectively offering a login screen) can I still send flashdata to their screen? ie they still (I think) have an active session.

Yes, if the session is active then flashdata can be accessed. If that's what you want, then the log out routine should not destroy the session.

If they have actually closed that browser tab and I try to send flashdata to their session_id as found in the DB, will it be queued for the next request?

Sounds like you are planning on writing to the session database outside of a user's request to the website. Is that the plan? Let's see.

1. If (big if) you can determine the correct db record to modify and
   
2. If you can correctly modify the record to represent "flash data" and
   
3. If, on the client side, the session has not been closed because $config['sess_expire_on_close'] = true; or
   
4. If the session (cookie) does not expire before the user returns to the site.
   

Then session data should be available when the user returns to the site.

By the way, closing the tab does count as a 'sess_expire_on_close' event. That event requires that the user exit the browser application. At least that's the case for the browsers I use for testing. Older, and/or less "main stream" browser apps might behave differently.

And for the love of all that is right and good upgrade to current version of CI.