Storing Data in Hidden Form Variables

Given what you already know about JSP, servlets, and HTML forms, you already have the ability to keep track of data between requests. You can store user data in hidden form variables.

Although not the most elegant solution, many applications use form variables to store user data. The idea is that every time the user submits a form, the form contains some hidden variables that provide information about the user. These variables might be a login ID and password or the user's name. The big hassle with using form variables is that all your forms must preserve these hidden variables and continue to pass them around.

The best way to illustrate this technique is with an example. Listing 12.1 shows a login form that calls a JSP to handle the login.

Listing 12.1 Source Code for `Login.html`

<html>
<body bgcolor="#ffffff">
<H1>Login</H1>
Please log in

<form action="Login.jsp" method="POST">

<table>
<tr><td>User Name:<td><input type="text" name="username">
<tr><td>Password:<td><input type="password" name="password">
</table>
<p>
<input type="submit" value="Login!">
</form>
</body>
</html>

The goal of this example is to preserve the username across multiple pages. The Login.jsp page will have the username because it's passed as a form variable from Login.html. Listing 12.2 shows Login.jsp. Notice that it inserts the username as a hidden form variable.

Listing 12.2 Source Code for `Login.jsp`

<html>
<body bgcolor="#ffffff">

<%
// Get the login information.
    String userName = request.getParameter("username");
    String password = request.getParameter("password");

%>
Welcome, <%=userName%>!
<form action=" ColorServlet" method="POST">

<%-- Save the username in a hidden form variable. --%>
<input type="hidden" name="username" value="<%=userName%>">

<p>
Please enter your favorite color:
<select name="color">
    <option value="blue" SELECTED>Blue</option>
    <option value="red">Red</option>
    <option value="green">Green</option>
    <option value="yellow">Yellow</option>
    <option value="mauve">Mauve</option>
</select>
<p>
<input type="submit" value="Choose color!">
</form>
</body>
</html>

Figure 12.1 shows the output from Login.jsp.

Figure 12.1. A page can contain hidden form variables that the user can't see.

graphics/12fig01.gif

The third part of this example is a servlet that receives the hidden form variable along with the user's color choice. Listing 12.3 shows the servlet.

Listing 12.3 Source Code for `ColorServlet.java`

package examples;

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class ColorServlet extends HttpServlet
{
    public void doPost(HttpServletRequest request,
        HttpServletResponse response)
        throws IOException
    {
// Tell the Web server that the response is HTML.
        response.setContentType("text/html");

// Get the PrintWriter for writing out the response.
        PrintWriter out = response.getWriter();

// Fetch the username and color parameters.
        String userName = request.getParameter("username");
        String color = request.getParameter("color");

// Write the HTML back to the browser.
        out.println("<html>");
        out.println("<body bgcolor=\"#ffffff\">");
        out.println("Well, I see that "+userName+
            "'s favorite color is "+color+".");
        out.println("</body>");
        out.println("</html>");
    }
}

Trying Out These Examples

You'll need to create a deployment descriptor to try these examples out. If you need to review this topic, you learned how to do this in Hour 2, "JavaServer Pages Behind the Scenes."

Security Concerns with Hidden Variables

One of the reasons you don't see hidden variables used very often in commercial Web sites, especially e-commerce sites, is that they are inherently insecure. Suppose Login.jsp actually verified the username and password. You would then assume that the username passed to ColorServlet is valid. But there is nothing to stop someone from inserting a bogus username and even a bizarre color by passing it in the URL for the servlet. Figure 12.2 shows an example of how the system can be tricked by inserting a phony username and color into the URL.

Figure 12.2. A malicious user can send phony values for hidden form variables.

graphics/12fig02.gif

Changing a username is bad enough, but imagine what could happen if someone did this with a bank account or credit card number! Certainly this technique needs some work. You might get clever and choose a variable name that is far less obvious than username. Suppose, for example, that you changed the name of the hidden variable to xpq7564HHgk. Surely no one would guess the variable name! Unfortunately, all someone needs to do is ask the browser to display the source for the page, as shown in Figure 12.3.

Figure 12.3. Because a user can view the source to a page, you can't safely hide anything in the page.

graphics/12fig03.jpg

Another big concern with hidden form variables is that the user might accidentally bookmark the secure information. When you use an HTTP GET method (by setting method="get" in your <form> tag) to submit a form, the form variables all appear in the URL and will be part of a bookmark if the user bookmarks the page. Even hidden form variables show up in the URL.

Most of these concerns can be eliminated by using an HTTP POST instead of GET. You'll recall that a POST embeds variables in the body rather than in the URL. If you use hidden form variables, even storing a single value, make sure you use an HTTP POST to help secure your application.

The hidden form variable approach seems to work fairly well except for one thing: the hidden variable itself. First of all, putting the hidden variable in every form is a hassle. Second, it requires the application to use only forms for accessing server-side pages. This presents quite a few problems. For example, if you use a hyperlink, there are no form variables to pass. You must either rewrite your hyperlinks to include all of the information that is included in your form or find a better alternative. That alternative is the session object.

[ Team LiB ]