9

I have a requirement where a user is authenticated into a session and after 10 minutes of inactivity, the session times out. Once the session times out any further requests from the now expired session is redirected to a timed out page. I have researched in this regard and came to 2 different approaches.

Approach #1:

In web.xml I have the code mentioned below...

<session-config>
     <session-timeout>10</session-timeout>
</session-config>

Approach #2:

I have the code mentioned below inside the authenticated page...

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0); // Proxies.

request.getSession().setMaxInactiveInterval(600);

Now my questions are:

What is the difference between these two approaches? Which one is better or recommended?

And also when using approach #2, if the end user navigates away from the authenticated page but has not logged out, does the session still times out after 10 mins of inactivity?

Roman C
  • 49,761
  • 33
  • 66
  • 176
Sai
  • 1,889
  • 5
  • 18
  • 26

2 Answers2

9

Session timeout can be set on various levels:

  • In the application server there is usually default settings, that can be changed - it is a default for all applications, or for given application (depending on server config capabilities).
  • Then in the application descriptor - you can override it by using web.xml - it will be used for all sessions in the given application
  • Then in the application code - you can override it using session.setMaxInactiveInterval(), it will be overridden only for that session

As Roman wrote:

no matter how you set it, it is invalidated by the container when timeout expires.

You should rather avoid programmatic approach (last one), as it is easy to miss some session and it will get the default timeout, and you will have inconsistent behavior. Use web.xml if you want to ensure given timeout (business requirement) and don't want to rely on server capabilities.

Roman C
  • 49,761
  • 33
  • 66
  • 176
Gas
  • 17,601
  • 4
  • 46
  • 93
  • Thanks to both Roman and Gas for explaining the difference and also giving me a good idea as to which approach to use. I am still waiting on the complete business requirements to see if the timeout is going to be consistent throughout the app which will clarify exactly which approach to use. But thanks to you both nonetheless in explaining me the difference. Now since I cannot mark both answers as answers to my question, I am marking Gas' solution as accepted answer (no particular reason) and voting up Roman's answer. Thanks again – Sai Oct 03 '14 at 19:01
  • Note the advice to avoid setting the timeout programmatically does not apply when your organization's security has specified different timeout periods for different users (e.g. users with administrative or other elevated access having a shorter timeout than "regular users") – JackLThornton Apr 14 '20 at 14:18
7

The first approach is using a static constant in the configuration for all sessions. The second approach is dynamic where you can set the value using servlet API at runtime dynamically and affected only a session which method is called. Once the value is set the session is invalidated by the container regardless which approach is used. See what the doc says about HttpSession#setMaxInactiveInterval(int):

Specifies the time, in seconds, between client requests before the servlet container will invalidate this session.

An interval value of zero or less indicates that the session should never timeout.

The value in deployment descriptor web.xml is in “minutes”, but the setMaxInactiveInterval() method accepts the value in “seconds”.

Community
  • 1
  • 1
Roman C
  • 49,761
  • 33
  • 66
  • 176