Problem:
"I am using sessions to manage authentication. I have noticed that the session automatically expires after about half an hour of sitting idle. I'd like to increase this time, but I am not sure how. Any sugestions?" - Anonymous
Solution by Coopster:
All of the session configuration options except session.use_trans_sid are of constant value PHP_INI_ALL, which means the entry can be set anywhere.
However! Be aware that things get funky if you are on a shared server and you use the default session directory! If you change garbage collection directives, they don't "stick" unless you are specifying your own *session directory*. I've tried to find some definitive documentation on this to no avail. The best I have come up with is my own conclusions. A friend of mine had the same issue once where the session times out well before it should and it prompted me to dig in a bit more. I cannot say that I have found the definitive answer, but my testing has proved the following scenario to be my best understanding of *how it works*
It seems we need to change the session.save_path directive for each virtual host to use their own directory other than the system and/or PHP default (/tmp) in order to effectively override each virtual host session.gc_maxlifetime directive.
Let me offer an example for clarification.
Example:
I've spent some time looking for a definitive guide to the internal workings of the PHP session.gc_maxlifetime directive, particulary it's impact/effect on servers with virtual hosting (shared servers). I have yet to find a definitive answer, however my testing has proved this theory to be correct.
Ultimately, I think you are better off managing sessions via your own handlers and a database on a shared server, but changing the session directory can be a close second.
However! Be aware that things get funky if you are on a shared server and you use the default session directory! If you change garbage collection directives, they don't "stick" unless you are specifying your own *session directory*. I've tried to find some definitive documentation on this to no avail. The best I have come up with is my own conclusions. A friend of mine had the same issue once where the session times out well before it should and it prompted me to dig in a bit more. I cannot say that I have found the definitive answer, but my testing has proved the following scenario to be my best understanding of *how it works*
It seems we need to change the session.save_path directive for each virtual host to use their own directory other than the system and/or PHP default (/tmp) in order to effectively override each virtual host session.gc_maxlifetime directive.
Let me offer an example for clarification.
Example:
A shared hosting provider has 10 domains running on an Apache server with PHP. www.shared_host1.com wants to set his session.gc_maxlifetime to 60 minutes. To do so, he must either use ini_set() or a PER_DIRECTORY override file (.htaccess) to change the default directive setting of 1440 (24 minutes) to 3600.
www.shared_host2.com wants to use sessions as well, but decides that a ten hour setting would be ideal, so www.shared_host2.com alters the directive in the same manner, setting the value to 36000.
We know that ini_set() is going to keep this new value during the script's execution, and will be restored at the script's ending, and a .htaccess file would work the same way. We also know (by opening and viewing the contents of a session file in the /tmp directory) that there is nothing in the file itself that designates when it will expire, PHP merely looks at the file mtime (atime, if < PHP 4.2.3). What I mean by this is that PHP doesn't look at the mtime of the file and compare it with some internal value to figure out if it should be trashed. If both hosts sessions are being written and saved in the default directory (/tmp), then I am assuming the session directives of the current session request determine whether or not garbage collection is going to be run, and if it happens to be www.shared_host1.com, then any sessions older than 60 minutes will be trashed, including those from www.shared_host2.com.
Is this a correct statement? I believe so. And if so, if each shared host were to save their own session files in their own directory using session.save_path (/shared_host1/tmp, for example), would this be the ideal way to use the directives, IN COMBINATION, to get the desired effect on virtual hosted (shared) servers? Yes, I believe this to be true as well.
www.shared_host2.com wants to use sessions as well, but decides that a ten hour setting would be ideal, so www.shared_host2.com alters the directive in the same manner, setting the value to 36000.
We know that ini_set() is going to keep this new value during the script's execution, and will be restored at the script's ending, and a .htaccess file would work the same way. We also know (by opening and viewing the contents of a session file in the /tmp directory) that there is nothing in the file itself that designates when it will expire, PHP merely looks at the file mtime (atime, if < PHP 4.2.3). What I mean by this is that PHP doesn't look at the mtime of the file and compare it with some internal value to figure out if it should be trashed. If both hosts sessions are being written and saved in the default directory (/tmp), then I am assuming the session directives of the current session request determine whether or not garbage collection is going to be run, and if it happens to be www.shared_host1.com, then any sessions older than 60 minutes will be trashed, including those from www.shared_host2.com.
Is this a correct statement? I believe so. And if so, if each shared host were to save their own session files in their own directory using session.save_path (/shared_host1/tmp, for example), would this be the ideal way to use the directives, IN COMBINATION, to get the desired effect on virtual hosted (shared) servers? Yes, I believe this to be true as well.
I've spent some time looking for a definitive guide to the internal workings of the PHP session.gc_maxlifetime directive, particulary it's impact/effect on servers with virtual hosting (shared servers). I have yet to find a definitive answer, however my testing has proved this theory to be correct.
Ultimately, I think you are better off managing sessions via your own handlers and a database on a shared server, but changing the session directory can be a close second.
In my Case, I chose to handle things by changing the session directory for the reason that the PHP application was already built and running for about 3 years by now. And the quick expiration of PHP Sessions just discovered recently.
First i created a Directory with 0757 permission and named it "_tmp". Created an .htaccess file with nothing but the following code in it. Note that gc_maxlifetime accepts time in seconds.
php_value session.gc_maxlifetime 60
php_value session.save_path "/home/rrsilo/public_html/_tmp"
php_value session.save_path "/home/rrsilo/public_html/_tmp"
Related posts:
- Convert text URLs or Hyperlinks to clickable links
- How to get Visitor's IP Address using PHP
- How to test or check if MOD_REWRITE is enabled
1 comments :
Thank you - this has helped me understand the issue we have with timeouts on our hosted system.
I have now set the following in our /html .htaccess file
php_value session.gc_maxlifetime 7200
php_value session.save_path "/home/bentra/bentra.co.nz/html/_tmp"
Now when I run /info I see these are my local settings, but even though people are on, I am not seeing any entries in the _tmp directory. Does this mean I have the path incorrect and it is still saving to the default?
Post a Comment
Hi there! Please leave your message here. Also, I may not be able to respond to your query right away. So please bear with me. Thanks. :)