Why session is automatic/random expired or site logout with https? - codeigniter

I am using Codeigniter and this is my application/config/config.php
$config['sess_driver'] = 'files';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 0;
$config['sess_expire_on_close'] = FALSE;
$config['sess_encrypt_cookie'] = FALSE;
$config['sess_save_path'] = 'application/session';
$config['sess_match_ip'] = TRUE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
$config['cookie_prefix'] = '';
$config['cookie_domain'] = '.example.com';
$config['cookie_path'] = '/';
$config['cookie_secure'] = TRUE;
$config['cookie_httponly'] = TRUE;
Site is automatically redirect to https using .htaccess.
When site working on http only with sess_match_ip, cookie_secure and cookie_httponly with FALSE then it is working fine. but when working on https it logout automatically/randomly.
What is the proper configuration for https?

Since your site is running on load-balanced servers, the issue is not the cookie_secure atribute but the files driver.
When using the files driver, the session information is stored locally on the server that responds to your request. Depending on your load-balancing configuration, the user may change servers between requests. If that happens, when changing servers, the new server will not have the user's session information and thus he'll be logged out.
You have basically two choices here:
1.- Tweak your load-balancing configuration to enable sticky sessions of some sort. This will prevent, in most but not all cases, that the user jumps between servers. It's by far the easiest solution, but it has some drawbacks. If a server goes down and the load-balancer HAS TO move the user to another server, he'll be logged out, so one of the benefits of load-balancing will not be such in your case.
2.- Change your session storage to another driver (such as database) that's independent of the server who is responding to the user. Contrary to the files driver (in which each application server stores its own local session info), a database, redis or other session driver would use a single centralized storage for session data. So, regardless of the user jumping from server to server on each request, he'd remain logged in seamlessly.
My suggestion would be to go with the second choice, try using a database (the CI documentation is very self-explanatory on this matter) and you'll be fine :)

Related

CodeIgniter session keeps restting

