Both CDbHttpSession and CHttpSession seem to be ignoring the timeout value and garbage collect data after a fairly short time (less than 12 hours). What could be the problem?
'session' => array(
'class'=> 'CDbHttpSession',
'autoCreateSessionTable' => true,
'autoStart'=>true,
'timeout' => 1209600,
'cookieMode' => 'only',
'sessionName' => 'ssession',
),
May be this is what you are looking for
Setting the timeout for CHttpSession just sets the
session.gc_maxlifetime PHP setting. If you run your application or
Debian or Ubuntu, their default PHP has the garbage collector disabled
and runs a cron job to clean it up.
In my apps I set the session dir somewhere in protected/runtime to
separate my session from other apps. This is important on shared
hosting sites and it's a good habbit. The downside is that I have to
remember to set up a cronjob to clean the files in that folder.
Anyway, you should also set a timeout when calling CWebUser.login to
log in a user.
from Yii Forum Post
Check duration parameter in CWebUser.login
Related
We moved our application to a new server and now the session is expiring too soon (not sure about exact hours) for the logged in users. We tried many things to find out why the session is expiring in a production environment but until now we are unsuccessful. We want to put the expiration for 20 days.
Stuff we tried:
This is the current configuration:
'Session' => [
'defaults' => 'php',
'cookie' => 'MYAPPHO',
'timeout'=> 80320, // in min
'ini' => [
'session.gc_maxlifetime' => 1728000, // in sec
'session.cookie_lifetime' => 1728000
]
]
We also tried to set the
'defaults' => 'cache'
and to set the values in .htaccess
php_value session.cookie_lifetime 1728000
php_value session.gc_maxlifetime 1728000
php_value session.cache_expire 1728000
but the behavior is the same.
We also made some debugging in the Network\Session::_timedOut() but is ok, is never expiring for that reason.
Is there any way to debug more and find out what is causing the session to expire?
Hackers would be delighted to have sessions never expire, because then any stolen session ID would become a permanent key to unlock your web application.
More details on why what you've tried with session.gc_maxlifetime and session.cookie_lifetime didn't work can be found here.
Anyways, you can do it by setting the value of session.gc_probability to 0 before starting the session.
Just try to restart your application server. Some times server cache behaves weirdly.Hope this will resolve your issue.
I setup my session timeout in CakePHP to be very long due to a business need, I configured it on core.php like this:
Configure::write('Session', array(
'defaults' => 'php',
'timeout' => 4320, //minutes
'cookieTimeout' => 1440, // The session cookie will live for at most 24 hours, this does not effect session timeouts
'checkAgent' => false,
'autoRegenerate' => true, // causes the session expiration time to reset on each page load
'ini' => array(
'session.gc_maxlifetime' => 259200 // 3 day seconds
)
));
I make some tests on local server and in production server and I see some differences:
Local development environment (PC)
1 hour: successfull (session not closed)
2 hour: successfull (session not closed)
4 hour: succesfull (session not closed)
Production server
1 hour: successfull (session not closed)
2 hour: Not successfull (session closed)
I need to be able to have big timeouts (4 hours minimum) on the production server, why I have this differences between the local PC and the server?
This is because your web host has different PHP configuration. You can check using phpinfo() about the Session expire time.
You can set it using PHP ini
we're using DynamoDB in order to synchronize sessions between more than one EC2 machine under ELBs.
We noticed that this method slow down a lot the scripts.
Specifically, I made a js that calls 10 times 3 different php scripts on the server.
1) The first one is just an echo timestamp(); and takes about 50ms as roundtrip time.
2) The second one is a php script that connect through mysqli to the RDS MySQL and takes the same time (about 50-60ms).
3) The third script use the DynamoDB session keeping method described in official AWS documentation and takes about 150ms (3 times slower!!).
I'm cleaning the garbage every night (as documentation say) and the DynamoDB metrics seems OK (attached below).
The code I use is this:
use Aws\DynamoDb\DynamoDbClient;
use Aws\DynamoDb\Session\SessionHandler;
ini_set("session.entropy_file", "/dev/urandom");
ini_set("session.entropy_length", "512");
ini_set('session.gc_probability', 0);
require 'aws.phar';
$dynamoDb = DynamoDbClient::factory(array(
'key' => 'XXXXXX',
'secret' => 'YYYYYY',
'region' => 'eu-west-1'
));
$sessionHandler = SessionHandler::factory(array(
'dynamodb_client' => $dynamoDb,
'table_name' => 'sessions',
'session_lifetime' => 259200,
'consistent_read' => true,
'locking_strategy' => null,
'automatic_gc' => 0,
'gc_batch_size' => 25,
'max_lock_wait_time' => 15,
'min_lock_retry_microtime' => 5000,
'max_lock_retry_microtime' => 50000,
));
$sessionHandler->register();
session_start();
Am I doing something wrong, or is it normal all that time to retrieve the session?
Thanks.
Copying correspondence from an AWS engineer in AWS forums: https://forums.aws.amazon.com/thread.jspa?messageID=597493
Here a couple things to check:
Are you running your application on EC2 in the same region as your DynamoDB table?
Have you enabled OPcode caching to ensure that the classes used by the SDK do not need to be loaded from disk and parsed each time your
script is run?
Using a web server like Apache and connecting to a DynamoDB session
will require a new SSL connection to be established on each request.
This is because PHP doesn't (currently) allow you to reuse cURL
connection handles between requests. Some database drivers do allow
for a persistent connections between requests, which could account for
the performance difference.
If you follow up on the AWS forums thread, an AWS engineer should be able to help you with your issue. This thread is also monitored if you want to keep it open.
I am a newbie to php and cakephp, recently I was assigned a job to implement memcache in my app so that its performance can be increased. Can anyone suggest some documentation on this topic for me?
Thanks.
This might be a bit late ... but the Cake core has support for Memcached built in (at least in the latest versions, 2.0.x and 2.1).
Have a look at Config/core.php in your app, and you should see these lines (commented):
Cache::config('default', array(
'engine' => 'Memcache', //[required]
'duration' => 3600, //[optional]
'probability' => 100, //[optional]
'prefix' => Inflector::slug(APP_DIR) . '_', //[optional] prefix every cache file with this string
'servers' => array(
'127.0.0.1:11211' // localhost, default port 11211
), //[optional]
'persistent' => true, // [optional] set this to false for non-persistent connections
'compress' => false, // [optional] compress data in Memcache (slower, but uses less memory)
));
You can uncomment these lines and test it out with a Memcached install. Make sure you have Memcached installed somewhere (localhost or elsewhere) and you are pointing to it.
Memcache is one of the supported Cache engines by the built-in Cache class. The Cache class is a wrapper for interacting with your Cache and you can read everything about it here: http://book.cakephp.org/2.0/en/core-libraries/caching.html
Warlock
Here is a more specific implementation of Memcache and Cakephp that may help with your bottle necks
Send your database on vacation by using CakePHP + Memcached
http://nuts-and-bolts-of-cakephp.com/2009/06/17/send-your-database-on-vacation-by-using-cakephp-memcached/
This is really bugging me. Has been for years. No matter what I do with core.php or php.ini, my logins timeout after about an hour - usually. Some deployments of identical code and configuration timeout after a respectable amount of time.
This is what I have at the moment on one site - timed out after about an hour:
session.gc_divisor 1000
session.gc_maxlifetime 86400
session.gc_probability 1
Configure::write('Session.timeout', '28800');
Configure::write('Session.checkAgent', false);
Configure::write('Security.level', 'medium');
And another - lasted all night:
session.gc_divisor 100
session.gc_maxlifetime 14400
session.gc_probability 0
Configure::write('Session.timeout', '315360000');
Configure::write('Session.checkAgent', false);
Configure::write('Security.level', 'medium');
Now, before you get excited and say, "Well, the answer is there in the Session.timeout value", let me tell you that this site usually times out after about twenty minutes!
Somewhere I read that on shared hosting, other applications can reset the session by clearing the php-defined session directory. This was alluded to by Rowlf in his answer.
CakePHP offers the option to configure the way sessions are handled. In core.php I changed this to 'cake' (by default it is 'php'):
/**
* The preferred session handling method. Valid values:
*
* 'php' Uses settings defined in your php.ini.
* 'cake' Saves session files in CakePHP's /tmp directory.
* 'database' Uses CakePHP's database sessions.
*/
Configure::write('Session.save', 'cake');
I also ensured that the session timeout and the corresponding php.ini values are the same:
/**
* Session time out time (in seconds).
* Actual value depends on 'Security.level' setting.
*/
Configure::write('Session.timeout', '86400');
So far, the system hasn't logged out.
I don't think this is a Cake-specific thing; I've seen it when no frameworks were involved - it's most likely an issue with your PHP config settings.
Things you should check/do to fix the issue:
Specify a dedicated path to store
sessions in session.save_path if you don't already do so.
Don't store them in /tmp - some other process may come along and wipe them
for you.
Make sure (and I mean really sure) that the value of session.gc_maxlifetime is what you think it is (86400 if you want your logins to time out after 24 hrs of inactivity, etc.). Same with session.gc_divisor and session.gc_probability. Even though the PHP Manual specifies that session settings can be set on any level, depending on the dodginess of your PHP build (they're all slightly buggy in their subtle ways :)) you may find they don't actually take effect unless set in the global php.ini file as opposed to in the code, .htaccess, etc. Just output them in your actual app to be sure they are applied.
Also, depending on your environment, check if the PHP CLI build is using the same php.ini file as the default PHP build - if the CLI build is using another config file and you have cron jobs using the CLI build, the cron job scripts could be invoking the session cleanup procedure.
If you have many CakePHP apps on the same server, this can be the cause of you troubles. Don't forget to :
Prefix each app differently ($prefix on core.php).
Change the name of each cookie path :
Configure::write('Session', array(
'defaults' => 'php',
'timeout' => 4320,
'ini' => array(
'session.cookie_path' => '/name_app', // this for each app
)));