You should implement a session timeout of your own. Both options mentioned by others (session.gc_maxlifetime and session.cookie_lifetime) are not reliable. I'll explain the reasons for that.
First:
session.gc_maxlifetime
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up. Garbage collection occurs during session start.
But the garbage collector is only started with a probability of session.gc_probability divided by session.gc_divisor. And using the default values for those options (1 and 100 respectively), the chance is only at 1%.
Well, you could simply adjust these values so that the garbage collector is started more often. But when the garbage collector is started, it will check the validity for every registered session. And that is cost-intensive.
Furthermore, when using PHP's default session.save_handler files, the session data is stored in files in a path specified in session.save_path. With that session handler, the age of the session data is calculated on the file's last modification date and not the last access date:
Note: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other filesystem where atime tracking is not available. Since PHP 4.2.3 it has used mtime (modified date) instead of atime. So, you won't have problems with filesystems where atime tracking is not available.
So it additionally might occur that a session data file is deleted while the session itself is still considered as valid because the session data was not updated recently.
And second:
session.cookie_lifetime
session.cookie_lifetime specifies the lifetime of the cookie in seconds which is sent to the browser. […]
Yes, that's right. This only affects the cookie lifetime and the session itself may still be valid. But it's the server's task to invalidate a session, not the client. So this doesn't help anything. In fact, having session.cookie_lifetime set to 0
would make the session’s cookie a real session cookie that is only valid until the browser is closed.
Conclusion / best solution:
The best solution is to implement a session timeout of your own. Use a simple time stamp that denotes the time of the last activity (i.e. request) and update it with every request:
if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1800)) {
// last request was more than 30 minutes ago
session_unset(); // unset $_SESSION variable for the run-time
session_destroy(); // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp
Updating the session data with every request also changes the session file's modification date so that the session is not removed by the garbage collector prematurely.
You can also use an additional time stamp to regenerate the session ID periodically to avoid attacks on sessions like session fixation:
if (!isset($_SESSION['CREATED'])) {
$_SESSION['CREATED'] = time();
} else if (time() - $_SESSION['CREATED'] > 1800) {
// session started more than 30 minutes ago
session_regenerate_id(true); // change session ID for the current session and invalidate old session ID
$_SESSION['CREATED'] = time(); // update creation time
}
Notes:
session.gc_maxlifetime
should be at least equal to the lifetime of this custom expiration handler (1800 in this example);
- if you want to expire the session after 30 minutes of activity instead of after 30 minutes since start, you'll also need to use
setcookie
with an expire of time()+60*30
to keep the session cookie active.
Are you using Forms authentication?
Forms authentication uses it own value for timeout (30 min. by default). A forms authentication timeout will send the user to the login page with the session still active. This may look like the behavior your app gives when session times out making it easy to confuse one with the other.
<system.web>
<authentication mode="Forms">
<forms timeout="50"/>
</authentication>
<sessionState timeout="60" />
</system.web>
Setting the forms timeout to something less than the session timeout can give the user a window in which to log back in without losing any session data.
Best Answer
Decrease the timeout
The easiest and most non-intrusive way to test this is probably to just decrease the timeout to a fairly small number, such as 3 or 5 minutes. This way you can pause for a few minutes to simulate a longer pause without worrying about application restarts or special reset code having any affect on your test results.
You can modify the session state timeout in a few locations - globally (in the web.config located in the config folder for the applicable .NET framework version), or just for your application.
To modify the timeout just for your application, you can add the following to your application's web.config:
Alternatively, you can also modify this same setting for your application through an IIS configuration dialog (I believe you still need to have a web.config defined for your application though, otherwise Edit Configuration will be disabled).
To access this, right-click on your web application in IIS, and navigate to Properties | ASP.NET tab | Edit Configuration | State Management tab | Session timeout (minutes).
Note that you can also manipulate this setting through code - if this is already being done, than the setting in the web.config file will effectively be ignored and you will need to use another technique.
Call Session.Abandon()
A slightly more intrusive technique than setting a low timeout would be to call Session.Abandon(). Be sure to call this from a page separate from your application though, as the session isn't actually ended until all script commands on the current page are processed.
My understanding is that this would be a fairly clean way to test session timeouts without actually waiting for them.
Force an application restart
In a default configuration of session state, you can simulate a session timeout by blowing away the sessions entirely by causing the application to restart. This can be done several ways, a few of which are listed below:
When I mention "default configuration", I mean a web application that is configured to use "InProc" session state mode. There are others modes that can actually maintain session state even if the web application is restarted (StateServer, SQLServer, Custom).
Tamper with the state tracking mechanism
Assuming your web application isn't configured with a "cookie-less" mode (by default, cookies will be used), you could remove the cookie containing the session ID from the client browser.
However, my understanding is that this isn't really simulating a time-out, as the server will still be aware of the session, it just won't see anyone using it. The request without a session ID will simply be treated as an unseen request in need of a new session, which may or may not be what you want to test.