Securing Struts Applications - Using Cookies
(Page 7 of 8 )
A cookie consists of name-value data that can be sent to a client’s browser and then read back again at a later time. Persistent cookies are stored by the client’s browser. Cookies can be read only by the same server or domain that originated them. Also, a cookie can have an expiration period. Cookies are supported by most major browsers. However, cookies are often considered a privacy risk and can be disabled by the client. A good approach is to design your Web application to use cookies to improve the user experience, but not to require or force users to allow cookies.
For application-managed security, you can use cookies to allow users automatic logins. Specifically, you can create a persistent cookie that contains the user’s username and password. Then, when a user accesses the application, you can check for those cookie values. If present, the values can be used to log the user in without requiring them to fill out a login form. Using a servlet filter, or some JavaScript, you could log in a user automatically. Alternatively, you may want to just prepopulate the login form with the values from the cookie.
To illustrate the use of cookies, Mini HR will be changed to use them as follows:
- Once a user logs in, Mini HR creates persistent cookies containing the username and password.
- Mini HR uses the cookie support of the Struts tags to set the initial values for the login form.
For the login action, this means adding the following lines after the authentication check has been performed:
Cookie usernameCookie = new Cookie("MiniHRUsername", username);
usernameCookie.setMaxAge(60 * 60 * 24 * 30); // 30 day expiration
response.addCookie(usernameCookie);
Cookie passwordCookie = new Cookie("MiniHRPassword", password);
passwordCookie.setMaxAge(60 * 60 * 24 * 30); // 30 day expiration
response.addCookie(passwordCookie);
This code creates cookies for holding the username and password. Each cookie has an expiration of 30 days. Each cookie is then added to the response.
Next, use the Struts bean tags to retrieve the cookie values and write the values to the login form:
<logic:notPresent name="user" scope="session">
<bean:cookie id="uname" name="MiniHRUsername" value=""/>
<bean:cookie id="pword" name="MiniHRPassword" value=""/>
<hr width="100%" noshade="true">
<html:form action="/login">
Username: <html:text property="username"
value="<%=uname.getValue()%>"/><br/>
Password: <html:password property="password"
value="<%=pword.getValue()%>"/><br/>
<html:submit value="Login"/>
</html:form>
<html:errors/>
</logic:notPresent>
The cookie tags retrieve the cookie values from the request and store them in page scope variables. These variables are then used as the initial values for the login form fields. However, this example is too simplistic for production use. Generally, using cookies without input from the user is considered overly presumptuous. A good Web application lets the user specify whether they want their user data stored as a cookie. It is also reasonable to let the user specify the length of time before the cookie expires. This type of information is easily gathered and stored by an application. Typically, this information is collected at registration time and stored as part of the user’s profile.
In addition, the data sent in the cookies should be secured or encrypted. A simple encryption scheme, such as MD5 or a variant of the Secure Hash Algorithm (SHA), can be used to encrypt the cookie value when it is created. Since the server creates the cookie and is the only party to legitimately use the data, it can encrypt and decrypt the data using the algorithm of its own choosing. Alternatively, cookies can be configured to only be transmitted over HTTPS—thereby providing encryption/decryption at the transport level.
Integrating Struts with SSLWeb applications often need to allow certain operations to be performed under secure processing—that is, using HTTPS. Users have come to expect sensitive data such as their usernames, passwords, and credit card numbers to be transmitted over a secure channel. As was noted earlier, the use of HTTPS for specific URLs can be specified using a user data constraint within a security constraint in the web.xml file. This declarative mechanism can be used to restrict URLs to SSL (by specifying a transport guarantee of INTEGRAL or CONFIDENTIAL). However, this approach does not address all the issues when using SSL. As a container-managed service, the implementation and behavior with SSL can vary by container. If the service is not used carefully and with a full understanding of its nuances, it is easy to code an application that will only run in a specific container—even when using services that are defined via an industry-accepted specification.
Therefore, HTTPS typically is used only when passing sensitive data, and otherwise HTTP is used. This requires redirecting from nonsecure pages to secure pages and then back again. Performing this redirection requires changing the protocol scheme on a URL from http to https on each redirection. The biggest problem with needing to do this protocol switching is that absolute URLs must be hard-coded into JSP pages and Action classes. This quickly leads to deployment and maintenance problems that arise when server names are different between development, integration test, and production servers. Some techniques for overcoming this problem are described shortly.
More pragmatically, programming an application to use HTTPS has other, more mundane but nevertheless equally frustrating issues. A common one is that the https protocol of the URL must often be hard-coded into a page. In fact, generally if you create HTML links that reference HTTPS, you must specify a fully qualified absolute URL. This makes it difficult to develop an application that is easy to migrate between deployment servers. Also, because switching the protocol requires an HTTP redirect, request attributes for the current request cannot be propagated to the secure URL. Thankfully, there is an open-source solution for handling these types of problems.
Next: SSLEXT to the Rescue >>
More Java Articles
More By McGraw-Hill/Osborne
|
 This article is excerpted from chapter 19 of the book The Complete Reference: Struts, written by James Holmes (McGraw-Hill/Osborne, 2004; ISBN: 0072231319 ). Check it out at your favorite bookstore. Buy this book now.
|
|
