session expires earlier on community auth

I have started to the community auth for my project, very easy set up if just follow the instruction carefully.

Thanks to the great work, the basic functions work well.

I only found out a small issue, which I don't know if your guys also experienced. The $config['sess_expiration'] doesn't work exactly same as the seconds I set. For example, if I set this variable to 604800 (7 days/ a week), I found the session timed out around the 3rd day.


I am using CI 3.1.0

Allen

I have started to the community auth for my project, very easy set up if just follow the instruction carefully.

Thanks to the great work, the basic functions work well.

I only found out a small issue, which I don't know if your guys also experienced. The $config['sess_expiration'] doesn't work exactly same as the seconds I set. For example, if I set this variable to 604800 (7 days/ a week), I found the session timed out around the 3rd day.


I am using CI 3.1.0

Allen

Allen, please show all of your session config. Have you looked at your cookie information immediately after logging in?

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

I have started to the community auth for my project, very easy set up if just follow the instruction carefully.

Thanks to the great work, the basic functions work well.

I only found out a small issue, which I don't know if your guys also experienced. The $config['sess_expiration'] doesn't work exactly same as the seconds I set. For example, if I set this variable to 604800 (7 days/ a week), I found the session timed out around the 3rd day.


I am using CI 3.1.0

Allen

Allen, please show all of your session config. Have you looked at your cookie information immediately after logging in?

Hi Brian, thanks for your reply

Here is my session globals in config.php

$config['sess_driver'] = 'database';#'files';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 1209600;
$config['sess_save_path'] = 'ci_sessions';#NULL;
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = TRUE;#FALSE;

Have you looked at your cookie information immediately after logging in?

I just did on the Chrome, and found 4 cookies

Name: ci_session
Content: 050fa60ec3ccaf3958700dcf350cc60b2b6de7a0
Domain: 10.10.1.143
Path: /
Send for: Any kind of connection
Accessible to script: No (HttpOnly)
Created: Wednesday, December 21, 2016 at 11:28:58 AM
Expires: Wednesday, January 4, 2017 at 11:28:58 AM

Name: csrf_cookie_name
Content: b37f0986a623222e0477bc615af278db
Domain: 10.10.1.143
Path: /
Send for: Any kind of connection
Accessible to script: Yes
Created: Wednesday, December 21, 2016 at 11:28:58 AM
Expires: Wednesday, December 21, 2016 at 1:28:58 PM

Name: httpUser
Content: 4ba0d7660f0c1a7d8d936b1a7b08e957e3bb95940fd32342cb29a14578b3a7628fa796664a203d0b019f227972da47751a6afdfae0beab70937a7a04f99ebfa7Vl5StovO3MZxviZQ7CiUIb%2Bf2Ra3l%2FNbNBx7rrZiNdE%2BRpn9LSHqGfsNQ53FBGT%2B7Guw5LmWJ0oqhO0DhUq8CA%3D%3D
Domain: 10.10.1.143
Path: /
Send for: Any kind of connection
Accessible to script: Yes
Created: Wednesday, December 21, 2016 at 11:28:58 AM
Expires: When the browsing session ends

Name: httpsTokens
Content: da16dc191595577b135b095c8a44bd47728d53fb0d6b846c842cd269edc7f03f4ff034513443312eff85c56f98e36d19df43a3174d7c79c6878d551ee0b72290dCroBJhY5gMREfDPMjKUE37MU3hKjHbm64192W8CY%2BY%3D
Domain: 10.10.1.143
Path: /
Send for: Secure connections only
Accessible to script: Yes
Created: Wednesday, December 21, 2016 at 11:28:58 AM
Expires: When the browsing session ends

Cookies look normal, and ci_session cookie shows 10 days. Now, when you look in your database, do you see a row in the ci_sessions table with values that look normal? Also in the auth_sessions table?

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

Cookies look normal, and ci_session cookie shows 10 days. Now, when you look in your database, do you see a row in the ci_sessions table with values that look normal? Also in the auth_sessions table?

I found sometimes when I refreshed (F5) the same logged-in page, it generated a new session entry in the ci_sessions, and the key in auth_sessions was updated correctly, so the page stayed logged in

However, after a while (a few days), when I clicked F5 again, then it inserted a new entry in the ci_sessions, but a very short one, i.e. as below

| 6ef552162c671e1e9c8a8759cf9f8309426adf1c | 10.10.1.142 | 1482173543 | __ci_last_regenerate|i:1482173543;

That is when the expiration started.

Most of the session regeneration stuff is part of CodeIgniter, and has nothing to do with Community Auth. Just so you know how the session is used in Community Auth, I'll break it down for you. It might help you debug, but be aware that older versions of Community Auth had an issue with session regeneration, so make sure you're using the latest version.

1) CodeIgniter sessions are combined with Community Auth's auth_session table so that there is always a database record associated with a logged in user, regardless of whether you use file or database based sessions.

