Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #4208 > unrolled thread

sessions timeout

Started byMichael Joel <no@please.com>
First post2012-01-03 20:42 -0500
Last post2012-01-04 06:54 -0500
Articles 6 — 5 participants

Back to article view | Back to comp.lang.php


Contents

  sessions timeout Michael Joel <no@please.com> - 2012-01-03 20:42 -0500
    Re: sessions timeout gordonb.bqidf@burditt.org (Gordon Burditt) - 2012-01-03 22:23 -0600
    Re: sessions timeout Arno Welzel <usenet@arnowelzel.de> - 2012-01-04 09:20 +0100
      Re: sessions timeout The Natural Philosopher <tnp@invalid.invalid> - 2012-01-04 10:51 +0000
        Re: sessions timeout Arno Welzel <usenet@arnowelzel.de> - 2012-01-08 20:17 +0100
    Re: sessions timeout Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-04 06:54 -0500

#4208 — sessions timeout

FromMichael Joel <no@please.com>
Date2012-01-03 20:42 -0500
Subjectsessions timeout
Message-ID<66b7g7lk434p6vk68429d8np5134jd52hd@4ax.com>
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
closes.

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?

Thanks
Mike

[toc] | [next] | [standalone]


#4209

Fromgordonb.bqidf@burditt.org (Gordon Burditt)
Date2012-01-03 22:23 -0600
Message-ID<NfydnbZ06v6hSZ7SnZ2dnUVZ_rudnZ2d@posted.internetamerica>
In reply to#4208
> 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
> closes.

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.

> 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?

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
$_SESSION['timestamp'].

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
section.

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.

[toc] | [prev] | [next] | [standalone]


#4214

FromArno Welzel <usenet@arnowelzel.de>
Date2012-01-04 09:20 +0100
Message-ID<4F040BE5.7000207@arnowelzel.de>
In reply to#4208
Michael Joel, 2012-01-04 02:42:

> 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?

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
variable.

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.

> 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.

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

> Obviously the server session cookies are set to clear when the browser
> closes.
> 
> 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?

See above.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]


#4216

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2012-01-04 10:51 +0000
Message-ID<je1avb$l8$1@news.albasani.net>
In reply to#4214
Arno Welzel wrote:
> Michael Joel, 2012-01-04 02:42:
> 
>> 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?
> 
> 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:
> 

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.

[toc] | [prev] | [next] | [standalone]


#4313

FromArno Welzel <usenet@arnowelzel.de>
Date2012-01-08 20:17 +0100
Message-ID<4F09EBE6.3060907@arnowelzel.de>
In reply to#4216
The Natural Philosopher, 2012-01-04 11:51:

[...]
> 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.

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

[...]
> 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.

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 <http://arnowelzel.de/samples/sessiondemo.php>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]


#4217

FromJerry Stuckle <jstucklex@attglobal.net>
Date2012-01-04 06:54 -0500
Message-ID<je1emn$nbq$1@dont-email.me>
In reply to#4208
On 1/3/2012 8:42 PM, Michael Joel wrote:
> 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
> closes.
>
> 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?
>
> Thanks
> Mike

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:

/var/www/example/html

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

/var/www/example/sessions

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.
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.php


csiph-web