[RESOLVED] sessions expiring too early on shared server - fix?

jennyp

Sessions are expiring too soon in my PHP login, running on a shared server. The server default is 24 minutes, but at times sessions are expiring before that.

I say "at times" because the expiry time seems to vary with the time of day (?)

I get the impression that this may be due to other sessions "interfering" with mine on the shared server, and that I can overcome this by specifying a new path for session storage on every page.

Is this right, and if so, how do I do this?

Can I set this up using an htacess file?

Can I write the:
$session_timeout and the session.gc_maxlifetime there as well? If so, how?

I saw an ominous note somewhere, related to this, saying, "...But the .htaccess from your original site might also include directives which cause JPI failure...." What's that about?

Should the new directory be outside the public access www level? Does that enhance security?

Also, I saw a comment that, "If you are using the subdirectory option for storing session files then garbage collection does not happen automatically. *You will need to do your own garbage collection through a shell script, cron entry, or some other method." I'm not quite sure what the "subdirectory option" is, but is this necessary, and if so, what would be the cron job code for this?

I'd be hugely grateful for some expertise here.

bradgrafelman

jennyp wrote:
Can I set this up using an htacess file?

That depends on your host and how PHP is setup. If your host is using the Apache webserver and PHP was installed as an ISAPI module (not a CGI binary), then yes, you can place PHP configurations inside a .htaccess file - it's similar to configuring global PHP values by placing them in your php.ini configuration file.

To check the two above conditions (Apache + PHP is an ISAPI module), do a phpinfo() and look at the first table of data; if the "Server API" is listed as "Apache 2.0 Handler" (or something similar), you should be good to go. For more information about what to add to a .htaccess file, see this manual page: [man]configuration.changes[/man].

jennyp wrote:
Should the new directory be outside the public access www level?

YES. There is absolutely no sensible reason you would need to make these private session files - needed only by PHP on your server - accessible by the rest of the world.

As for the subdirectory bit, I'm not exactly sure what that means, sorry.

jennyp

My server API is just described as "Apache".

Sessions aren't mentioned on that link! 😕

I've written some elementary things for .htaccess on the server before (password protection, error notices, etc), but I still don't know what code would specify the new server path for session storage to a directory outside the public www access (eg, ../my_sessions).

If the thing about writing a cron job for garbage collections is also necessary - I can set up cron jobs in my server's control panel, but how do I code the right garbage collections? Is it just a case of deleting outdated files every so often?

bradgrafelman

If it's listed as Apache, then you will probably be able to make configuration changes to PHP using a .htaccess file.

Did you visit the manual link I provided above about doing this? Basically, you just use php_value or php_flag (depending upon whether or not the PHP directive you're changing is a true/false boolean value or if it takes some other specified value) to alter a PHP directive. The link above has example usage, though you probably don't need the whole <IfModule ... > </IfModule> syntax - just put the php_flag or php_value lines in your .htaccess and see if a phpinfo() reflects the changes.

If it doesn't work, post the line(s) you added to your .htaccess file.

EDIT:

jennyp wrote:
Sessions aren't mentioned on that link!

Well, no, that single page can't list and give examples for every PHP directive that exists. Instead, it shows examples for the general case; you can lookup which directive does what on this manual page: [man]ini.list[/man].

Alternatively, each extension should have a "configuration" page in the manual which lists the PHP directives it uses. For sessions, this page can be located here: [man]session.configuration[/man].

jennyp

Well, I tried a slightly different method without using .htaccess, and it seems to work.

Every page that uses my login now calls this code:

ini_set("session.gc_maxlifetime","86400"); // 24 hours
ini_set("session.save_path", "/serverpath/local/home/me/storagedir/");

I got this from here

I set the directory permissions to 757.

I have another login system on the shared server, and I didn't want to set a directory for all websites' sessions.

It seems to work: after logging in, scanning the "storagedir" directory shows a file:

sess_[32-character-alpha-numeric-string]

So, is that OK?

I'm new to sessions (you can tell? :o ) , so I hope it's OK..

I presume that this directory will get stuffed with strings like this... how will I know which to delete in a cron job?

bradgrafelman

PHP's session handling includes a built-in "garbage collector". For more information about how often this garbage collector is executed, see this manual link and read about the three directives that define how the gc (garbabe collector) works.

bradgrafelman

Also note that you need to include the example code snippet you provided in every script in this application. Not only does this leave room for forgetfulness, but it also decreases portability/scalability/etc.; if you were to later decide that you want to change the path and/or max lifetime, you would have to look in every single PHP script.

This is why the .htaccess method would be preferable since it contains the same configuration information but in one central location. Example usage would be:

php_value session.gc_maxlifetime 86400
php_value session.save_path /path/to/dir/

jennyp

OK thanks I can see that that's two methods I can use.

I can see that the .htaccess would be preferable since it's "set it and forget it".

I understand that PHP has its own 'garbage collector'... but I did see some remarks somewhere about needing to write your own if you changed the session path by the method I used above (ie not .htaccess). I certainly don't see old session files being deleted (they appear to take on 0kb of space, but they're not deleted yet).

I guess if I use the .htaccess method I shouldn't have to worry about garbage collection, in that PHP will do it automatically - is that right?

The shared server I'm using has my different websites in the root public www level, like:
mydomain.com
myotherdomain.com
etc

If I used the .htaccess method, I guess I could just put an .htaccess file at this same level (ie, not a separate .htaccess file for each domain)?

Thanks for your help.

bradgrafelman

jennyp wrote:
I understand that PHP has its own 'garbage collector'... but I did see some remarks somewhere about needing to write your own if you changed the session path by the method I used above

From my understanding of it, the internal gc is still applicable even with a different save path. The only time the internal gc is bypassed is if you use the "N;path" format (e.g. "5;/tmp") for session.save_path.

Otherwise, the manual leads me to believe that the internal gc handler is called whenever you call session_start() - regardless of whether or not you've used ini_set/.htaccess to alter the save path (again, assuming you didn't do the "N;path" format). In fact, the manual even implies this almost explicitly in the following note under the session.gc_maxlifetime directive:

PHP Manual wrote:
Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

jennyp wrote:
I certainly don't see old session files being deleted (they appear to take on 0kb of space, but they're not deleted yet).

Well, that's definitely understandable; what are the values for session.gc_probability and session.gc_divisor? The default values, 1 and 100, imply that gc is actually done only 1% of the time, or that each session_start() call only has a 1% chance of causing gc to be performed.

jennyp wrote:
If I used the .htaccess method, I guess I could just put an .htaccess file at this same level (ie, not a separate .htaccess file for each domain)?

No, not exactly. This stems from the fact that PHP has no control over how a .htaccess file is handled. Your webserver, Apache, only begins looking for .htaccess files to exectuted at the root directory of the website it's handling a request for.

So, if you go to http://mydomain.com, Apache knows that for a host of "mydomain.com" it should look in "/user/jennyp/mydomain.com/html/" (example path) for the root of all requests. Thus, it is in this directory that the first .htaccess will be executed; in my example path above, a .htaccess file in "/user/jennyp/" would not be executed - it's above the root.

So to answer your question in short; no, you need a .htaccess file at the root of each domain (unless Apache is somehow configured differently for you).

jennyp

Hey thanks very much for your brilliant help 🙂