session_cache_expire is the wrong function. It sets the lifetime of session pages stored on the client's computer (think "web page cache"). It only operates when session.cache_limiter is set to something other than its default of nocache and has NO VALUE for timing out a session. It's only value is for convenience when surfing a session-controlled web site. Generally (IMHO), you shouldn't be using it at all.
If you want sessions to expire, you need to do one or both (preferably both) of two things.
1) Limit the life of the session on the server.
You do this by setting the session.gc_maxlifetime variable. This variable sets the maximum life in seconds of a session file on the server. Note that the garbage collector (gc) doesn't start every time session_start() is executed, so a session file may remain on the server longer than its maxlifetime, but once the value is exceeded, the file will be permanently deleted, thus closing the session. You can control (mostly) how frequently the gc is executed, but I'll leave that as an exercise for the reader.
ini_set('session.gc_maxlifetime', 1800);
Sets the maximum session file life to 30 minutes (1800 seconds).
2) Limit the life of the session on the client.
You do this by setting the maximum life of the session cookie (if you're using cookies, which you should be, they're the most secure method).
session_set_cookie_params(1800, '/');
sets all session cookies to 30 minutes (1800 seconds).
NOTES
A) Garbage collection is a PHP event. This means two websites on the same server use the same garbage collector and, without control, the same directory for session files. This means when your neighbor executes the gc, your files can be affected. And if your maxlife is shorter than his, then you're deleting his files sooner than he wants. You can avoid this problem by putting the session files for your website (or any sub-portion of the site) into their own directory using session_save_path(PATH); Then, when you start the gc, it only affects your session files, and when your neighbor starts the gc, it only affects his. For improved security, PATH should not be a public directory (c.f. file and directory permissions for your computer.)
B) The '/' in the cookie variable identifies the directories on your website the session cookie can be used for. For most people, leaving it as '/' (all directories) is OK, but keep it in mind. It's a useful tool if there's a user section to your website and an admin section and they both use session cookies. The admin might want to use '/', but the user might want to use '/user', etc.
C) ALL of these commands/variables MUST be executed BEFORE session_start(); Thus:
-
define(SESSION_PATH, '/tmp/mydir');
-
define(COOKIE_DIR, '/');
-
define(COOKIE_MAXLIFE, '1800');
-
define(GC_MAXLIFE, '1800');
-
-
session_save_path(SESSION_PATH);
-
ini_set('session.gc_maxlifetime', GC_MAXLIFE);
-
session_set_cookie_params(COOKIE_MAXLIFE, COOKIE_PATH);
-
session_start();
-
D) Finally, be aware that there's no way to guarantee a session will close in EXACTLY any amount of time. Cookies can be spoofed, which is why you should also use the gc, but the gc might not execute for several minutes (or longer if your site isn't used very often) after the session file times out. No solution is perfect, and you can only approach perfection as the number of people who use your site increases, thereby increasing the frequency of gc operation.
Cheers.
4
