Each cookie is given a lifetime; when the period expires, the browser deletes the cookie. Time periods can be set literally (i.e., a specific date/time), duration (number of seconds from the time the cookie is set), or simply to exist only during the current browser session (the cookie is deleted once the browser exits).
As described earlier, getting the timeout value correct is critical. Make it too brief, and and the cookie will be removed before the user has finished her business. When used for a shopping basket or other ‘visit’ based purpose, setting too large a value can mean that the information is retained for too long and starts to interfere.
Of course, you can specifically delete and existing cookie by re-supplying the cookie data and specifying a very short lifetime.
Domain or Site Limitations
The browser will send a cookie only to a Web site that matches the URL of the requested object. When you create a cookie, you must specify the hostname or domain in which the cookie is valid. If you do not specify it, the browser will set the value for you. That information is then used to validate when the cookie is used.
For example, if a cookie is configured to be valid within the mcslp.com domain, then only Web servers within the mcslp.com domain will be supplied with the cookie. This simple mechanism prevents another Web server from accessing the data in your cookie.
To set a domain, prefix the domain with a period — for example, for a cookie to be supplied to any Web server within the mcslp.com domain, you would specify the domain as .mcslp.com. To set it only for a specific Web server you would use the full name, for example www.mcslp.com. Using a specific name in this example would prevent cookie data from being shared between www.mcslp.com and maps.mcslp.com. Browsers will not allow a cookie to be set within a top-level domain — you cannot set a cookie for .com, for example.
A path specification further limits when a browser sends a cookie to a Web site. Most cookies set a path of ‘/’, which means the cookie will be supplied to all areas of a Web site, but you can be more restrictive about the path where the cookie is valid. For example, using ‘/cgi-bin/’ as a cookie path specification limits the browser to supplying the cookie only to objects within this directory. When accessing a file from ‘/images’, the browser would not supply the cookie to the Web servers.
Cookies are Web server driven, but client browser bound. That is, the only way to create a cookie is for the Web server to supply the cookie specification and contents, and the only way for the Web server to receive the cookie is for the browser to send it. The server does not request the cookie; it is automatically sent with each request.
Modifying the URL
The URL method is more complex, and it relies on having a completely dynamically generated Web site because we must always supply, and process, the session information for each page or object accessed. This complicates development but obviously has the benefit of not requiring users to set cookies on their browsers.
The URL method is comparatively less secure. Because the session ID is exchanged in plain text as part of the URL request, the information can be seen. Viewing a user’s basket can then be a case of modifying the URL with the alternative session ID. Without further checking or verification, anybody could use anybody else’s session. Sessions used in this fashion will also require manual management to ensure the session expires.
There is no easy way to resolve the security issue; you can embed verification information (such as the host IP address into the session data held on the server), which is then verified, but since an IP address is not unique to a machine it offers little real protection. You can also require secondary verification (perhaps requesting a password) when viewing sensitive information. There are, however, obvious limitations.