What is the norm for session login timesouts on remote hosts?? Plz help!

Paul_help_

Hi guys.

I was just curious.

Do hosting companies generally tend to have a login timeout limit for websites when a customer either forgets to log out (of there admin area) or if there is a lack of activity once they are logged in?

The reason I am asking this is because I have built a number of login/logout applications for different customers over the past year and I want to make sure there is some level of security in place if they forget to log themselves out.

Paul.

cluelessPHP

It really depends, if you look at something like Facebook it never times out but this forum does have session timeout coded in, so realistically you should build to the requirements of the client, however have you ever heard of Cross-Site Request Forgery (CSRF) by any chance?

NogDog

You can configure it at the application level, particularly easily if you have a config or other file that is always included first. Then you can set the session cookie timeout to whatever you want, as well as the session data lifetime.

http://php.net/manual/en/session.configuration.php

session.cookie_lifetime and session.gc_maxlifetime are the settings of interest.

dalecosp

It really depends on the site/application.

My banking site, for example, runs a JS timer, and if you don't do anything (mouseover, link click, scroll, etc.) within 10 minutes it logs you out and send the browser to the home page.

Contrast that with a growing number of e-commerce sites/apps, for example Newegg, Amazon, etc. They cookie you at login and don't give an option for session length; they actually keep your session open basically forever, but require a login for "sensitive" operations (personal settings, payment, account history, etc.). I recall reading about this a couple years ago ... I'll see if I can find a link.

Paul_help_

Thanks guys.

Is there any way of setting a session timeout through the $_SESSION superglobal?

If so, can you provide me with some illustration code?

NogDog

Paul help!;11062761 wrote:
Thanks guys.

Is there any way of setting a session timeout through the $_SESSION superglobal?

If so, can you provide me with some illustration code?

Nope. $_SESSION is not available (or at least not populated) until after the session_start() has been executed, and you need your session configuration options set before session_start() is called.

You can either set them in the web host config via the php.ini file, or on Apache, at the directory level via .htaccess. If you want to set in in the PHP code itself, then it has to be done before the call to session_start() (as referred to above), so you might want it in a general config file:

<?php
$session_time = 60 * 60; // 1 hour
ini_set(session.gc_maxlifetime, $session_time);
session_set_cookie_params($session_time, '/', '.example.com'); // replace with domain
if(!headers_sent()) {
    session_start();
}
else {
    throw new Exception('Cannnot start session, headers already sent');
}

Then make sure you require that config file in any file that requires session data (including login authentication).

Caveat emptor: untested code, so beware typos.

Paul_help_

Thanks NogDog.

Can I ask?

Does ini_set() target the php.ini file which is already situated on the host?

...... and in order to use: session_set_cookie_params() ..... does the code expect me to have set a cookie myself?

Paul.

NogDog

ini_set() overrides any system settings -- or for that matter anything else that has set that particular setting. (Note however that not all settings can be overridden by it, but in this case, these can.)

In normal usage, session_start() sends a cookie and looks for an incoming one (which would have the session ID). session_set_cookie_params() tells session_start() to use its session cookie parameters instead of whatever the defaults would be.

Paul_help_

Thanks NogDog.

When you say:

In normal usage, session_start() sends a cookie and looks for an incoming one

.... What do you mean by an incoming cookie??

Do you mean one that has already been set?

pbismad

As to 'automatically' logging someone out or making a hijacked session id no longer match any session data, DON'T rely on the underlying session garbage collection operation to do this. The session garbage collection has a random probability of running and on a server that has few page requests, the session data could persist for a long time, allowing a hijacked session id to remain usable to impersonate a user.

Next, to positively log someone out, you need to have an actual data value, stored in the database table holding user data, that gets set to a value that indicates logged in, that gets cleared to indicate the logged out state. You should not rely just on the existence or absence of a session to permit access. By having an actual value stored on the server, it will require someone to enter correct authentication credentials in order to become logged in, which will prevent a hijacked session id from allowing someone to impersonate a user that is in the logged out state.

Lastly, to 'automatically' log someone out, you need to record the date and time of the last page request of the visitor in a database table, then check on each request if the last request is farther in the past then a value you have picked. If it is, you clear the logged in value stored in the database table, which will result in the visitor, or someone using a hijacked session id, needing to provide correct authentication credentials in order to become logged in.

NogDog

Paul help!;11062769 wrote:
Thanks NogDog.

When you say:

.... What do you mean by an incoming cookie??

Do you mean one that has already been set?

Yes: I suggest doing some reading up on cookies in general and session cookies in particular. In very short form: the server sends a cookie with a session ID to the browser with any page that includes a session_start() (in PHP). The browser receives that cookie, does whatever magic it does to remember it, and then sends a copy back with any subsequent HTTP request to that server domain, including that session ID (as long as the cookie has not yet timed out). That's how the server-side script differentiates requests from different session users, (which can include those that have logged onto your site).

Paul_help_

NogDog.

Back to your illustration code.

Wouldn't the following be enough (on it's own) to set a session timeout limit:

$session_time = 60 * 60; // 1 hour
ini_set(session.gc_maxlifetime, $session_time);

Surely setting the 'session.gc_maxlifetime' directive to something else is all that is necessary?

NogDog

It gets a little messy/fuzzy, as the "gc" process only runs when someone causes session_start() to be executed, and then there's a random chance it will or will not run the "garbage cleanup", with that random probability being another session config option. Also, in my experience, it does not clean up the session data of the user who triggered the session_start(), so that can also mess things up a bit. So just in case, I suggest setting both -- it's just one more line of code, and if you put it somewhere in a config file that always gets called, you're good to go.