Unit 15.1. Using Cookies to Maintain State
Maintaining State in a Web Application
It can be difficult to grasp that each request is unrelated when surfing the Web. What happens when a browser requests a Web page or resource from a site? In short:
Browser identifies the server that has the resource
Browser requests the resource from the server
Server returns the resource to the browser for rendering
Although each request is separate, Web browsers create the feeling of a user session by placing each request for a page into a larger context; thus a Web browsing session can unfold like a story, with you as the protagonist and the sequence of pages you travel through as the plot. Browsers keep track of each page request, and provide “Previous” and “Next” buttons that reinforce the impression that each request is part of a larger session. However, this impression is the work of the browser. From the server’s point of view, the server is handling separate page requests without being able to recognize that the same user is making them.
In a Web application, it is often necessary to maintain information about users from one page request to the next. For example, if a site’s splash page requires a user to provide a name and password to access a site, how does each subsequent page know whether the user already logged in successfully? If a user clicks a link to add an item to a shopping cart, how does the server know whose shopping cart to fill? How can an application identify and track its users?
Even if users do not provide a name and password to identify them, a Web site might want to assign an id number to a visitor and track their activity as they travel through the site. For this to work, a number such as a “session id” must be accessible throughout the application. Applications that maintain a shopping cart for visitors must know which visitor is on each page. The shopping cart items might be stored in the database, but they must still be linked to the user by a session id or user name.
Some state information can be passed in parameters, as shown throughout Chapter 11, “WEB TOOLKIT II: FRAMES, FORMS, AND PARAMETERS.” Including name/value pairs at the end of URLs in links is one way to share information from one page to another; clicking on a specific instructor’s name in a list can take you to a page with personal details about that instructor because the instructor_id is passed as a parameter from one page to the next. Forms also pass information to the programs/procedures specified in their ACTION attributes, through inputs like text boxes, text areas, checkboxes, and radio buttons, as well as through hidden inputs.
However, parameter passing can become cumbersome when information is needed across an entire Web site. Consider the above example of a Web site that has a login screen. Once a user has logged in, their user id can be passed from one page to the next throughout the site. However, each page must be written to handle this additional parameter.
How else can this state information about the user be maintained? Another way is to use cookies.
What is a Cookie?
A cookie is a text string. The string contains a name and a value. You can think of it as a name–value pair, or as a variable—a holder of information.
Cookies are stored and managed by the browser. It is logical to have browsers manage cookie information. Browsers are already keeping track of the previous and next sites that a user has visited. A cookie is simply another piece of information about the user’s browsing experience that the browser manages. The advantage of cookies is that they outlast a single request to a Web server.
Cookies are sent to a user’s browser by servers. When a server responds to a browser’s request by delivering a page to the browser, this response can include a request to set a cookie. If the user’s browser is configured to accept cookies, the browser then stores the cookie information, which is tagged as coming from a specific server. A communication between a browser and a server that wants to set a cookie looks like this:
Browser identifies the server that has the resource.
Browser requests the resource from the server.
Server returns the resource to the browser for rendering. Included in the resource may be a request to the browser to set a new cookie.
Browser stores any cookies received and renders the page.
End of communication.
The next time a user requests a resource from the same server, how does the server see the cookie information? The browser returns the cookie to the server that sent it. Now, when a user requests a resource through the browser, the entire communication looks like this:
Browser identifies the server that has the resource.
Browser checks for any existing cookies from the server.
Browser requests the resource from the server. The request includes any cookie information previously placed by that server.
Server receives the cookies along with the request. The cookie information can be used to assemble the resource for the browser.
Server returns the resource to the browser for rendering. Included in the response may be a request to the browser to set a new cookie.
Browser stores any cookies received and renders the page.
End of communication.
What a Cookie Looks Like
A cookie is simply a string of text.
FOR EXAMPLE
.mysite.org TRUE / FALSE 1047428811 SITESERVER_ID=6e9151adb730a62
This cryptic string, stored in a single line by the browser, is really just a way of storing a variable called SITESERVER ID with a value of 6e9151adb730a62 for the site mysite.org.
Breaking this cookie into parts, you will see that the parts correspond to the parameters you need to supply when you send cookies of your own (Table 15.1).
 | Expiration dates are in seconds—the number of seconds since January 1, 1970. To translate this into a readable date, simply divide the number of seconds by 86,400 to know how many days the number represents: in other words, 60 (seconds) × 60 (minutes) × 24 (hours). Once you have the number of days, add the days to January 1, 1970. Ex: SELECT TO_DATE('01-JAN-1970')+ROUND(1047428811/ 86400) from dual; |
