I have a web application where web session need to expire after stipulated period of time. However capturing browser closure event is not a good idea to invalidate a user session.

What can be an alternative solution to invalidate a user session on browser closure ?

2 Answers 2


Session (in)validation is usually a server concept: a session is "valid" as long as the server considers it to be valid, i.e. grants access to whatever data and functionalities are defined to be session-based.

What is usually done is:

  • The server has a session timeout. If nothing is heard from the client for some time, then the session disappears.
  • An explicit "logout" button is provided, when users want to trigger an early session end.

From your question, I suppose that you would like the browser "closure" to act like a logout button. If you can capture a closure event, then that's good. Otherwise, you can use a short timeout (e.g. two minutes) and have some Javascript running in the background of the page to do some regular hidden "keep-alive" activity with the server (e.g. every 90 seconds) as long as the corresponding tab/window is open.

Either way, it is up to the server to enforce a timeout. You cannot reliably handle it client-side only, if only because the client can disappear abruptly without any trace (user's laptop battery is empty, user is roaming in a car/train and goes out of range of a station, user's machine or browser crashes, user is evil and kills his browser just to annoy you... possibilities are endless).

  • What if we don't keep the session at the server side? For example, imagine the session is an encrypted value that includes a secret, and when the server receives the session, de-crypts it, and accepts the session only if the value matches a secret? How can we improve the log out or closing the browser to invalidate the session?
    – Goli E
    Commented Jul 7, 2015 at 19:30

If you do not set an expiration time for the session-cookie, the browser will delete it whenever the browser is closed.

Set-Cookie: SessionId=1ogf87b04oajp1lvkrid2iciskd2acug; path=/; HttpOnly

This leaves you with the question of expiring the session.

This should be done by server-side check: On each (valid) request, store the request time in/for this session. Whenever a subsequent request is made, check the current time against the previous request time. If the last activity was more than X minutes ago, consider the session expired and explicitly expire the session cookie by setting an expiration time far back. Setting a cookie expiration time far back in the past (1971-01-01 for example) will tell the client it can garbage collect the session cookie, while still making sure you do the actual expiring on the server side.

Set-Cookie: SessionId=false; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

You should not rely on any client scripting or the like, it is not needed for session management (and cannot be implemented reliable anyhow).

Edited to add:
Some frameworks have a good session implementation, while most do an OK-ish job. However, some (I'm looking at you Zend Framework) are downright wrong. Try to make sure you understand what cookies are send out and do not confuse the session cookie with, for example, a 'remember me' cookie.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .