Altering how long a session lasts

OniLink

Hi,

How would I go about altering how long a session lasts? Is it possible to make it so a session lasts as long as the user has their browser open?

Thanks for any help,
~Oni.

MarkR

Sessions should last as long as the browser is open by default - but some session handlers have a clean up routine (including the default one) which is occasionally called and deletes sessions which haven't been used for a while.

Setting session.gc_maxlifetime controls this clean up routine.

If the sessions files are manually deleted (e.g. during server reboot), the sessions will also be lost.

If you need more control, you have to write your own session handler (which is nontrivial)

Mark

OniLink

Thanks. Yeah, it seems to be the case where I leave the site (still having the browser open), then I go back and the session is ended.

What are the properties of session.gc_maxlifetime?

MarkR

Are you using cookies to maintain session state?
Are your URLs canonical?

You should definitely use cookies unless you have a really good reason not to. I recommend setting session.use_only_cookies to 1.

You should also canonicalise your URLs - www.example.com is not the same site as example.com and can't share its cookies normally. Therefore, you should make sure that one redirects to the other.

The session GC handler will only apply to sessions which have been idle for that long.

Read the session document for more info.

Mark

Piranha

MarkR wrote:
You should definitely use cookies unless you have a really good reason not to. I recommend setting session.use_only_cookies to 1.

Is that really a good idea Mark? It is after all possible to deny cookies, if someone do that then they might not be able to use the site at all. Of course using cookies should be default, but should access be denied to those that don't use cookies?

MarkR

Yes, using cookies is really a good idea. At least I think so. Whether you require them for the use of your application is a design decision however.

Maintaining sessions using a query string parameter is inherently unreliable and a major security risk if you use them for anything authentication/authorisation related, as session IDs easily "leak" via referrers and other mechanisms.

Moreover, session fixation attacks are much easier if you use query strings (or specifically, if you allow query strings to be used, which is why I advocate session.use_only_cookies)

Cookies are convenient and at least a bit more secure.

Of course there are other issues - for example, MSIE's privacy settings deny cookies under some circumstances. The application designer needs to decide whether this is acceptable.

Bear in mind that a great many popular web sites rely on cookies to function correctly, so someone denying cookies across the board already loses a lot of capability.

Mark

bradgrafelman

If you truly want to remain flexible, you could try setting a cookie when the user visits the first page of your site (i.e. a logon page). Then, test for that cookie on the next page. If you don't find it, make sure your script propogates the session ID via the URL. If you do find the cookie, woohoo! Use a cookie for the session ID, definitely.

MarkR wrote:
You should also canonicalise your URLs - www.example.com is not the same site as example.com and can't share its cookies normally. Therefore, you should make sure that one redirects to the other.

Or you could instead specify the session.cookie_domain directive to be ".example.com" so that the cookie will be applied to "www.example.com" and "example.com" and "any-subdomain-your-heart-desires.example.com" .