Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

Servlet Sessions and Automatic Login: Standard Java EE Might Not Be Enough For You

  • submit to reddit
Java servlet session management works well for basic requirements, but has limits when it comes to advanced features:
  • There is no standard global view of all the sessions, since HttpSession.getSessionContext() has been deprecated. If you want access to all sessions, you have to set up your own registry.
  • You have relatively little control of when the session expires. For example, there is no standardized way of accessing the session cookie and extending its lifespan beyond browser restarts.
  • Any kind of server access keeps the session alive: Long-pull is still a common technique for sending events from the server to the client and prevents a session from being inactive.

These kinds of limitations become relevant when you need to implement automatic login. There, you have the following options:

  • Store user name and password in a cookie: This is inherently unsafe and should never be done.
  • Let the browser remember user name and password: Firefox does this, but only for forms the exist at page load time. It is thus very complicated to get to work for Ajax dialogs.
  • Keep the session around longer: One needs to control session timeout (after a given period of inactivity) and possibly cookie expiration (the session ID is normally removed once one quits the browser).

Simple solution, standard Java EE:

  • During login, ask for the period of time one should stay logged in (if there is no activity).
  • On the server, use HttpSession.setMaxInactiveInterval(). Beware: Some servlet containers seem to create a new session when this method is invoked.
  • Problems: (1) Long-polling is registered as usage. (2) You cannot extend session lifespan beyond the next browser termination (because the cookie with the session ID will be removed).

Comprehensive solution, manual session management:

  • Manage your sessions yourself. The client initially receives a session ID from the server and then sends it with each request to the server. The login security FAQ [1] has more details.
  • It would be interesting to integrate this kind of session management with Google Guice which currently supports servlet sessions via a dedicated scope.

Related topics:

From http://2ality.blogspot.com/2010/06/servlet-sessions-and-automatic-login.html

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Ibrahim Levent replied on Mon, 2010/06/21 - 12:05am

Another limitation is shared session support between applications(EAR). Some aplication servers support this for web applications(WAR) in one enterprise application(EAR) beyond Java EE standard. Even that was not enough for us. We needed shared sessions among EARs and we had to implement it ourselves. Why we need multiple EARs for one application(instead of multiple WARs) was restartability feature of EARs. We're using WebSphere and you can restart only EARs not WARs. EAR restartability is important when installing new versions of applications since it only bothers users of one module. Otherwise you have to restart application server for every version and that decreases server availability.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.