I'm struggling with a session issue so bizarre, I don't even know how to start debugging it.
I have a CI 3.0.0 project that has been up and running (and constantly being developed) for several years now.
Last week I switched to a new hosting service, and ever since then, I've been experiencing session issues, where session data keeps resetting at various intervals.
The switch to the new host was done by the hosting company - they say they copied the whole cPanel account as is, including files & database. One change I did make on the new server is defining the cookie_domain, which was previously unset, to ".mydomain.com".
When I started having problems with the sessions, I changed it back to $config['cookie_domain'] = ''; but that did not help.
My session/cookie settings in config.php are as follows:
$config['sess_driver'] = 'database';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 14400;
$config['sess_save_path'] = 'ci_sessions3';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
$config['cookie_prefix'] = '';
$config['cookie_domain'] = '';
$config['cookie_path'] = '/';
$config['cookie_secure'] = FALSE;
$config['cookie_httponly'] = FALSE;
I use sessions mainly to hold user login details, and here's what I use in my basic page template, to check whether the user is logged on and has the appropriate permissions. If they do, I load the requested page view. If not, I load the login form.
What happens now is that after the user has logged on and started using the system, after a very short time, they are thrown back to the login form, as if the userdata has been somehow reset.
if (!$this->session->userdata('admin_logged_in') || empty($this->session->userdata('digital_view_perms')))
{
$main_content = 'admin_digital/login_form';
}
$this->load->view($main_content, #$data_rows, #$prev_code, #$action);
Any pointers as to where I should start digging for problems would be highly appreciated!
The only thing I know for sure has changed is the hosting service. The php version on the new server is 7.0.28, whereas the php version on the old server was 5.6.33.
Thanks!
I had this problem when I changed the php version to 7.0
Download the latest version of CI3
Replace the System/ folder by the new one!
You need to update your framework to the latest version for it to work with PHP 7
Update your framework! To fix that issue

Coldfusion 10 cross domain HTTPS session problems

Just wondering if anyone has come across an issue in CF10 whereby sessions are dropped when crossing between subdomains for the same Application under HTTPS, even though the JSESSIONID is being explicitly passed in these links which had worked for us for over 5 years without fail prior to CF10. From what I have read there appears to be a big change to address the Session Fixation security issues in CF10 which explains why the sessions would drop jumping between HTTP and HTTPS but this doesn't explain my issue. I understand the Session Fixation changes introduced in CF 9.02 and CF will definitely have an impact on our passing JSESSIONID via the URL, however this behaviour has been removed still the session is dropping.
Essentially we have CF10 installed with J2EE Session Management turned on, and the default HTTPOnly set to true. This is a single CF Application with the same Application name, setClientCookies is false and in the application the domain structure looks as follows:
https://book.domain.com
https://profile.domain.com
https://approve.domain.com
When crossing between the domains (which had worked for many years prior) the session drops and CF issues a new set of session identifiers.
Even setting a cookie in the onSessionStart() as follows has no effect:
<cfcookie name="jsessionid" value="#session.sessionid#" domain=".domain.com" secure="true">
Has anyone come across this behaviour migrating to CF10?
Cheers
Phil
So after playing around with a number of settings and ideas I now have the sessions behaving across the subdomains mentioned in my original question over HTTPS and using secure (browser based) cookies, thereby satisfying PCI-DSS Compliance requirements. All passing of JSESSIONID via the URL was removed from the system and the following lines added into the Application.cfc for both the constructors and the onSessionStart(). Note the setDomainCookies and setClientCookies set to false and the Domain specific sessioncookie settings below and also note in the onSessionStart my cookie being set without an expiry to ensure it only lasts for the duration of the browser, and the new CF10 encodeValue attribute to prevent strange encoding issues with the cookie values:
<cfcomponent hint="Application" output="false">
<cfscript>
// Application Settings
this.name = "myApplication";
this.applicationTimeout = createTimeSpan(0,2,0,0);
this.clientManagement = false;
this.loginStorage = "session";
this.sessionManagement = true;
this.sessionTimeout = createTimeSpan(0,1,0,0);
this.setClientCookies = false;
this.setDomainCookies = false;
// Domain specific settings for session persistence over subdomains
this.sessioncookie.domain = '.domain.com';
this.sessioncookie.httponly = true;
</cfscript>
<cffunction name="onSessionStart" returnType="void" output="false">
<cfcookie name="jsessionid" value="#session.sessionid#" secure="true" domain=".domain.com" encodeValue="false">
</cffunction>
</cfcomponent>

Https (SSL) in Codeigniter not working properly

I have a CI site with several form using jquery .click function, when I was in http its worked well, when I change to https all the form click button cannot be fire, its happen in localhost and in web host as well, is that anything need to config to run CI in https?
please advise and thanks!
Solved:
I just remove the url from $config['base_url'], and now the issue is solved, but I wonder how come when running https couldn't set value on $config['base_url']? hope someone would clear my doubt.
Thanks guy for taking time to view my question.
Set your base_url protocol independent:
$config['base_domain'] = 'yourdomain.com'; // a new config item if you need to get your domain name
if (isset($_SERVER['HTTP_HOST']))
{
$protocol = ($_SERVER['SERVER_PORT'] == 443 ? 'https://' : 'http://');
$config['base_url'] = $protocol.$_SERVER['HTTP_HOST'];
$config['base_url'] .= str_replace(basename($_SERVER['SCRIPT_NAME']),"",$_SERVER['SCRIPT_NAME']);
}
else
{
$config['base_url'] = '';
}
I am guessing your ajax request fails because you are trying to access no-secure content from a secure site.
I had a similar issue. I simply changed the base URL from HTTP to HTTPS in the config file and it worked well for both protocols.
# Base URL in codeigniter with HTTP
$config['base_url'] = 'http://mysite.abc/';
# Base URL in codeigniter with HTTPS
$config['base_url'] = 'https://mysite.abc/';
Remember, when you change HTTP to HTTPS, the site should work well for both protocols but it doesn't work the other way around.

Codeigniter session doesn't work?

I have a website based on Codeigniter which works fine. I had to clone this site with database to an another host. I copied the database and all files. My problem is: the session doesn't work on the new site. (I recognized it at the login). The same code works on the old host, but everything is exactly the same.
Does somebody have any idea? Is it a codeigniter configuration issue?
Thanks
Check your application/config.php
especially these lines:
$config['cookie_prefix'] = "";
$config['cookie_domain'] = "";
$config['cookie_path'] = "/";
$config['cookie_secure'] = FALSE;
Also: please delete your cookie-history
(if you're using Firefox: CTRL-SHIFT-DELETE)
Alternatively you could use (shameless self-plug) codeigniter-native-session
I too had a bit to much problems with the built-in session engine.
It basically mimics the Codeigniter session class so just drop in these files into your application folder and code doesn't needs any modification. (and you'll be using PHP-native-sessions)
Hope it helps.

Code Igniter Login, Session and Redirect Problem in Internet Explorer?

I'm still new to code igniter and I'm having problems getting the login system to work.
The login always works when I use Firefox. The login consistently works on some IE7 browsers but consistently fails on other IE7 browsers.
When tracing the code, I see that the models/redux_auth_model.php does successfully authenticate the user, it writes user information into the $this->session->set_userdata() and it redirect them to a member's page of my choosing. Here's the code:
public function login($identity = false, $password = false)
{
$identity_column = $this->config->item('identity');
$users_table = $this->tables['users'];
if ($identity === false || $password === false || $this->identity_check($identity) == false)
{
return false;
}
$query = $this->db->select($identity_column.', email, password, group_id')
->where($identity_column, $identity)
->where('active', 'Active')
->limit(1)
->get($users_table);
$result = $query->row();
if ($query->num_rows() == 1)
{
//$password = $this->hash_password_db($identity, $password);
if (!empty($result->activation_code)) { return false; }
if ($result->password === $password)
{
$this->session->set_userdata($identity_column, $result->{$identity_column});
$this->session->set_userdata('email', $result->email);
$this->session->set_userdata('group', $result->group_id);
return true;
}
}
return false;
}
I did a variable dump of $this->session in both IE7 and FF and confirmed that all the userdata is intact before the redirect. The session had my email information, group information and $identity_column information.
However, after the redirect, the session data is empty on some IE7 browsers, which is why CI keeps booting me out of the system. It's fully intact on other IE7 browsers and always intact in Firefox.
Why would session data be browser dependent?
Any ideas on how to troubleshoot this further? I am baffled...
It is a frustrating problem with the Codeigniter database session class, in the end I resorted to using native sessions using the drop-in replacement found here: https://github.com/EllisLab/CodeIgniter/wiki/Native-session
I was having the same problem while using CI Session in IE. Then I use the below header in controller constructor and it works for me.
Here is the header:
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
I faced the same problem while using IE8 with browser mode. I've found the problem is in matching the user agent. In session database it saves useragent as IE7 but from cookie it gets IE8. I've set $config[sess_match_useragent] = FALSE and the problem is solved.
The session class works fine in several of my projects including IE6/7/8 support (including multiple releases of CI). There are a few things that might be causing this, outside of the code pasted above:
Calling $this->session->sess_create(); from a baseclass (or elsewhere in your class's code) would reset your session.
Try combining your set_userdata calls to one call by passing it an array.
Make sure your data does not have any unexpected characters in it (this can cause issues in certain browsers).
Make sure your session class settings in the config are not rolling over the cookie every request.
Alternatively, consider an alternate session class like Native sessions
This is an issue that someone made a 3rd party fix for, it patches the session controller. Let me dig it up. I have used it in my codeigniter setups since it was first noted.
This issue is IE7/IE8 specific with redirects or frames.
EDIT
Here is the reference that I have found before, it helped me with the IE issue. Hopefully this is what is causing you headaches:
http://www.philsbury.co.uk/blog/code-igniter-sessions
It's a problem with browsers. I put this in MY_Controller in constructor:
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
for example:
if($this->uri->segment(1)=='admin') header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
We were developing an app involving a Facebook tab when we ran into this problem. We tried the above to no avail. Here's what we found out:
IE privacy settings seem to have to be medium or less
If your running a page app, make sure BOTH URL's have HTTPS protocol in them
Also, look into the Compact Privacy Policy for cookies.
config file application config.php
// 'cookie_secure' = Cookies will only be set if a secure HTTPS connection exists.
$config['cookie_secure'] = FALSE;
I solved this by using native php session instead of cookies (Storing codeigniter session_id in php native session).
You can grab library here: https://github.com/staskus/codeigniter-2.--native-session.
Just copy MY_Session.php file into applications/libraries
The problem is IE denying the cookie CI is trying to set. Native sessions is one way, however if you want to keep using CI sessions I have had success with the following troubleshooting:
Check that setting $config['cookie_domain'] in config.php is not empty
Remove the underscore from $config['sess_cookie_name'], for example change "ci_session" to "cisession"
Check that the server time is correct
I hate IE !!!
its working now giving P3P to our controllers fix the problem :
class Chupacabra extends CI_Controller {
function __construct() {
parent::__construct();
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
}
This issue plagued me when I was trying get a login page to work in CodeIgnitor. The session would not save.
It turns out that it was due to a domain name that I created from FREEDNS that contained an underscore (_). I renamed the domain name using a period (.) and reverted all the code changes that were suggested in this post, and Voila, it worked.
Thanks for all the comments and contributions on this page because they really led me down the road of investigating that darn underscore.

Resources