Issues concerning cookie acceptance

The use of cookies to circumvent the problems derived of the state-less nature of the HTTP protocol presents a problem: the user may set his browser to receive no cookies, and a script running at the server has no means to be aware of that fact. For example, a Perl script using cookies cannot know if the cookies it sends are received or not. At this respect I would like to discuss briefly the usage of the terms 'send,' 'receive,' 'retrieve,' etc. Some purists object the usage of the verb 'retrieve' because, they say, is the Web server which sends the cookie to the script and not the script who initiates an action to get it. For the sake of these purists, I will review here how cookies travel between client and server.

The cookie process is initiated when the server--in response to a browser's request--sends to the browser a page that contains a cookie in its header, or contains a script that when interpreted at the client side will make that the browser receive a cookie. In the first case, the cookie is included with the page headers by a server-side script like the one I have presented. In the second case, it is JavaScript embedded in the HTML code of the page that makes the job.

Once the browser has the cookie it may accept it or ignore it. This is ruled by the preferences the user has set up. There are many ways in which the user may regulate the acceptance of cookies: he may want to reject all cookies altogether, reject all cookies from third parties, accept cookies from only some sites, decide cookie by cookie, etc. Whatever the browser does with the cookie, it tells nobody. There is no way to know what the browser has done with the cookie, except to try to get it again. If the browser returns us the cookie, it means that it stored the cookie; otherwise, the cookie was discarded.

For a server-side script, the only way to get (or "retrieve") the cookie is to expect the next request from the browser and see if the request carries the cookie. We will see later how a server-side script can force this request, but the fact remains that until the request is received the script cannot know what happened. On the other hand, a client-side script needs not to wait the next request--it can ask for it again, immediately after sending the cookie.

It must be observed, at this point, that the fact of the cookie being returned does not mean that a successive cookie will also be accepted. As I said the user may elect to decide each time individually, or he may at any moment turn off cookie accepting by changing his browser's preferences. This is why it is not reliable the strategy of testing if the user accepts cookies before actually using them. What must be done is to send the cookie that really interests us, try to get it back, and, if we cannot do it, either alert the user or use another mechanism.

For the next discussion, I will assume that we are trying to set up a system where users have to log in before reading the site's pages. Once the user has been logged in--by means that are not explained here, a cookie is sent so that the user has access to all the pages. You may think of the cookie as a ticket to get in. To do this using Perl, you must have at least two scripts, and maybe three. The first script will replace the home page of the site, so that instead of "index.html" you will have "index.cgi". This script will have the mission of sending the cookie with the user identification, and immediately redirect the browser to the real home page. An example follows.

# calculate the ticket number as a number of five digits
# and leave it in the variable $user_id
print "HTTP/1.0 302 Moved Temporarily\n";
print "Set-Cookie: session_id=$user_id\n";
print "Location: index1.html\n\n";

A user identification is calculated by instructions not shown here and stored in the variable $user_id. Then HTTP headers are sent that perform two tasks: sending a cookie named "session_id" and redirecting to the home page, in this case "index1.html".

The second Perl script, which should be called from the home page (index1.html), would only have to read the cookie to check that it has been effectively received by the user. If it succeeds, then the user can be considered as logged in. If it cannot retrieve the cookie, it assumes that this is a guest user that can see only certain restricted contents because he has chosen not to receive cookies.

If you want to make your site a cookie-enabled-only one, or at least warn the user that having cookies enabled will give him "a more pleasant experience," you will need another script that will be the target of the first one. Instead of redirecting to the home page, the first script will send the browser to a new second script that will try to read the cookie. If it succeeds, it redirects to the home page; if not, it redirects to a page were the user is forbidden to enter the site, or he is advised to turn cookies on. The third script, at the home page, is the same that was previously the second one.

The drawback of this two- or three-scripts scheme is that the user is identified only at the pseudo home page. If he enters the site by any other point (page), he will be not given an identity. This was acceptable in old times when people arrived to a site using the URL of its home page as given by a friend or by a directory like Yahoo. In the present day, most people use search engines like Google that lead them directly to the page of interest, and the home page is no longer the only entry point. Under these circumstances, most visitors will have to be redirected to the login page. It must be noted, nonetheless, that any of these methods represents an improvement with respect to just sending the cookie and supposing that the user accepted it.

Previous | Contents | Next

	| HOME | FEEDBACK | BOOKMARK | Build your Website © 1999-2008 Hector Castro -- All rights reserved