Welcome Guest, Not a member yet? Register   Sign In
sessions managment
#1

Hi Team,
We autoload session library and make good use of the cross page storage mechanism. (file based).
My config is as follows:

$config['sess_driver'] = 'files';
$config['sess_cookie_name'] = 'MyAppName';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = '/var/www/html/saved_sessions';
$config['sess_match_ip'] = false;
$config['sess_time_to_update'] = 3600;
$config['sess_regenerate_destroy'] = false;

and my /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

I have a few problems which may be my misunderstanding!

1) We are using these sessions files currently to detect if a user already has a session open (ie we store a "logged_in" var in the session data). Unfortunately the logic detects any old regenerated session, that is left on the file system. It appears the old sessions are never being garbage collected and deleted? Not sure why


2) We currently use a cookie to store the session_id. However it appears to be a session_id from our domain name rather than the subdomain we are doing all our testing on. Again I'm not sure whether this is a good or bad thing.

I know sessions are quite sensitive and have read many articles giving advice.

So, I would like to know a) are we using sessions wisely/correctly? and b) is there a better way to limit a user to a single logged_in session on our website - in brief what are the best practices I should follow?

Thanks, Paul
Reply
#2

(This post was last modified: 05-14-2018, 12:12 PM by jreklund.)

session.gc_probability = 0
1) You have garbage collector turned off; based on your settings.
You got an Ubuntu server? Look and see that you got a cron job running.
/etc/cron.d/php5

2) You need to set the following to limit the login to just one domain (or subdomain).
/application/config/config.php
$config['cookie_domain'] = 'subdomain.domain.com';
$config['cookie_secure'] = TRUE; // You are using https right?

a)
1. Lowercase this
$config['sess_cookie_name'] = 'myappname';

b) One user can only be logged in from one computer? Then you need to use database storage instead of files. And query the database and see if there are any open sessions for that user and destroy it.
(If that's the case, don't do that... I'm logged in on some websites from 3 devices)
Reply
#3

Thanks jreklund- Could you clarify a bit further please as I don't understand some of your comments.

1) The CI notes talk about GC as though it was something CI controls. Am I right in understanding that GC is a native function of the php system under which CI runs?

2) I do indeed have a script in /etc/cron.d

09,39 *     * * *     root   [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi

So does this mean I am or am not getting any GC? If this is running I am not seeing any of my regenerated session files being deleted?

3) why should the cookie name being lowercase?

4) We are reviewing the need to only allow a single session. However, can you see or explain any possible conflicts by allowing multiple sessions?

Thanks for you help, Paul
Reply
#4

Sure, I will do my best.

1) There are a garbage collector function named gc() that are being called in session_set_save_handler(). This function lets PHP know how garbage collection should work for your application.
Code:
The garbage collector callback is invoked internally by PHP periodically in order to purge old session data. The frequency is controlled by session.gc_probability and session.gc_divisor. The value of lifetime which is passed to this callback can be set in session.gc_maxlifetime. Return value should be TRUE for success, FALSE for failure.
As you have an Ubuntu server your session.gc_probability are set to 0. And therefor your session are never deleted. As CI relies on the native garbage collection.

2) I haven't run a CI application under Ubuntu so I don't know if that cron script actually will trigger CI garbage collection. You need to open that script and see what it actually does.
So you can solve it by:
1. Set session.gc_probability = 1 (and disable cron)
2. Write your own PHP script that just calls CI's gc() function, and runt it with cron.

3. In the good old days Internet Explorer had some problem's with it. So you had to do my_app_name. Old habits die hard.

4. If you are a bank or something; I can see why you only want one session. But other then that your users will just get irritated. There won't be a conflict as long as you store a unique cookie (remember me, if that's allowed), else PHP will handle it for you and time your users out depending on your sess_expiration setting.
Reply
#5

ok thanks for all that - appreciated.

One further query if I may please?

Your point 4 - How would having a unique cookie help say 3 user sessions which each (presumably) have their own unique session_id? Furthermore what would you suggest using for the unique cross-session cookie?

Nearly there!

Thanks, Paul
Reply
#6

Sure, ask away. :-)

You only need to generate a different unique cookie if you allow users to use "remember me". CI already generates a unique cookie that match the current session file.

If you want to write your own:
https://paragonie.com/blog/2015/04/secur...ersistence

But I'm using a modified Community Auth, for login and remember me.
Reply
#7

What an excellent article!

I shall be taking the advice asap :-)

Thanks for your patience.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB