Databases and Cookies - Looking at your cookies
(Page 3 of 13 )
Although it is not of direct concern to us to see the cookies (remember, the browser will set and serve cookies to ASP pages), they can be viewed easily. If you are using Microsoft Internet Explorer on Windows 98, you can look in C:\Windows\Cookies where you will see small text files holding each cookie; the name of the file is the user name and the domain name. In Netscape you can see them in C:\program files\netscape\users\ \cookies.txt. Note that, as a security measure, when a cookie file is opened the browser considers the cookie tampered with and thus nonexistent.
There are many ways that cookies are lost or ruined Cookies suffer from a multitude of abuses, and thus can never be relied upon to be there when needed. Any of the following events can render a cookie unusable or inappropriate:
- Replacing or reformatting the hard drive
- Expiration of the cookie
- Movement of a visitor to a different PC
- Use of a PC by a different user
- Preference settings on a browser that prevent the setting of cookies
- Use of a firewall that prevents setting or reading cookies
- Switching between browser softwares
- Deletion or corruption of the cookie files
It is important to design your site to handle the possible absence of a cookie, not only from first-time visitors, but from returning browsers that have lost or rendered their cookies inappropriate.
Cookies are frequently used with a database Cookies can hold one datum or many. A minimalist approach is to store in the cookie only an identifier, which is then used to look up all other information in a database, using ASP-ADO. The large-cookie approach is to store all of the information that will be needed in the cookie itself. Generally, an intermediate tack is taken, with the most commonly and urgently needed information in the cookie; particularly the user's ID number, and less frequently used or secure information held in the database for look-up.
However, doing a look-up has time and server load costs, and so if there are one or two fundamental pieces of data we may want to include them in the cookie. For example, storing display preferences in a cookie would allow the building of pages with larger type for aging baby-boomers. Likewise, some basics on the visitor's area of interest would allow information of greatest appeal to the visitor to be immediately displayed. Another useful piece of data, if available, is the visitor's zip code, which allows geographic specialization.
Factors in favor of keeping data in cookies:
- The data is crucial to improving page loading speed
- The data is used frequently, for example building every page
- The information is not confidential
Factors in favor of keeping data in a database for look-up:
- Data is only used infrequently in the site
- You want to minimize the impact of the cookie on the user
- Cookies are likely to be unavailable, e.g. destroyed, unaccepted, or inapplicable
- The data needs to be kept secure
WebMaster strategies for visitors in a state of cookie-denial I mention several times in this chapter that if you use cookies you will have to address the possibility that a visitor does not accept cookies or has lost a cookie that you set. There are several ways to handle this problem. The first is to require that visitors sign in each time they visit the site. A second is to check if they have your cookie, and if not shunt them to a page which asks them to re-register and re-set their cookie.
A third option is to offer a set of pages that are cookie-less. This suite of pages would be weaker in features and more limited in scope than those for cookie-acceptors. At various points on these pages you could offer the chance for the visitor to change their mind about accepting a cookie.
Fourth, there is a product called Cookie Munger, which can emulate most aspects of cookies for cookie-deniers. More information is available by searching the Microsoft site for "Cookie Munger." A good paper resides, at the time of this publication, at http://msdn.microsoft.com/workshop/server/toolbox/cookie.asp. The Munger searches both outgoing and incoming data streams, and if it sees cookie-like activity it excises the information and performs the same read or write task, but instead by adding extensions to the URL. Design drawbacks include performance hits that can become significant, cumbersome URLs that get book-marked, and other problems. Furthermore, in some cases it just doesn't work.
Lastly, in case you are thinking of avoiding cookies by using ASP sessions variables, remember that sessions require cookies.
Cookies as an instrument of the Devil Cookies have a bad reputation and thus you may encounter resistance from customers. The facts, though, are quite simple. First, it is impossible to set a cookie without the approval of the user. Second, cookies are generally only available to the domain that set them. Third, cookies do not have the ability to gather and report information about other activities of the user back to a web site.
Having said the above, there is also a level of responsibility required on the part of the programmer. Secure information such as a credit card number should not be stored in a cookie. Although it would be difficult for another web site to obtain the information, a hacker could find the cookie on the hard drive and derive the sensitive information.
 This is from Beginning ASP Databases by Kauffman, Spencer, and Willis (Apress, ISBN 1590592492). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Examples of Using Cookies >>
More ASP.NET Articles
More By Apress Publishing
