JSP and struts to resolve user exit issues

In a password-protected Web application, it is not just a matter of calling the HttpSession invalidate () method to properly handle the user exit process. Now most browsers have back and forward buttons that allow the user to step back or forward to a page. If the user presses the Back button browser to present the cached page to the user after exiting a Web application, this can cause confusion to the user, who will begin to worry about the safety of their personal data. Many Web applications force users to shut down the entire browser when they exit, so users cannot click the Back button. Others use JavaScript, but in some client browsers this does not necessarily work. These solutions are clumsy and are not guaranteed to be 100% effective in either case, and it also requires a certain amount of operational experience from the user.

This article illustrates the correct solution to the user exit problem. The author, Kevin Le, first describes a password-protected Web application, and then illustrates how the problem arises and discusses the solution to the problem. Although the article is for JSP page elaboration, but the concept elaborated by the author is easy to understand to be able to use for other web technology. Finally, the author shows how to use Jakarta struts to solve this problem gracefully.

Most Web applications do not contain information as confidential as bank accounts or credit card information, but once sensitive data is involved, we need to provide a type of password protection mechanism. For example, a factory worker accesses their schedules through the web, enters their training courses, and looks at their salaries and so on. It's a bit overkill to apply SSL (Secure Socket Layer) at this point, but it's undeniable that we have to provide password protection for these applications, otherwise workers (that is, users of Web applications) can spy on private confidential information from other employees in the factory.

Similar to the above situation, there is a library, hospitals and other public places of the computer. In these places, many users use several computers together, and it is important to protect the user's personal data at this time. Good design and excellent application of the user's expertise requires very little.

Let's take a look at how a perfect Web application in the real world behaves: a user accesses a page through a browser. Web applications show a landing page that requires users to enter valid authentication information. User entered user name and password. At this point we assume that the authentication information provided by the user is correct and that, through the validation process, the Web application allows the user to browse the area he has access to. When the user wants to exit, click the Exit button, the Web application asks the user to confirm whether he really needs to exit, if the user determines to exit, session ends, the Web application is relocated to the landing page. Users can safely leave without worrying that his information will be compromised. When another user sits in front of the same computer, he clicks the Back button and the Web application should not appear on any page that the previous user visited. In fact, a Web application should stay on the landing page until the second user provides the correct authentication information.

Through the sample program, the article explains how to implement this functionality in a Web application.

JSP Example

To more effectively illustrate the implementation scenario, this article starts with a problem that is presented in the logoutSampleJSP1 of an example application. This example represents a number of Web applications that do not correctly resolve the exit process. LogoutSampleJSP1 contains the following JSP pages: login.jsp, home.jsp, secure1.jsp, secure2.jsp, logout.jsp, loginaction.jsp, and Logoutaction.jsp. The pages home.jsp, secure1.jsp, secure2.jsp, and logout.jsp are not allowed to be accessed by unauthenticated users, that is, they contain important information that should not appear in the browser until the user logs in or exits. Login.jsp contains a form for users to enter user names and passwords. The logout.jsp page contains a form that requires the user to confirm whether or not to exit. The loginaction.jsp and logoutaction.jsp are included as controllers for login and exit codes respectively.

The second example application logoutSampleJSP2 shows how to troubleshoot problems in the example logoutSampleJSP1. However, the second application itself is questionable. In certain cases, the exit problem will still occur.

The third example applies logoutSampleJSP3 to the second example, which solves the exit problem more perfectly.

The last example logoutsamplestruts shows how struts resolves the landing problem gracefully.

Note: The example attached here is tested in the latest version of Microsoft Internet Explorer (IE), Netscape Navigator, Mozilla, Firefox, and avant browsers.

Login Action

Brian Pontarelli's classic article "Java EE Security:container versus Custom" discusses different ways of Java EE certification. The article also points out that HTTP protocol and form based authentication do not provide a mechanism to handle user exit. Therefore, the solution is to introduce a custom security implementation mechanism.

A common approach to customizing the security authentication mechanism is to obtain authentication information entered by the user from the form and then authenticate to the security domain such as LDAP (Lightweight Directory Access Protocol) or the relational database. If the user provides authentication information that is valid, the login action injects an object into the HttpSession object. HttpSession there is an injected object that indicates that the user has logged in. To facilitate the reader's understanding, the example attached to this article only writes a username to HttpSession to indicate that the user has logged in. Listing 1 is a section of the code excerpt from the Loginaction.jsp page to illustrate the login action:

Listing 1
//...
Initialize RequestDispatcher object; Set forward to home page by default
RequestDispatcher rd = Request.getrequestdispatcher ("home.jsp");
Prepare Connection and statement
rs = stmt.executequery ("Select password from USER where userName = '" + userName + "");
if (Rs.next ()) {
Query only returns 1 record in the result set; Only 1
Password per UserName which is also the primary key
if (rs.getstring ("password"). Equals (password)) {//if valid password
Session.setattribute ("User", userName); Saves username string in the Session object
}
else {//password does not match, i.e., invalid user Password
Request.setattribute ("Error", "Invalid password.");
RD = Request.getrequestdispatcher ("login.jsp");
}
//no record in the result set, i.e., invalid username
else {
Request.setattribute ("Error", "Invalid user name.");
RD = Request.getrequestdispatcher ("login.jsp");
}
}
As a controller, loginaction.jsp finally either forwards to "login.jsp" or "home.jsp"
Rd.forward (request, response);
//...

The examples that are attached to this article use a relational database as a security domain, but the views elaborated in this article apply to any type of security domain.

Logout Action

The exit action contains a simple delete user name and a invalidate () method to invoke the user's HttpSession object. Listing 2 is an excerpt from the loginoutaction.jsp page to illustrate the exit action:

Listing 2
//...
session.removeAttribute("User");
session.invalidate();
//...