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 assume that the username passed to ColorServlet is valid. There is nothing to stop someone from inserting their own username and even a bizarre color by passing it in the URL for the servlet. Figure 5.2 shows an example of how the system can be tricked. Notice that the phony username and color are embedded into the URL.

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

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 could 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 5.3.

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

Another big concern with hidden form variables is that the user might accidentally bookmark the secure information. When you submit a form using an HTTP GET method (setting method="get" in your <form> tag), 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. If you use hidden form variables, even storing a single value, make sure you use an HTTP POST to keep the hidden information from being bookmarked.

Now, suppose you decide to store information on the server instead of trying to save all the data in hidden form variables. When a request comes in from a browser, how will you know what information goes with which client browser? To solve this problem, the browser must identify itself somehow.

You need to store one piece of data on the client: a key that uniquely identifies the browser and helps you remember where the user's data is stored. In other words, you get some data from the client, you store it in a hash table using some random key, and then send that key back to the browser in a hidden field. The next time the user fills out a form, the browser sends the server the hidden key field along with the other form variables. Your code on the server takes that key, looks in the hash table, and pulls out the user's data.

Storing data this way is much more secure than putting the data straight into hidden fields. Now if someone wants to break the system and tamper with the data, the best he can do is change the key. If the key value is large enough, it's unlikely that the hacker will be able to guess someone else's random key. He certainly won't be able to send you phony data, because the data stays on the server.

Listing 5.4 shows you a Java class that implements the key generation and data storage for keeping track of user data.

package usingjsp;

import java.util.*;

public class UserDataTable
{ 
    protected static Hashtable userData = new Hashtable();
    protected static Random keyGenerator = new Random();
/** Creates a new table for a user's data and returns the key for
 *  the user's data.
 */
    public static String createUserData()
    { 
// Create a random key for the user's data
        String userKey = ""+keyGenerator.nextLong();

// Create a hash table for the user's data and store it
        userData.put(userKey, new Hashtable());

        return userKey;
    } 

/** Returns the user data table for a particular user */
    public static Hashtable getUserData(String userKey)
    { 
        if (userKey == null) return null;
        return (Hashtable) userData.get(userKey);
    } 

/** Destroys the user data table for a particular user */
    public static void clearUserData(String userKey)
    { 
        if (userKey == null) return;
        userData.remove(userKey);
    }
}
						

To make use of this new UserDataTable class, you need to change the Login.jsp file to store the username in the user data table instead of a hidden frame. Listing 5.5 shows how Login.jsp can support this new storage method with very few changes.

<%@ page language="java" import="java.util.*,usingjsp.*" %>

<HTML>
<BODY bgcolor="#ffffff">

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

    String userKey = UserDataTable.createUserData();

    Hashtable userData = UserDataTable.getUserData(userKey);
    
    userData.put("username", userName);
%>
Welcome, <%=userName%>!
<FORM action="/servlet/usingjsp.ColorServlet2" method="POST">

<%-- Save the username in a hidden form variable --%>
<INPUT type="hidden" name="userkey" value="<%=userKey%>">

<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>
						

The main difference between Login.jsp and Login2.jsp is that Login2.jsp creates a user data table and stores the key for that table in a hidden field. Notice that Login2.jsp does not send the username back to the browser in a hidden field. All you need now is to modify the ColorServlet program to fetch the username from the user data table instead of from the hidden field. Listing 5.6 shows the modified ColorServlet that uses the user data table.

package usingjsp;


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

public class ColorServlet2 extends GenericServlet
{ 
    public void service(ServletRequest request,
        ServletResponse 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 user key and color parameters
        String userKey = request.getParameter("userkey");
        String color = request.getParameter("color");

        Hashtable userData = UserDataTable.getUserData(userKey);

// If the user data table isn't found, someone probably monkeyed with
// the key value.
        if (userData == null)
        { 
            out.println("<HTML><BODY>");
            out.println("<H1>Sorry</H1>");
            out.println("The system is experiencing problems.");
            out.println("</BODY></HTML>");
            return;
        } 

// Now try to get the username from the table
String userName = (String) userData.get("username");

// 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>");
    }
}
						

This method of storing data makes one assumption that you can't overlook: The servlet and Java Server Page must be running within the same Java Virtual Machine (JVM). The key to preserving the data is that the UserDataTable class uses static data. If the servlet runs in one JVM while the Java Server Page runs in another JVM, they will be using separate copies of the UserDataTable class, and thus will not share any data. If you ever decide to use a technique like this, make sure that everything is running within the same JVM. Most servlet and JSP engines on the market today run within a single JVM.

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 browser to use forms only as a method of accessing server-side pages. If you use a hyperlink, there are no form variables to pass. You must either rewrite your hyperlinks to include something like "?userkey=9345837479" or find a better alternative. That alternative is the session object.

