2

I'm using a java based uploading construct http://www.javaatwork.com/java-upload-applet/details.html that I tried running over night.

  1. It basically stores everything on the server's hard drive (/var/www/private/$userId)
  2. Makes sure that data is well-formed
  3. Then passes it onto a permanent storage (Amazon S3).

After step 1 completes, I run the following code:

if($_SESSION['userId'])
    {//Makes sure that data is well-formed} 
else
    {echo 'you are not logged in';}

I tried running this for four hours only to find you are not logged in printed to the screen.

Here are the appropriate directives in the cgi php.ini file (I'm using ubuntu 12.04 with apache2.)

session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 14400 //this is 30 hours, which is far greater than the 4 hours it was running
session.cache_expire = 1800
session.cookie_lifetime = 0

Most of these directives are the default with exception to session.gc_probability and session.gc_maxlifetime.

I was trying to resolve this issue and came across a really helpful blog by Jeff from which I inferred that browsers can cause the PHPSESSID cookie stored in the browser to be deleted if a period of inactivity on the website from within the browser occurs. He suggests

"Create a background JavaScript process in the browser that sends regular heartbeats to the server. Regenerate a new cookie with timed expiration, say, every 5 or 10 minutes." http://www.codinghorror.com/blog/2008/04/your-session-has-timed-out.html

So I decided to do just that.

function myTimeoutFunction()
{
    $.ajax({
        url: "heartbeat.php",                    
        success: function() {
        }
    });
    setTimeout(myTimeoutFunction, 15*60*1000);
}
myTimeoutFunction();

heartbeat.php <?php session_start(); ?>

I'm about to test this for an upload that should take ~4 hours. However I just read the following

In general you can say session.gc_maxlifetime specifies the maximum lifetime since the last change of your session data (not the last time session_start was called)

https://stackoverflow.com/a/1516338/784637

If I had 3 session variables, $_SESSION['userId'] $_SESSION['firstName'] $_SESSION['lastName'], would I need to reset all their values in heartbeat.php

session_start(); 
$_SESSION['userId'] = $_SESSION['userId'];
$_SESSION['firstName'] = $_SESSION['firstName'];
$_SESSION['lastName'] = $_SESSION['lastName'];

Or could I just reset one value

session_start(); 
$_SESSION['lastHeartbeat'] = time();

so that the other three would not expire?

Community
  • 1
  • 1
user784637
  • 15,392
  • 32
  • 93
  • 156

1 Answers1

4

The PHP session is kept as a whole; any changes in $_SESSION will update the change time and, by extensions, preserve the entire session.

Concerning the actual issue: PHP shouldn't GC sessions until the max time is reached, but that doesn't mean PHP is always clearing it. By default, sessions are kept in the /tmp (or another) directory and some Linux distros will have cron jobs that may clean the folder out from time to tome. Check for crons or other things that may clear the sessions independent of PHP too.

sirbrialliance
  • 3,612
  • 1
  • 25
  • 15
  • 2
    +1. I'll add that a good way to avoid session files being wiped by other processes, or other php scripts with different gc settings, is to save them to a secluded non web accessible directory by setting `session.save_path` – goat Jun 18 '12 at 05:57
  • @rambocoder - would merely setting a different path for the `session.save_path` directive prevent those "other processes"? How would I go about determining what those processes might be? – user784637 Jun 18 '12 at 06:08
  • 1
    Yes it will work. I don't know how to find the processes- I'm not much of a system admin, but I imagine you could set something up which logs which processes make calls to stat() or unlink() other os level calls that would be involved in the gc process. But, a likely culprit aside from a cron job that cleans the tmp folder, is other php script calling session_start() with different config, on the same shared webserver. – goat Jun 18 '12 at 06:43
  • max time since when? Session creation or last call of session_start()? – Tyson of the Northwest Oct 30 '12 at 19:13