JavaSercer Pages 10.2.6 Logging Out Since the proof of authentication is kept in the session scope, the user will be automatically logged out when the session times out. But even so, an application that requires authentication should always provide a way for the user to explicitly log out. This way a user can be sure that if he or she leaves the desk, no one else can come by and use the application. The main page in the example application contains a link to the logout page, shown in Example 10.7. Example 10.7. Logout Page (logout.jsp) <%@ page language="java" %> <%@ taglib uri="/orataglib" prefix="ora" %> <%- Terminate the session and redirect to the login page. --%> <% session.invalidate( ); %> This page explicitly terminates the session by calling the invalidate( ) method of the session object in a scriptlet, and then redirects back to the login page. All objects kept in the session are removed and the session is marked as invalid. The next time someone logs in, a new session is created. If you want to test the examples described in this chapter, you first must create at least one user with the application we developed in Chapter 9. To see how the automatic redirect to the originally requested page works, you can open two browser windows and log in from both. They both share the same session, so if you log out using one window and then try to load the “post a new message” page with the other, you will first be redirected to the login page. After you’ve entered your username and password, you’re redirected to the page for posting a message. 10.3 Other Security Concerns In this chapter we have discussed only authentication and access control, but there’s a lot more to web application security. You also need to ensure that no one listening on the network can read the data. In addition, you need to consider ways to verify that the data has not been modified. The common terms for these concepts (also used in the Servlet 2.2 specification) are confidentiality and data privacy for the first, and integrity checking for the second. On an intranet, users can usually be trusted not to use network listeners to get to data they shouldn’t see. But on the Internet, you can make no assumptions. If you provide access to sensitive data, you have to make sure it’s protected appropriately. Network security is a huge subject area, and clearly not within the scope of this java blog. Therefore I will touch on only the most common way to take care of both confidentiality and integrity checking: the Secure Socket Layer (SSL) protocol. SSL is a protocol based on public key cryptography: it relies on a public key and a private key pair. Messages sent by someone, or something (such as a server), are encoded using the private key, and can be decoded by the receiver only by using the corresponding public key. Besides confidentiality and integrity checking, public key cryptography also provides the means for very secure authentication: if a message can be decoded with a certain public key, you know it was encoded with the corresponding private key. The keys are issued, in the form of certificates together with user identity information, by a trusted organization such as VeriSign (http://www.verisign.com). Both the client and the server can have certificates. However, the most common scenario today is that only the server has a certificate, and can thereby positively identify itself to the client. The SSL protocol takes care of this server authentication during the handshaking phase of setting up the connection. If the server certificate doesn’t match the server’s hostname, the user is warned or the connection is refused. If the client also has a certificate, it can be used to authenticate the client to the server in a more secure fashion than basic and digest authentication. page 146
Note: If you are looking for good and affordable webspace to host and run your servlet application check Sandzak servlet hosting services
This entry was posted
on Friday, December 29th, 2006 at 1:41 am and is filed under Java.
You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.