Reputation: 498
After a month trying to solve this, and trying all kind of answers in related questions I decide to ask it myself.
This problems occurs on a new server we recently bought, the same code it's working fine on localhost and last server. But it's probably code related.
The Session is correctly created and the token is set, a var_dump shows that. But when the users tries to login, after redirecting to the access function, the Session token is not set, so the login doesn't occurs.
Even on the same page, if you refresh, the __ci_last_regenerate (which get the time when the Session was regenerated for last time) is the current time, and change after every single refresh.
In var/lib/php/session two different files are created after every refresh, don't know why. Here the pic:
The one at 19 secs hast the correct data (time and token), the last one only the time.
Also, we recently add a new subdomain to the site, so we have in the same server two different subdomains.
This is the Session configuration:
$config['sess_driver'] = 'files';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = NULL;
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
Tried also with DB driver, and it generated 2 (or 3 rows sometimes) on the table. The config was:
$config['sess_driver']= 'database';
$config['sess_cookie_name']= 'ci_session';
$config['sess_expiration']= 0;
$config['sess_save_path']= 'ci_sessions';
$config['sess_match_ip']= FALSE;
$config['sess_time_to_update']= 300;
$config['sess_regenerate_destroy']= FALSE;
$config['sess_use_database']= TRUE;
$config['sess_expire_on_close']= TRUE;
$config['sess_table_name']= 'ci_sessions';
And the output of database being its columns (id, ip, timestamp, data):
The data is always the same, a last regenerate containing the time and a token in one case, and only the last regenerate in the other (2 rows on each refresh).
PHP is 7.2.7 . CodeIgniter is 3.1.5.
Any further code needed or server information will be supplied if asked.
Edit 4/9: Also adding these cookie data, as asked by some users.
$config['cookie_domain'] = '.my-domain.com';
$config['cookie_path'] = '/';
$config['cookie_secure'] = FALSE;
$config['cookie_httponly'] = FALSE;
Upvotes: 6
Views: 8067
Reputation: 498
Okay, the problem was the Apache conf in our Centos 7 with the two subdomains.
We had both VirtualHost data inside the same httpd conf file. The fix was to create a different conf file for each domain. Something like:
domain1.com.conf
<VirtualHost *:80>
ServerName domain1.com
ServerAlias domain1
DocumentRoot /var/www/html/domain1
ErrorLog /var/log/httpd/domain1-error_log
CustomLog /var/log/httpd/domain1-access_log combined
</VirtualHost>
And the same for the domain2.
Hope this can help anyone.
Upvotes: 1
Reputation: 9
if you are using http server so set config_secure = false otherwise your session will be expired on every page refresh
check below
$config['cookie_prefix'] = '';
$config['cookie_domain'] = '';
$config['cookie_path'] = '/';
$config['cookie_secure'] = FALSE;
$config['cookie_httponly'] = FALSE;
Upvotes: 1
Reputation: 109
-make sure you initialized session library only once
$this->load->library('session');
-make sure it isn't autoloaded
application/config/autoload.php
- call session_write_close()
once you no longer need anything to do with session variables if you are using codeigniter version 3
-make sure you neither unset( $_SESSION );
nor destroyed it
session_destroy();
// or
$this->session->sess_destroy();
-sessions are affected by those cookies configurations application/config/config.php
$config['cookie_domain'] = '.your-domain.com';
$config['cookie_path'] = '/';
Upvotes: 1
Reputation: 3237
It looks like you're not storing session data anywhere but in the user's cookie, as it seems that your config reads
$config['sess_save_path'] = NULL;
Since you're using the files
driver, you should specify a location for the session data to be stored in the server. By default (out of the box), CodeIgniter is set-up like this:
$config['sess_save_path'] = APPPATH . 'ci_session/';
you need to specify a directory to which CodeIgniter can write to. Otherwise, if the session data is not stored in the server, whenever you try to do anything, the session in the cookie will not match against anything.
Remember, CI sessions are not exactly the same as native PHP sessions.
Furthermore, as CI itself states in the config:
| 'sess_save_path'
|
| The location to save sessions to, driver dependent.
|
| For the 'files' driver, it's a path to a writable directory.
| WARNING: Only absolute paths are supported!
|
| For the 'database' driver, it's a table name.
| Please read up the manual for the format with other session drivers.
|
| IMPORTANT: You are REQUIRED to set a valid save path!
UPDATE (Aug. 31 2018) Based on the updates you made to the original question:
There a a couple of un-needed/redundant settings in the session config when using database. These are all you need, anything extra on your setup should go away:
$config['sess_driver'] = 'database';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 0;
$config['sess_save_path'] = 'ci_sessions';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
I don't think that this is the case, but please check your code for any place you may be calling the native session_start()
function. Doing so makes CI session management behave unpredictably and one of the symptoms is that sessions do not persist (I learned this the hard way, spent around a month debugging until I found a single session_start call that was messing everything up)
Can you please check if the data
column in the sessions table is actually being written? (another symptom of the above). Try running this and if everything is returned as "empty", we may be getting closer:
select
case
when cast(data as char(1000)) = '' then "empty"
else "something"
end as content, count(*)
from ci_sessions group by content;
Also, keep in mind that actually creating the sessions table is not sufficient. Did you run the ALTER
that's required depending on your sess_match_ip
setting?
Upvotes: 2