2) Because the CodeIgniter session and the auth_sessions table are working together to manage the session for the authenticated user, during session regeneration the session ID needs to be updated in the auth_sessions record. This action is part of what you see in the MY_Session library, and also the reason why the auth_sess_check hook exists. We're just always making sure that the auth_session and CI session have a matching ID.

Beyond that, there really isn't anything going on for existing sessions, but there are some Community Auth sessions related configuration that you'll find. If you look at those though, you'll find that unless you've specifically changed them, they're mostly turned off and not making any difference in the way sessions are handled. The one that would cause a problem though would be "disallow_multiple_logins". If that is set to TRUE than if you were to log in at a different computer and come back to the first computer, the session on the first computer would have been deleted. Again, this is turned off by default.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

Most of the session regeneration stuff is part of CodeIgniter, and has nothing to do with Community Auth. Just so you know how the session is used in Community Auth, I'll break it down for you. It might help you debug, but be aware that older versions of Community Auth had an issue with session regeneration, so make sure you're using the latest version.

1) CodeIgniter sessions are combined with Community Auth's auth_session table so that there is always a database record associated with a logged in user, regardless of whether you use file or database based sessions.

2) Because the CodeIgniter session and the auth_sessions table are working together to manage the session for the authenticated user, during session regeneration the session ID needs to be updated in the auth_sessions record. This action is part of what you see in the MY_Session library, and also the reason why the auth_sess_check hook exists. We're just always making sure that the auth_session and CI session have a matching ID.

Beyond that, there really isn't anything going on for existing sessions, but there are some Community Auth sessions related configuration that you'll find. If you look at those though, you'll find that unless you've specifically changed them, they're mostly turned off and not making any difference in the way sessions are handled. The one that would cause a problem though would be "disallow_multiple_logins". If that is set to TRUE than if you were to log in at a different computer and come back to the first computer, the session on the first computer would have been deleted. Again, this is turned off by default.

Thanks for the explanation, I agree somehow the ci_session cookie was regenerated (I found today the issue happened again, I checked the cookies, and found it re-generated today, although the old one is supposed to be expired next Jan)

I will try to upgrade my CI to 3.1.2 today first

Most of the session regeneration stuff is part of CodeIgniter, and has nothing to do with Community Auth. Just so you know how the session is used in Community Auth, I'll break it down for you. It might help you debug, but be aware that older versions of Community Auth had an issue with session regeneration, so make sure you're using the latest version.

1) CodeIgniter sessions are combined with Community Auth's auth_session table so that there is always a database record associated with a logged in user, regardless of whether you use file or database based sessions.

2) Because the CodeIgniter session and the auth_sessions table are working together to manage the session for the authenticated user, during session regeneration the session ID needs to be updated in the auth_sessions record. This action is part of what you see in the MY_Session library, and also the reason why the auth_sess_check hook exists. We're just always making sure that the auth_session and CI session have a matching ID.

Beyond that, there really isn't anything going on for existing sessions, but there are some Community Auth sessions related configuration that you'll find. If you look at those though, you'll find that unless you've specifically changed them, they're mostly turned off and not making any difference in the way sessions are handled. The one that would cause a problem though would be "disallow_multiple_logins". If that is set to TRUE than if you were to log in at a different computer and come back to the first computer, the session on the first computer would have been deleted. Again, this is turned off by default.

Thanks for the explanation, I agree somehow the ci_session cookie was regenerated (I found today the issue happened again, I checked the cookies, and found it re-generated today, although the old one is supposed to be expired next Jan)

I will try to upgrade my CI to 3.1.2 today first

It turned out I have session cookie name collision.
I managed several projects on the same CI. because the projects use the same ci_session cookie name, so if switching it from one to another, it forced the ci_session to be regenerated. now I added a prefix for different project, it worked well.

PS: I found the prefix was automatically prepend to httpUser cookie, but not to httpsTokens.

I changed the line in config.php
$config['cookie_prefix']        = 'abc';

my browser got abchttpUser, but still httpsTokens.

Also I found in MY_Input.php

if ( ! is_numeric($expire))
{
           $expire = time() - 86500;                   
}

why did we want to set expire to yesterday? the set_cookie method usually called without $expire, so it will take the default value of "", then this line will be executed always. i.e. $this->CI->input->set_cookie( $http_user_cookie );

In config/authentication.php do this:

PHP Code:

$config['http_tokens_cookie']  = config_item('cookie_prefix') . 'httpTokens';
$config['https_tokens_cookie'] = config_item('cookie_prefix') . 'httpsTokens'; 


until I can properly fix the Tokens library.

.. and that expiration stuff in MY_Input is CodeIgniter code, not mine.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

In config/authentication.php do this:

PHP Code:

$config['http_tokens_cookie']  = config_item('cookie_prefix') . 'httpTokens';
$config['https_tokens_cookie'] = config_item('cookie_prefix') . 'httpsTokens'; 


until I can properly fix the Tokens library.

.. and that expiration stuff in MY_Input is CodeIgniter code, not mine.

Thank you so much for your help.

Its a great addin,