sessions timeout

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I am on a shared server so I have no control over the settings.

Is there a way for me to set a "timeout" for sessions?

I am working on some scripts (logged in as a test user) and had been
away from it for a few hours. The tabs (this is Opera browser) were
closed, but not the browser.

When I went back to the page it still had me logged in.
Obviously the server session cookies are set to clear when the browser

Is there a way for me to have some control over this and set a time
limit so after a reasonable amount of time the session cookie clears?


Re: sessions timeout

Quoted text here. Click to load it

The server cannot tell when the browser closes.  Some browsers
delete some cookies when the browser closes, but you cannot depend
on this happening, and the user may have control over the behavior,
overriding what the cookie spec might say.

Some browsers are also rather lax about cookie expiration times.
They might check once a day (or perhaps once every browser version
upgrade) or when the browser closes, whichever is less often.  I
think browsers reliably keep the cookie *AT LEAST* as long as the
cookie expiration date/time (barring problems like the browser and
server clocks being very different) but they may keep it too long.

Quoted text here. Click to load it

I'm assuming your pages are already set up to use sessions (calling
session_start() ) and have a way to let the user log in.

When a user logs in successfully, set $_SESSION['timestamp'] to time().
If a user unsuccessfully tries to log in, you might want to unset

On every page where a user needs to be logged in to see the page,
do your normal login checks, and then check that
$_SESSION['timestamp'] is set and
    $_SESSION['timestamp'] + ($hour_limit*60*60) > time() .  

($hour_limit is the time limit.  It can be different for different
pages, but that is probably confusing and not particularly useful.)

If not, the session has expired, redirect the user to the login
page.  If so, show them the page.  If you wish to extend the allowed
time for the session (generally, I believe it makes much more sense
to set a time limit from the time of the *latest* hit, not the time
limit from the *first* hit, especially if your concern is the person
who walks away from the computer leaving the browser open), set
$_SESSION['timestamp'] to time() again (after the test for expiration).

There is nothing special about the variable $_SESSION['timestamp'].
Any variable in $_SESSION[] will do.  If you have several sections
of your web site that independently require a user to log in (perhaps
using different lists of valid users, and different login pages),
you might want to use a different timestamp variable for each

Unlike the "lazy session expiration" used by built-in PHP session
timeout parameters, this method will time out the session at the
correct time down to the second.  It does not depend on any code
being executed at the time of the expiration (and will work fine
if the web site is down at the time).  Note, however, that if the
built-in PHP session stuff (which uses parameters you often can't
change on hosted sites) times out the session earlier than you
want it, $_SESSION[] restarts empty, and you cannot *lengthen* the
time by this method, only shorten it.

Re: sessions timeout

Michael Joel, 2012-01-04 02:42:

Quoted text here. Click to load it

Maybe using ini_set() to modify session.cookie_lifetime - but i'm not
sure if this is possible.

Another way would be to manage this "manually" - e.g. using the current
time and the time of the last activity of the user:

1) When the session is created also store the current time as a session

2) If there is already a session compare the current time with the time
recorded in the session and then either destroy the session, if the time
span is too long OR update the time in the session.

Quoted text here. Click to load it

Sure - the cookie is still there as long as the browser is running.

Quoted text here. Click to load it

See above.

Arno Welzel

Re: sessions timeout

Arno Welzel wrote:
Quoted text here. Click to load it

Another way would be to not use sessions and use the raw cookie instead,
then you have complete control.

Every time a user with a valid login hits the site, you check his cookie
against one stored in a database for that user, make sure its less than
whatever minutes old, and immediately store the current time and issue a
new utterly random  cookie to the user.

Whether HE times them out in his browser or not is irrelevant. You ARE.

If the cookie is out of date at YOUR end, issue the 'you are not logged
in, bugger off or get with the program' message.

Once you HAVE a database of users its a lot easier NOT to use sessions
it seems to me.

What you want to remember about a user is put in the database. ALL he
has to carry around as a cookie hopefully proving he is who he is: a
short term passport.

Basically the code needs to do as a common FIRST THING in EVERY access

get the cookie name/value pair and search your database for a value that
matches it, and is less than X minutes since it was stored in the database.

If a match found, immediately generate a random cookie value, store in
on the database and reset the timestamp on that user to 'now'. I store
their IP address as well, Then use them with the new cookie and set a
global variable somewhere saying 'this user is OK and his ID is this'
and proceed to modify  your code to behave differently if he is valid etc.

If not present a login screen (or an invitation to visit one).

The login screen takes name/password, matches them to the database
values, and then sets the same global variable and issues the first
cookie, and puts it in the database,  on completion.

I am sure you can get sessions to behave in this way, but it seems to me
its a poor substitute for a database, if you have one.

Re: sessions timeout

The Natural Philosopher, 2012-01-04 11:51:

Quoted text here. Click to load it

Which means, nearly *every* access will result in a database access.

Quoted text here. Click to load it

For me it seems to be the opposite: A session can make things a lot
easier, since you don't have to handle hundrets or thousands of database
queries. Of course it makes sense to use a database to store user
accounts - but it should only be checked *once* at the time of login and
not at *every* request by the user.

I alread did an example for session timeout handling a while ago - well,
it also demonstrates using JavaScript to automatically tell the user
that the session timed out, but it also works without JavaScript:

See <

Arno Welzel

Re: sessions timeout

On 1/3/2012 8:42 PM, Michael Joel wrote:
Quoted text here. Click to load it

If your hosting company allows you to set PHP values in your .htaccess
file (most do, at least for some functions), the easiest would be to set
it in your .htaccess file.  Then you don't need to keep checking in all
of your code.  Something like:

php_value session.cookie_lifetime 3600
php_value session

Would set the value to 1 hour (3600 seconds).

And since you're using a different value than the system default, so you
would want to use your own session save path, i.e.

php_value session.save_path /my/session/save/path

Where the directory would be not be available to the web but would be in
your path, i.e. if your website root were:


(example being your root directory), you might want to place them in


And finally, to keep things cleaned up, you might want to set the
garbage collection lifetime to the same value as your cookie lifetime, i.e.

php_value session.gc_lifetime 3600

This will help keep things cleaned up.

One other note: if you can't set these in your .htaccess directory, you
might be able to set them in your own php.ini file in you root
directory, but this isn't as common.  If you do, ensure you set your
.htaccess file up to deny access to your own php.ini file.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Site Timeline