Cookie Storage
Cookies are stored in two ways. They can be held by the browser temporarily, and then vanish when the user exits the browser program. This short-term cookie is a session-level cookie. Session-level cookies can be used to:
Store a session id for a user until the browser is closed
Store other data that is temporary until the browser is closed
Maintain a shopping cart until the browser is closed
Track activity in a single browser session until the browser is closed
The other type of cookie is a persistent cookie. The browser places persistent cookies directly into your machine’s file system. As with other files saved to your file system, they remain on the computer even after the browser programs have been closed and the computer is turned off. It is persistent cookies that enable a Web site to do the following:
Greet you by name when you return to a site the next day using the same computer
Tell you how many times the browser on that specific computer has visited a site overall
Provide you with a list of stores near you based on a zipcode you provided the previous visit
| Cookie Part | Description | Example |
|---|---|---|
| Domain | The domain that set the cookie. This is the domain that will have access to the cookie later. | .mysite.org |
| T/F Flag | A TRUE/FALSE value indicating whether all machines within the domain can access the cookie later. This value is set automatically by the browser unless a value is provided when the cookie is set. | TRUE |
| Path | The path within the domain that the cookie is valid for. If / is specified, then all directories in the domain can access the cookie. Otherwise, the default is the current directory and any of its subdirectories. | / |
| Secure | A TRUE/FALSE value indicating whether a secure protocol such as HTTPS is needed to access the cookie. The word secure must be added to specify that HTTPS is needed. | secure |
| Expires | Whether this cookie part is present determines how the cookie will be stored. This cookie part represents the UNIX time when the cookie will expire. UNIX time is defined as the number of seconds since January 1, 1970, 00:00:00 GMT (Greenwich Mean Time). | 1047428811 |
| Name | The name of the cookie | SITESERVER_ID |
| Value | The value of the cookie | 6e9151adb730a62 |
When a server sends a cookie, it specifies an expiration date for the cookie. The expiration date determines whether a cookie is a session-level or persistent cookie.
If cookies are sent with no expiration date specified, then they are session-level cookies. They are held in the browser’s memory until the browser application is closed.
If cookies are sent with an expiration date, then they are stored in the computer’s file system. Most browsers will store up to 20 cookies per site.
The way to locate persistent cookies that have been placed on your file system varies, since different versions of browsers store cookies differently on different versions of operating systems. You can always do a search for *cookie*.* in your file system to locate cookie-related files or directories. Here are some additional guidelines:
In IE for Windows: Each Windows user will have a directory created in the same volume as the operating system. For example: “C:Documents and SettingsYourUserNameCookies.” “YourUserName” should be replaced with your user name for the machine. If you are using an older version of Windows that does not require a login, look in the directory Windows for a subdirectory called Cookies. There are multiple files stored here.
In Netscape for Windows: Look for a single file called cookies.txt, usually stored in: ProgramFiles/Netscape/Users/YourUserName/ cookies.txt. “YourUserName” should be replaced with your user name for the machine. The location of cookies.txt will depend on the installation of Netscape on your computer.
How Cookies are Sent
Cookies are sent in the HTTP header. Cookies are not part of HTML; they are part of the HTTP protocol. Recall from Chapter 1, “Introduction to Oracle Web Applications,” that HTTP is the protocol of the World Wide Web. Requests for Web pages, as well as the Web pages that are returned, are sent with HTTP headers that can contain cookies.
Within the HTTP header, the cookie specification looks something like this:
Set-Cookie: name=<value> expires=<expires> path=<path> domain=<domain> [secure]
 | NOTE: Since servers send cookies in the HTTP header, you will not see cookies or cookie values if you view the source of an HTML page in the browser. |
