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
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.
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:
logoutAction.jsp. The JSP pages
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
logoutAction.jsp act as the controllers and contain code that carries out the login and logout actions, respectively.
|Forum migration complete By Athen|
|Forum migration update By Athen|
Solving the logout problem By JavaWorld
( 1 2 3 all )
|Sorting data from a data base on to a servlet By|
|A "follow-up" solution By Kevin Hoang Le|
|Article By Madhusudhan|
|how to check the user? By|
|I think there is a mistake in the text...! By Baldo|
|Prevent Spoofing of the time By Anonymous|
|Remove the sexist language!!!!! By Anonymous|
|Great Article By Paro|
|need more clarification By Anonymous|