The Java Server Pages API has several built-in objects. You have already seen two of them: request and out. The next important one is called session, and it's an instance of HttpSession. The three methods that you use the most in the session object are getAttribute, setAttribute, and removeAttribute. The declarations for these methods are

public void setAttribute(String name, Object value)
    throws IllegalStateException
public Object getAttribute(String name)
    throws IllegalStateException
public void removeAttribute(String name, Object value)
    throws IllegalStateException

These methods act much like the get and put methods in the Hashtable class. That is, setAttribute associates a name with a value, and getAttribute returns the value associated with a name or null if there is no value associated. For example, to store some data in a session, you would do something like this:

session.setAttribute("someKey", "here is my data");

To retrieve the data back out of the session, you would do something like this:

String myData = (String) session.getAttribute("someKey");

IllegalStateException is thrown when you try to get or set an attribute on an invalid session. A session becomes invalid either when you call its invalidate method or after the session has timed out. The servlet engine keeps track of how long it has been since a session has been accessed; after a certain period of inactivity, the session is marked as invalid. You can configure the amount of time it takes to time out a session, either on a per-session basis or for all sessions.

Listing 5.7 shows the Login.jsp page modified to support the session object instead of the UserDataTable class. Notice that it no longer needs to use the hidden form variable.

<%@ page language="java" import="java.util.*,usingjsp.*" %>

<HTML>
<BODY bgcolor="#ffffff">

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

// Store the username in the session
session.setAttribute("username", userName);
%>
Welcome, <%=userName%>!
<FORM action="/servlet/usingjsp.ColorServlet3" method="POST">

<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>

If you are having trouble storing or retrieving your session information, see "Storing and Retrieving Data," in the "Troubleshooting" section at the end of this chapter.

You have probably guessed this already, but the session object you use in a servlet is identical to the one you use in a Java Server Page. The only difference is that it isn't already conveniently sitting around in a variable named session. Instead, you must get the session object from the requestobject.

To get the session object from the request object, just call the getSession method:

HttpSession session = request.getSession();

Inside a servlet, you use the same getAttribute and setAttribute methods to update session variables as you do in a Java Server Page. After all, the session object is an instance of HttpSession in both a servlet and a JSP.

Listing 5.8 shows the modifications necessary to ColorServlet to make it use HttpSession instead of the UserDataClass. Also notice that unlike the previous versions of ColorServlet, this one is a subclass of HttpServlet (the others were subclasses of GenericServlet). The method signature on the service method is a little different now, too, because the request and response parameters are now instances of HttpServletRequest and HttpServletResponse.

package usingjsp;

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

public class ColorServlet3 extends HttpServlet
{ 
    public void service(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 color parameter
        String color = request.getParameter("color");

// Get the username from the session
HttpSession session = request.getSession();

        String userName = (String) session.getAttribute("username");

// 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>");
    }
}

The HttpSessionBindingListener interface defines notification methods that the session object uses to notify objects when they are added to or removed from a session. There are two methods in the interface:

public void valueBound(HttpSessionBindingEvent event);
public void valueUnbound(HttpSessionBindingEvent event);

As you might have guessed, valueBound is called when an object is added to a session; valueUnbound is called when the object is removed from a session. Listing 5.9 shows an example class that listens for valueBound and valueUnbound messages and counts the number of sessions that are bound to it.

package usingjsp; 

import javax.servlet.http.*;

/** Counts the number of sessions that are bound to this object. */

public class BindListener implements HttpSessionBindingListener
{ 
// The current session count
    protected int numSessions;

    public BindListener()
    { 
        numSessions = 0;
    } 

// Every time this object is added to a session,
// valueBound is called
    public synchronized void valueBound(HttpSessionBindingEvent event)
    { 
        numSessions++;
    } 

// Every time this object is removed from a session,
// valueUnbound is called
    public synchronized void valueUnbound(HttpSessionBindingEvent event)
    { 
        numSessions--;
    } 

// Returns the current number of bound sessions
    public int getNumSessions()
    {
        return numSessions;
    }
}
						

To test the BindListener class, you need to observe what happens when you access it from multiple sessions and also see what happens when you invalidate a session containing a BindListener object. You should expect to see the session count go up whenever the object is added to a session, and you should see the count go down when the object is removed from a session, or when the session it belongs to is invalidated.

Listing 5.10 shows a test harness JSP that exercises the BindListener class. By selecting various hyperlinks, you can remove the BindListener object from the session or invalidate the session.

<%@ page language="java" import="usingjsp.BindListener" %>

<HTML>
<BODY bgcolor="#ffffff">

<%-- Set up a static BindListener shared by all instances of this JSP.

     There is probably only one instance, but just in case the server creates

     multiple instances, this page can handle it. --%>
<%!
    protected static BindListener listener = new BindListener();
