Question

I set up a test version of a PHP coded website which uses sessions to handle user logins. On the test server, the session would expire on browser close, since copying everything to the “clean” live server, the session stays in place on browser close and the user is still logged in even the next day after full system reboot.

In php.ini

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
; http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
session.cookie_lifetime = 0

Which implies that it should expire on browser restart.

I thought maybe it was being overridden somewhere, but if I print_r the session_get_cookie_params in PHP I get

Array
(
    [lifetime] => 0
    [path] => /
    [domain] => 
    [secure] => 
    [httponly] => 
)

Is there something I am missing?

Answer 1

I was going to add this as a comment on Alexander’s excellent answer, but its going to get a bit verbose.

How long the cookie is retained on the browser and how long the session data is retained by the server in the absence of a request are 2 seperate and independent things. There is no way to avoid this due to the stateless nature of HTTP – although there are some things you can do to mitigate what you perceive as a security flaw.

For the browser to access the same session after being closed down and some delay it requires that both the session cookie be retained by the browser (which Alexander has already explained) and for the server to have retained the session data.

The behaviour you describe may be much more pronounced on systems handling a low volume of requests and where the session handler does not verify the TTL of the sesion data (I’m not sure if the default handlers do, or if they just assume that any undeleted session data is considered current).

You’ve not provided any details of how the 2 servers are configured, notably the session.gc_maxlifetime.

If the session.gc_maxlifetime has expired between requests but the session data is still accessible this implies that the session handler merely considers this as the time at which the session is considered eligible for garbage collection (which, semantically, is what the configuration option is for). However there is a strong case for treating this value as a TTL. To address this you could either force the garbage collection to run more frequently and delete the session data, or use a session handler which ignores session data older than the specified limit.

That you see a difference between the 2 systems may be due to differing values for session.gc_maxlifetime or differences in the frequency of garbage collection or even different session handlers.