Research and Development

The previous post about session management was about how to improve the security of web sessions. An aspect which was not addressed in that post is how to identify that a session is not in active use any more but where the user has manually logged out. For example, a user who was using a banking application and closed the tab without logging out the application.

This point is also crucial for web applications because, computers and web browsers are frequently shared between people so it is important that this case cannot be exploited. Identifying when the user stops working with a web application and terminating the session reduces the window of opportunity that surrounds this type of attacks.

Although web applications should always include a “Log out” button, it is even naive to think that all the users are going to close their sessions when they finish to use a web application or before closing the tab/web browser where it was loaded.

Using JavaScript events

JavaScript allows to control an event which is fired at the moment of a browser window or a browser tab is closed. The name of this event is onbeforeunload. In fact, this event is fired before a page is unloaded, that includes: closing the tab, reloading the page, using the browser’s navigation buttons, click on a link…

The implementation of how the web browser acts when this event is launched depends on the web browser. In general, this event can be used to display a message box asking the user if he wants to close the current page. This message box contains two buttons to allow the user to choose between completing the action, closing the tab, or staying in the page.

So, in principle, it could be possible to detect when the user is closing the page and then send a request to the server with his confirmation. But the fact is that the majority of the web browsers do not return the control to the JavaScript interpreter before closing the tab; so it is not possible to send the request only in those cases that the user decides that he actually wants to close the tab (the event can always send a request before asking the user, but in few browsers will be able to do it after confirmation).

It was possible to check that Firefox returns the control to the JavaScript interpreter, but depending on the version, this only works when the page is reloaded, but not when a tab or the browser is closed (tested with versions 23 and 24). In the same way, Opera version 17 will send the logout request when the browser is closed, but not if the user closes is the tab. The rest of the tested browsers (Safari , IE and Chrome) did not send anything if the user confirmed the tab/browser closing.

The following code is an example about how to implement it:

<script src="">

// Not using JQuery
window.onbeforeunload = function () {
    return  "Are you sure want to LOGOUT the session ?";

// Used to logout the session , when browser window was closed
window.onunload = function () {
    $.get( "" );

// Using JQuery
$(window).on('beforeunload', function() {
        return 'Are you sure want to LOGOUT the session ?';

$(window).unload(function() {
        $.get( "" );

  <h1><i>Unload</i> and <i>Beforeunload</i> example</h1>
  Please, reload, close this tab or close the browser to launch the test.

So, as you would be able to note, this is not a suitable solution to the original problem outlined at the start of this post.

Using AJAX ping

A better approach, because it should work in any web browser, is to reduce the session timeout configuration in the server to few minutes (2-5 minutes) and to ping the server regularly (15-30 seconds) with an AJAX request. The ping request will maintain the sessions life on the web server, preventing it from being timed out unintentionally. On the other hand, if the user closes the tab or the browser, the session will be terminated by the web server after the determined period.

The code below is a possible implementation of an AJAX ping using jQuery:

$(function() { window.setInterval("$.post('');", 15000); });

This line should be included in every web page of the application, so it would be a good idea to create a file with it and include the file in the contents of every page served by the web serve.

With this solution, there are two problems:

  • The server will need to be able to support the load of the ping requests which, depending on the number of users, could be thousands each minute. But an application which had that number of users should be able to support that load, so this is not a real problem.
  • If the user leaves the application opened in a browser without supervision, the session will never time out.

The way to fix the second problem is to count the number of pings the server received without any other kind of request and to configure the application to close the session after the corresponding time (idle time). The time limit will need to be longer than the session timeout that has been configured, to avoid those cases of users who are using the application but staying in the same page for a while. For example:

Imagine that the session timeout was configured to 2 minutes and the delay between pings, 15 seconds. That means that after closing the browser, the session will remain live for 2 minutes maximum before being closed. That is a suitable period of time for the web server to wait before timing the session out because it will tolerate some network or connectivity problems which could in principal cause some of the pings to be lost (8 ping requests would have to be lost to close the session by mistake).

The major problem is the idle time, which will have to be configured depending on the kind of application. If the web application contains long articles, the idle time should be set to a longer period (5-10 minutes). If the application consists of small pages, then the idle time could be configured to the same as the session timeout (but never shorter).

By doing this, the application will cover:

  • If the tab or web browser is closed, the session will be terminated after session time out (2 minutes in the example).
  • If the users leaves the application unattended, the session will be closed after the idle time (at least as long as the session time out but no more than 10 minutes).
  • While the user is working with the application, the session will be remain active.

A last improvement would be to use a variable time out. So it could be configured to the same period as the session time out in most cases but could also be increased for those pages which will take longer to read.

Editor’s note: If you enjoyed our two articles on how to improve session management, we’ve asked the author to put together a good practice guide detailing these and other practical steps that can be employed to help keep your users safe.

Request to be added to the Portcullis Labs newsletter

We will email you whenever a new tool, or post is added to the site.

Your Name (required)

Your Email (required)