JavaScript Validator
JavaScript Editor
|
|
The key to cookies is the document object's cookie property. Using this property we can create and retrieve cookie data from within our JavaScript code.
We can set a cookie by setting document.cookie to a cookie string. We'll be looking in detail at how this cookie string is made up later in the chapter, but let's first create a simple example of a cookie and see where the information is stored on the user's computer.
The following code will set a cookie with the UserName set as Paul, and an expiration date of 28 December 2010.
<html> <head> <script language=JavaScript> document.cookie = "UserName=Paul;expires=Tue, 28 Dec 2010 00:00:00;"; </script> </head> <body> <p>This page just created a cookie</p> </body> </html>
Save the page as FreshBakedCookie.htm. We'll see how the code works as we discuss the parts of a cookie string, but first let's see what happens when a cookie is created.
How we view cookies without using code varies with the browser we are using. We'll see how this is done, first in IE, and then in NN.
In this section we'll see how to look at the cookies that are already stored by IE on our computer. We'll then load the cookie-creating page we just created with the preceding code to see what effect this has.
First we need to open IE. I'm using IE 6, so if you're using IE 4 or 5 you will find the screenshots and menus in slightly different places.
Before we view the cookies, we'll first clear the temporary Internet file folder for the browser because this will make it easier to view the cookies that our browser has stored. In IE, select Internet Options from the Tools menu, as shown in Figure 11-1.
Having selected this option, we'll be presented with the Internet Options dialog box shown in Figure 11-2.
Click the Delete Files button under Temporary Internet files. We'll be asked to confirm our request in another dialog box, shown in Figure 11-3.
Check the Delete all offline content check box and then click OK. We'll be returned to the Internet Options dialog box.
Let's have a look at the cookies we have currently residing on our machines. From the Internet Options dialog box, click the Settings button next to the Delete button grouped under Temporary Internet files. We should see the dialog box shown in Figure 11-4.
Now click the View Files button, and a list of all the temporary pages and cookie files on your computer will be displayed. If you followed the instructions previously and deleted all temporary Internet files, all you should see are the cookie files on your computer, as these are not deleted. The number of cookie files on your computer will vary, but Figure 11-5 shows those currently on mine:
The actual cookies, their names, and their values, will look slightly different depending on your computer's operating system. In Figure 11-5, we can see I have four cookie files: one set by the google.co.uk website, a second and third by amazon.co.uk, and the fourth by yahoo.com.
We can delete each cookie simply by clicking it once, then pressing the Delete key, as you would with any file in Explorer. If we want to delete all cookies, IE 6 has a button on the general tab of the Internet Options dialog box to delete cookies.
We can examine the contents of the cookies by double-clicking them. Note you may get a warning about the potential security risk of opening a text file, although we are fairly safe with cookies because they are simply text files. I've double-clicked the cookie file named google set by the search engine Google; we can see its contents Figure 11-6.
As we can see, a cookie is just a plain old text file. Each website, or domain name, has its own text file where all the cookies for that website are stored. In this case there's just one cookie currently stored for google.co.uk. Domains like amazon.com will almost certainly have many cookies set.
In Figure 11-6, we can see the cookie's details. Here, the name of the cookie is PREF; its value is a series of characters, which although indecipherable to us, make sense to the Google website. It was set by the domain google.co.uk, and it relates to the root directory /. The contents probably look like a mess of characters, but don't worry: When we see how to program cookies, we'll see that we don't need to worry about setting the details in this format.
After you have finished, close the cookie and click OK on the dialog boxes to return to the browser.
Now let's load the FreshBakedCookie.htm page into our IE browser. This will set a cookie. Let's see how it has changed things by returning to the Internet Options dialog box (by choosing Internet Options from the Tools menu). Click the Settings button, and then click View Files. My computer now shows the information shown in Figure 11-7.
Because we are creating a cookie from a web page that is stored on the local hard drive rather than a server, its domain name has been set to Code, the directory my page was stored in. Obviously, this is a little artificial. In reality people will be loading our web pages from our website on the Internet and not off our local hard drive. The Internet address is based on the directory the FreshBakedCookie.htm file was in. We can also see that it expires on December 28, 2010, as we specified when we created the cookie. Double-click the cookie to view its contents, which look like those in Figure 11-8.
We can see the name we gave to the cookie at the left, UserName, its value, Paul, and also the directory it's applicable to. The expiration date is there as well; it's just not in an easily recognizable form. Note that we may sometimes need to close the browser and reopen it before we see the cookie file.
There is no sharing of cookies between browsers, so the cookies stored when we visited websites using an IE browser won't be available to NN and vice versa.
NN keeps its cookies in a totally different place than IE does, and the contents are viewed by a different means. In fact the means of viewing the cookies differs between versions of the browser.
All of the NN 4.x browser cookies are kept in one text file called cookies.txt, which is contained under the directory in which Netscape is installed. However, its exact location will vary, so the easiest way to find this file is to use the operating system to do a search for a file called cookies.txt.
For example, on my computer the file was found in C:\Program Files\Netscape\Users\Default, but it'll most likely be different on your computer.
Once we've found the file, we want to open it with a text editor. On my computer it contained the cookies shown in Figure 11-9.
As you can see from Figure 11-9, although this was taken from an NN browser on the same machine as IE whose cookies we saw earlier, the cookies have nothing in common. There are no amazon.com or yahoo.com cookies. On the last line there is a cookie set by the Internet Movie Database website, from imdb.com, since I visited it with this browser.
Again we can see the cookie details. This time the first detail is the domain the cookie belongs to. Second is the directory on that domain; then moving along three pieces of data we come to the cookie's name, for example uu, and then its value. Although the value is meaningless to us, it means something to the imdb site!
When we know what we are looking for, we can make out individual cookies, their values, and so on from this file. However, when viewing the cookies using code, it's much easier.
If we want to delete one or more of the cookies, we simply need to close the Netscape browser and then delete the cookie's text in the text file, before saving it. Be careful to delete only the cookie text, and not the top line warning you that it is a generated file.
Let's load our FreshBakedCookie.htm page into the NN browser and see the effects on cookie.txt.
If we then reopen the cookie.txt file, we should see somewhere within it the lines shown in Figure 11-10.
We can see that our code has succeeded and the cookie is in there with the name UserName and the value Paul. The expiration date is also contained within the cookie.txt file, but not in an obvious form.
On Netscape Navigator 6, it is a bit easier to manage the viewing and deleting of cookies. From the Tasks menu, choose the Privacy and Security option. Click Cookie Manager and then View Stored Cookies. This will open the Cookie Manager, shown in Figure 11-11. In Netscape 7 choose the Tools menu, select Cookie Manager, and finally the Manage Stored Cookies menu.
Click OK to get back to the browser, and load FreshBakedCookie.htm. Repeat the process we followed previously to get to the Cookie Manager, and we should find that the UserName cookie has been added to the box. Click the cookie, and its details are displayed as shown in Figure 11-12.
Note that buttons are provided at the bottom of the Cookie Manager to delete the cookie selected or all of the cookies that are stored.
Now that we've seen how to view cookies manually, let's look at how we create them and read them using code. We'll start by looking at each of the parts making up a cookie string.
When creating a cookie there are six parts we can set: name, value, expires, path, domain, and security, although the latter four of these are optional. We'll now look at each of these in turn.
The first part of the cookie string consists of the name and value for the cookie. The name is used so that we can reference the cookie at a later date, and the value is the information part of the cookie.
This name/value part of the cookie string is compulsory; it sort of defeats the point of the cookie if you don't store a name or value because storing information is what cookies are all about. You should make sure that this part comes first in the cookie string.
The value for the cookie is a primitive string, although of course the string can hold number characters if it is numerical data that we want to store. If we are storing text, certain characters, such as semi-colons, cannot be used inside the value, unless we use a special encoding, which we'll see later. In the case of semicolons, this is because they are used to separate the different parts of the cookie within the cookie string.
In the following line of code, we set a cookie with the name UserName and the value Paul.
document.cookie = "UserName=Paul;";
This cookie has a very limited lifespan. By lifespan, I mean the length of time the information will continue to exist. If we don't set an expiration date, a cookie will expire when the user closes the browser. The next time the user opens the browser the cookie will be gone. This is fine if we just want to store information for the life of a user session, which is a single visit by the user to our website. However, if we want to ensure that our cookie is available for longer, we must set its expiration date, which we'll look at next.
If we want a cookie to exist for longer than just a single user session, we need to set an expiration date using the second part of the cookie string, expires, as follows:
document.cookie = "UserName=Paul;expires=Tue, 28 Dec 2010 00:00:00 GMT; ";
The cookie set by the previous line of code will remain available for future use right up until December 28, 2010. Note that the format of the expiration date is very important, especially for IE browsers. It should be the same format it is given by the toGMTString() method. This method is similar to the toUTCString() method that we saw in Chapter 9.
In practice, we'll probably use the Date object to get the current date, and then set a cookie to expire three or six months after this date. Otherwise, we're going to need to rewrite our pages on December 28, 2010.
For example, we could write the following:
var expireDate = new Date(); expireDate.setMonth(expireDate.getMonth() + 6); document.cookie = "UserName=Paul;expires=" + expireDate.toGMTString() + ";";
This will create a new cookie called UserName with the value of Paul and it will expire 6 months from the current date. Note that other factors can cause a cookie to expire before its expiration date, such as the user deleting the cookie or the upper cookie limit being reached.
We'll find that 99 percent of the time, we will only need to set the name, value and expires parts of a cookie. However, at times the other three parts, such as the path part that we are looking at here, need to be set. The final two parts, domain and secure, are for more advanced use beyond the scope of a beginners' book, but we'll look at them briefly just for completeness.
You're probably used to the idea of there being directories on your hard drive. Rather than storing everything on our computer in one place on the hard drive, we instead divide it into these directories. For example, we might keep our word processing files in My Documents, our image files in My Images, and so on. We probably also subdivide our directories, so under My Images we might have subdirectories called My Family and My Holiday.
Well, web servers use the same principle. Rather than the whole website being in one web directory, it's common and indeed sensible to divide a website into various different directories. For example, if we visit the Wrox website at www.wrox.com, and then click one of the book categories, we'll find that the path to the page navigated to is now www.wrox.com/Books/.
This is all very interesting, but why is this relevant to cookies?
The problem is that cookies are specific not only to a particular web domain, such as www.wrox.com, but also to a particular path on that domain. For example, if a page in www.wrox.com/Books/ sets a cookie, then only pages in that directory or its subdirectories will be able to read and change the cookie. If a page in www.wrox.com/academic/ tried to read the cookie, it would fail. Why are cookies restricted like this?
Take the common example of free web space. A lot of companies on the web allow us to sign up for free web space. Usually everyone who signs up for this web space has a website at the same domain. For example, Bob's website might be at www.freespace.com/members/bob/. Belinda might have her website at www.freespace.com/members/belinda. If cookies could be retrieved and changed regardless of the path, then any cookies set on Bob's website could be viewed by Belinda and vice versa. This is clearly something neither of them would be happy about. Not only is there a security problem, but if, unknown to each other, they both have a cookie named MyHotCookie, there would be problems with each of them setting and retrieving the same cookie. When we think how many users a free web space provider often has, we can see that there is potential for chaos.
Okay, so now we know that cookies are specific to a certain path, but what if we want to view our cookies from two different paths on our server? Say for example we have an online store at www.mywebsite.com/mystore/ but we subdivide the store into subdirectories, such as /Books and /Games. Now let's imagine that our checkout is in the directory www.mywebsite.com/mystore/ Checkout. Any cookies set in the /Books and /Games directories won't be visible to each other or pages in the /Checkout directory. To get around this we can either set cookies only in the /mystore directory, since these can be read by that directory and any of its subdirectories, or we can use the path part of the cookie string to specify that the path of the cookie is /mystore even if it's being set in the /Games or /Books or /Checkout subdirectories.
For example, we could do this like so:
document.cookie = "UserName=Paul;expires=Tue, 28 Dec 2010 00:00:00" + ";path=/mystore;";
Now, even if the cookie is set by a page in the directory /Books, it will still be accessible to files in the /mystore directory and its subdirectories, such as /Checkout and /Games.
If we want to specify that the cookie is available to all subdirectories of the domain it is set in, we can specify a path of the root directory using the / character.
Now, the cookie will be available to all directories on the domain it is set from. If the website is just one of many at that domain, it's best not to do this because everyone else will also have access to our cookie information.
It's important to note that while Windows computers don't have case-sensitive directory names, many other operating systems do. For example, if our website is on a Unix- or Linux-based server, the path property will be case sensitive.
The fourth part of the cookie string is the domain. An example of a domain is wrox.com or pawilton.com. Like the path part of the cookie string, the domain part is optional and it's unlikely that you'll find yourself using it very often.
By default, cookies are available only to pages in the domain they were set in. For example, if we have our first website running on a server with the domain MyPersonalWebSite.MyDomain.Com and we have a second website running under MyBusinessWebSite.MyDomain.Com, a cookie set in one website will not be available to pages accessed using the other domain name, and vice versa. Most of the time this is exactly what we want, but if it is not, we can use the domain part of the cookie string to specify that a cookie is available to all subdomains of the specified domain. For example, the following sets a cookie that can be shared across both subdomains:
document.cookie = "UserName=Paul;expires=Tue, 28 Dec 2010 00:00:00;path=/" + ";domain=MyDomain.Com;";
Note that the domain must be the same: We can't share www.SomeoneElsesDomain.com with www.MyDomain.com.
The final part of the cookie string is the secure part. This is simply a Boolean value; if it's set to true the cookie will only be sent to a web sever that tries to retrieve it using a secure channel. The default value, which is false, means the cookie will always be sent, regardless of the security. This is only applicable where we have set up a server with SSL (Secure Sockets Layer).
|
|
JavaScript Validator
JavaScript Editor