HTTP Headers And Environment Variables
Normally you do not see the HTTP header in the browser. As explained in Chapter 1, “Introduction to Oracle Web Applications,” the HTTP header is the behind-the-scenes means by which a browser communicates with a Web server, and vice versa. It is through this header that HTTP requests and responses are made.
Some of the most common environment variables that can be part of the HTTP header are:
SERVER_SOFTWARE— The name and version number of the server software
REQUEST_METHOD— The request method, e.g., GET, HEAD, or POST
QUERY_STRING— The query string of the URL, i.e., the part following the “?” (if present)
The HTTP header begins with an instruction to open the header. Another instruction closes the header. Note that this header is not the same as the HTML header created by the <HEAD> tag.
To respond to a client’s request for a page, the PL/SQL agent in the Application Server automatically creates an HTTP header. It indicates that the contents have a MIME type (Multipurpose Internet Mail Extension) of “text/html,” and closes the HTTP header. Then it takes the HTML output from your procedures, and sends it with this HTTP header.
To perform certain tasks, such as creating a cookie or activating a content handler on the user’s browser, we must interrupt this normal flow of events. This is done with the OWA_UTIL procedures that change the default HTTP header. Unlike the htp procedures, these OWA_UTIL procedures do not generate HTML. Instead they create text within the HTTP header that contains special instructions that cause the browser to act in a particular way. Other parts of the OWA_UTIL package are covered in more detail in Chapter 16, “The OWA_UTIL Package: Dynamic SQL, HTML, Date Utilities, and More.”
How Cookies are Returned
How does a server “read” the cookie later on? Browsers transmit cookie data along with requests for new pages from the same source. Again, this is done in the HTTP header of the request, not in the HTML page itself.
First the browser has to identify the server that has the resource the user wants.
Then the browser checks all of its existing cookies, both session-level and persistent cookies, to see whether any of them are from that site. If it finds any cookies from that site, it bundles them up and includes them in the HTTP header of the request for the new page. The browser does this for every new request, regardless of whether the server actually requires the cookie information to serve up that particular page; the cookies are always along for the ride with each new request.
Since the cookie arrives at the server as part of the page request, the server can use the cookie when putting together the page for the user. If the cookie contains a user’s id, then the user’s name can be retrieved from a database and built into the page. If the cookie contains a zipcode, a page can be built containing regional information. The server is supplied with the cookie information before the user even sees the resulting page to view, and the server can tailor a page to a specific user.
It is important to note that the browser only returns cookies to the site that has placed them. For example, imagine that you went thumbtack shopping and provided your personal information to a Web site that sold thumbtacks when placing your order. The thumbtack site placed several persistent cookies on your computer. You then visit a completely different site that sells refrigerator magnets. Would the magnet site be sent the cookies placed by the thumbtack site? No—recall that each cookie contains the name of the site that placed the cookie, and the browser only sends cookies back to the site that placed them.
Realize, however, that a single page may be composed of material from several different sites. A page for Thumbtack World could contain advertisements from Refrigerator Magnet Land. The advertisements might be pictures whose source attribute is a URL on Refrigerator Magnet Land’s server. So the browser requests resources from two different company’s servers in order to build the page. In this case, the browser would send Thumbtack World its own cookies, and also send Refrigerator Magnet Land its own cookies, based on the user’s visit to a single page.
Browser Settings for Cookies
Browsers offer users some options with regard to cookies. Most browsers allow users to completely turn off cookie functionality. If you do this, some sites may not display properly, or they may demand that you configure your browser to accept cookies before visiting their sites. If your application requires cookies, your only recourse is to tell users to accept cookies.
Your browser may offer users the option of being warned about cookies before accepting them. For each cookie sent by a server, the browser will display a pop-up window telling the user that the server is attempting to send a cookie, and asking whether or not it should accept the cookie. The message may not use the word “cookie,” but instead refer to a “piece of temporary information” that a server wants to store on your computer. If you choose this setting in your browser, you will see many pop-up windows as you browse through the Web that prompt you as to whether or not to accept cookies, and you will gain an understanding of when servers are sending cookies to your browser.
However, more commonly, users set their browsers to accept all cookies, and many cookies are accepted by browsers automatically, unbeknownst to the users.
Browsers provide options to warn users before accepting a cookie, but how about returning cookies to servers that were already placed? This activity—returning cookies to servers with new requests—is even more automatic than the browser’s acceptance of cookies in the first place. Browsers that give users the option of being warned when a cookie is being sent may not provide an option to be warned when existing cookies are sent back to a server. If any cookies already exist, they will be returned to the servers that sent them, whenever new pages are requested from those same servers. Usually it is only by disabling cookies completely, or by deleting existing cookies, that this activity can be halted. However, browsers are responding to users’ distrust of cookies by offering more elaborate levels of cookie settings.
Problems with Cookies
There are technical as well as philosophical problems with cookies.
Persistent cookies, which are stored on the file system, have numerous limitations. Perhaps the most problematic aspect of persistent cookies is that they assume use of the same physical computer, which is not always an accurate assumption. If you let a friend named Daniel Shultz use your computer to purchase something from one of your favorite sites, and then you visit that site later, you could be greeted cheerily with the words, “Welcome Back, Daniel Shultz!” Most sites recognize that such a greeting can be inaccurate, and so they also include an existential disclaimer such as this: “If you are not Daniel Shultz, click here.” While some systems require a user login and store cookies separately for each user, that type of configuration cannot be relied upon.
Moreover, because persistent cookies are stored in a file system, they are gone if the user deletes the cookie files or if the hard drive is cleaned and the software reinstalled.
For these reasons, persistent cookies are best used to provide features that are nice but not absolutely necessary to the function of the site. For example, having your zipcode preloaded into a restaurant locator is convenient, but it is easily added or changed if the zipcode is inaccurate or missing. Likewise, if you are presented with options based on what Daniel Shultz likes to view because he visited the site last, you can always tell the site that you are someone else.
Other problems with cookies are less technical than ethical. Many users find cookies problematic and do not appreciate having their system compromised without their knowledge. When you visit an outside site, it can place a cookie file on your computer’s file system, such as the innocuous-looking string of text in the section “What a Cookie Looks Like” in this unit. The fact of an outside site placing a file on a user’s personal computer without the user’s explicit permission is disconcerting to many people. Moreover, visiting a site that greets you by name when you have not logged in or identified yourself in any way can be unsettling. The convenience of having a site tailored to your preferences or needs wars with a need for privacy.
Since cookies allow a site to identify a user from one request to the next, and throughout each request during a visit, the site can deduce information about the user’s likes and dislikes and compile a profile of that user’s interests. If the user has provided name and/or address information previously, then the site may be able to tie that together. Even with session-level cookies, a single visitor’s activity can be tracked by assigning them a session ID number, and then recognizing each subsequent request by the Session ID that is sent along with each subsequent request of the same site. This is valuable information that helps the site find out how effective it is and which of its links are used the most. This is also valuable information for any advertisers that want to place an ad on that site. It is much more useful to know which route a user took to access a page on a Web site than it is to know simply the total number of requests for each page. However, it is an invasion of the user’s privacy. The user is not anonymously browsing a site, but rather browsing a site with each request noted and possibly tracked in a database. If a persistent cookie is used, or if the user logs in or purchases something, then the user’s identity is known and linked to the previous activity.
As mentioned earlier in this chapter, the fact of each site being associated with different cookies can be an illusion when it comes to advertising. Suppose that a site contains an advertisement that is a clickable image. The IMG SRC can be a URL for a completely different server. That server returns a resource to the browser, and it can place its own cookies when it returns the advertisement. If another site uses the same advertiser, that advertiser can be returned its cookie, and recognize that the same person is visiting both sites.
Unit 15.1 Exercises
15.1.1. Locate Your Cookies
| Q1: | Locate cookies stored on your computer. Experiment with deleting cookies and observe how that changes the behavior of sites you visit regularly. |
15.1.2. Experiment with Browser Settings for Cookies
| Q1: | Change the settings for cookies on your browser. Experiment with different cookie settings and observe how that changes the behavior of sites you visit regularly. |