HTTP Cookies are a useful mechanism for tracking a client through a Web site. Cookies are a small state token that is stored in the client's browser that allows your server side Web application to keep track of the user on the other end. The cookie is stored on the client and sent as part of every request made against the Web server, so the server side application has access to this cookie. This is very useful for applications, like online stores that must track users so that the application can keep track of for example items dropped into a shopping cart on a per user basis.

Cookie Persistance

By default Cookies persist for the duration of the browser session - when the user shuts down the browser the cookie is released and goes away. You can also create persistant cookies which can have an expiration date in the future or with Web Connection simply 'NEVER'. When you set a cookie for future expiration shutting down the browser will cause the cookie to be written into a special cookie file on the client machine storing the state until the cookie expires. Next time the user visits the Web site that generated the cookie, the cookie will be sent to that server again. It's important to understand Cookies are always specific to the Web server they were created on. In other words, if Yahoo gave you a Cookie, Excite can't use or access that cookie in any way. Cookies are stamped with their target domain and virtual directory and can only be retrieved by the matching domain/virtual. However, on your local machine, cookies are stored in files so somebody spying around your machine can find the cookies and figure out where you hang out. You may not want your boss knowing about your porn site visits <s>... Overall the hype and paranoia about cookie security are unfounded. People are worried about being 'tracked' but cookies are just a vehicle that can be performed by other mechanisms just as easily. Cookies just make it easier for site developers to do their job and in many cases state keeping is simply required. You simply cannot create a shopping site without somehow tracking the user!

What should be in a Cookie

Cookies are typically used to maintain user state through a site. Ideally the actual cookie should be no more than a simple ID - this is mainly so users don't get paranoid about the information kept about them. You can use this key to store the real information that you need to keep track of in a database. Real information typically will consist of user information like customer name, address, order information and current order process such as item in a shopping cart. In all these cases the Cookie serves as the Id that identifies the user and based on that the current information of his visit.

Who can use a Cookie

HTTP Cookies require a browser that supports cookies and a willing user that will accept the cookie - browsers do have the capability to refuse cookies either with or without user prompting. By default most modern browsers accept cookies but options in these browsers let users turn off cookies, or prompt for acceptance. Because Cookies can be blocked and because they have gotten a bad name in the press some users are paranoid of cookies and refuse to take them so consider this in your application.

Cookie Alternatives

In lieu of Cookies other mechanisms can be used to implement Cookie like behavior, but they tend to be a lot more work. The most common approach used by most Web sites is known as 'license plating' which basically provides key information identifying a user as part of every URL used in the Web site. You may have seen these kinds of URLS: http://www.shopme.com/item.asp?sku=SKU1212&Id=312312kl12klj123 The ID in this case identifies the user. While the above works, it's required that every link in the site pass this ID forward. If one link doesn't pass it forward the ID and the user's context or state is lost. Thus using license plates are more work to implement and difficult to debug once an ID is lost. Furthermore license plates are passed on the URL and can thus be spoofed. It's absolutely vital that IDs are unique and then IDs are not generated in a predictable manner - sequential numbering would be a really bad call. With the right ID it might be possible to highjack somebody's shopping cart. Jump to Implementing HTTP Cookies