Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Solving the logout problem properly and elegantly

Solutions for JSP pages and Struts

  • Print
  • Feedback

Many Web applications do not contain overly confidential and personal information like bank account numbers or credit card data. But some do contain sensitive data that requires some sort of password protection scheme. For example, in a factory where workers must use a Web application for entering timesheet information, accessing their training courses, and reviewing their hourly rates, etc., employing SSL (Secure Socket Layer) would be overkill (SSL pages are not cached; the discussion of SSL is beyond the scope of this article). But certainly these applications do require some kind of password protection. Otherwise, workers (in this case, the application's users) would discover sensitive and confidential information about all factory employees.

Similar examples to the situation above include Internet-equipped computers in public libraries, hospitals, and Internet cafes. In these kinds of environments where users share a few common computers, protecting users' personal data is critical. At the same time, well-designed and well-implemented applications assume nothing about the users and require the least amount of training.

Let's see how a perfect Web application would behave in a perfect world: A user points her browser to a URL. The Web application displays a login page asking the user to enter a valid credential. She types in the userid and password. Assuming the supplied credential is correct, after the authentication process, the Web application allows the user to freely access her authorized areas. When it's time to quit, the user presses the page's Logout button. The Web application displays a page asking the user to confirm that she indeed wants to log out. Once she presses the OK button, the session ends, and the Web application presents another login page. The user can now walk away from the computer without worrying about other users accessing her personal data. Another user sits down at the same computer. He presses the Back button; the Web application must not show any of the pages from the last user's session. In fact, the Web application must always keep the login page intact until the second user supplies a valid credential—only then he can visit his authorized area.

Through sample programs, this article shows you how to achieve such behavior in a Web application.

JSP samples

To efficiently illustrate the solution, this article starts by showing the problems encountered in the Web application, logoutSampleJSP1. This sample application represents a wide range of Web applications that do not handle the logout process properly. logoutSampleJSP1 consists of the following JSP (JavaServer Pages) pages: login.jsp, home.jsp, secure1.jsp, secure2.jsp, logout.jsp, loginAction.jsp, and logoutAction.jsp. The JSP pages home.jsp, secure1.jsp, secure2.jsp, and logout.jsp are protected against unauthenticated users, i.e., they contain secure information and should never appear on the browsers either before the user logs in or after the user logs out. The page login.jsp contains a form where users type in their username and password. The page logout.jsp contains a form that asks users to confirm that they want to indeed log out. The JSP pages loginAction.jsp and logoutAction.jsp act as the controllers and contain code that carries out the login and logout actions, respectively.

  • Print
  • Feedback

Resources