%>

<%

    BindListener l = null;

// Allow the browser to pass a "removeListener" parameter to remove
// a listener from the session

    if (request.getParameter("removeListener") != null)
    { 
        session.removeAttribute("listener");
    } 

// Allow the browser to pass a "resetSession parameter to clear out
// the session
    else if (request.getParameter("resetSession") != null)
    { 
// See if there is already a session
        HttpSession oldSession = request.getSession(false);

// If there was already a session, invalidate
        if (oldSession != null)
        { 
            l = (BindListener)
                oldSession.getAttribute("listener");
            oldSession.invalidate();
// Tell the user that the session was reset and show that the
// bind counts have been updated. Make sure that there was a
// listener on the old session, too.

            if (l != null)
           { 
%>
Your current session was reset. The listener now has <%=l.getNumSessions()%>
active sessions.<P>
<%
            }  else { 
%>
Your old session didn't have a listener.<P>
<%
            } 

            l = null;

        }
    }
    else
    { 
// See if the listener is already in the session
        l = (BindListener)
            session.getAttribute("listener");

// If not, add the global copy of the listener to the session
        if (l == null)
        { 
// Put the global listener variable into the session
            session.setAttribute("listener", listener);
            l = listener;
        } 
    } 
%>
<%
    if (l != null)
    { 
%>
You have a listener bound to your session.
<%
    }  else { 
%>
You do not have a listener bound to your session.
<%
    } 
%>
There are currently <%=listener.getNumSessions()%> sessions holding onto the
bind listener.
<P>
<TABLE>
<TR>
<TD>
<A href="BindTest.jsp">Refresh Form</A>
<TD>
<A href="BindTest.jsp?removeListener">Remove Listener</A>
<TD>
<A href="BindTest.jsp?resetSession">Reset Session</A>
</TABLE>
</BODY>
</HTML>
						

Figure 5.5 shows several browser sessions running BindTest.jsp.

Figure 5.5. The BindListener object keeps track of how many sessions it belongs to.

To disable cookies in Internet Explorer, you must change the security level for your Internet zone. Internet explorer groups Web sites into four zones: Local Intranet, Internet, Trusted Sites, and Restricted Sites. To change the security settings for a zone, go to the IE menu and select Tools-Internet Options and then click the security tab. You should see a dialog box like the one shown in Figure 5.7.

Figure 5.7. To change the cookie settings, go to the Security tab in the Internet Options.

You can change the setting on each zone to a different level (high, medium, medium-low, and low). The high setting disables cookies. If you are testing with the Web site on your own machine, you must change the setting for the Local Intranet zone. If you are testing with another machine, you will probably need to change the setting for the Internet zone. Just move the slider on the security dialog box up to high.

TO disable cookies in Netscape, click the Edit menu and select Preferences. Then, select Advanced in the dialog box. You should see a dialog box similar to the one shown in Figure 5.8. Click the Do Not Accept or Send Cookies button.

Figure 5.8. To change the cookie settings in Netscape, go to the Preferences dialog box and select Advanced.

If you are having trouble disabling or enabling cookies in your browser, see "Cookie Settings" in the "Troubleshooting" section at the end of this chapter.

Unfortunately, to make full use of URL rewriting, you must pass all your pages through the URL rewriting process. In other words, if you have a static HTML page with links to Java Server Pages or servlets that needs session information, you must turn these static HTML pages into Java Server Pages that use encodeURL to rewrite the HREF values for all the hyperlinks. So, in your HTML file where you have a line like

<a href="CallMe.jsp">

the JSP file would read

<a href="<%=response.encodeURL("CallMe.jsp")%>">

You also need to change the action attributes in each of your <FORM> tags. A <FORM> tag with an action of "HandleForm.jsp" appears in the JSP like this:

<form action="<%=response.encodeURL("HandleForm.jsp")%>">

From all appearances, the application object seems like overkill. What is the difference between storing something in the application object and storing it in a static variable somewhere? You will see in Chapter 28, "Packaging a JSP Application," that it's possible to group a set of Java Server Pages and servlets into an application. The servlet engine knows what application a particular JSP or servlet belongs to. You could, for example, have a set of Java Server Pages deployed in a server under an application called "QA" and an identical set of JSPs under an application called "Beta" . These two applications, although running in the same server and the same Java Virtual Machine, would have different application objects (that is, different ServletContext objects).

Now you can see how this differs from a static variable. If you tried to store a data item in a static variable, you would circumvent the notion of separate applications. There is only one copy of a static variable within a single Java Virtual Machine. You can't say that the "QA" application gets its own copy of a static variable and the "Beta" application gets another unless you are somehow able to run each application in a separate virtual machine. Because you can't count on a servlet engine to support multiple JVMs, you shouldn't rely on static variables for application-level data sharing.