Overview of Cookies
Cookies are small bits of textual information that a Web server
sends to a browser and that the browser returns unchanged when
visiting the same Web site or domain later. By having the server
read information it sent the client previously, the site can
provide visitors with a number of conveniences:
- Identifying a user during an e-commerce session. Many
on-line stores use a "shopping cart" metaphor in which the user
selects an item, adds it to his shopping cart, then continues
shopping. Since the HTTP connection is closed after each page is
sent, when the user selects a new item for his cart, how does the
store know that he is the same user that put the previous item in
his cart? Cookies are a good way of accomplishing this. In fact,
this is so useful that servlets have an API specifically for
this, and servlet authors don't need to manipulate cookies
directly to make use of it. This is discussed in the tutorial
section on Session Tracking.
- Avoiding username and password. Many large sites
require you to register in order to use their services, but it is
inconvenient to remember the username and password. Cookies are a
good alternative for low-security sites. When a user registers, a
cookie is sent with a unique user ID. When the client reconnects
at a later date, the user ID is returned, the server looks it up,
determines it belongs to a registered user, and doesn't require
an explicit username and password.
- Customizing a site. Many "portal" sites let you
customize the look of the main page. They use cookies to remember
what you wanted, so that you get that result initially next time.
I'll give an example like this later in this section of the
tutorial.
- Focusing advertising. The search engines charge their
customers much more for displaying "directed" ads than "random"
ads. That is, if you do a search on "Java Servlets", a search
site can charge much more for an ad for a servlet development
environment than an ad for an on-line travel agent. On the other
hand, if the search had been "Bali Hotels", the situation would
be reversed. The problem is that they have to show a random ad
when you first arrive and haven't yet performed a search, as well
as when you search on something that doesn't match any ad
categories. Cookies let them remember "Oh, that's the person who
was searching for such and such previously" and display an
appropriate (read "high priced") ad instead of a random (read
"cheap") one.
Now, providing convenience to the user and added value to the
site owner is the purpose behind cookies. And despite much
misinformation, cookies are not a serious security threat.
Cookies are never interpreted or executed in any way, and thus
can't be used to insert viruses or attack your system in any way.
Furthermore, since browsers generally only accept 20 cookies per
site and 300 cookies total, and each cookie is limited to 4KB,
cookies cannot be used to fill up someone's disk or launch other
denial of service attacks. However, even though they don't
present a serious security threat, they can preseent a
significant threat to privacy. First, some people don't
like the fact that search engines can remember that they're the
person that usually does searches on such and such a topic. For
example, they might search for job openings or health data, and
don't want some banner ad tipping off their coworkers next time
they do a search. Even worse, two search engines could share data
on a user by both loading small images off a third party site,
where that third party uses cookies and shares the data with both
search engines. (Netscape, however, provides a nice feature that
lets you refuse cookies from sites other than that to which you
connected, but without disabling cookies altogether.) This trick
can even be exploited via email if you use an HTML-enabled email
reader that "supports" cookies, as Outlook Express does. Thus,
people could send you email that loads images, attach cookies to
those images, then later identify you (email address and all)
when you went to their site.
Or, a site that ought to have much higher security standards
might let users skip user name and passwords via cookies. For
example, some of the big on-line bookstores use cookies to
remember users, and let you order without reentering much of your
personal information. However, they don't actually display the
full credit card number, and only let you send books to an
address that was entered when you did enter the credit card in
full or use the username and password. As a result, someone using
the person's computer (or stealing their cookie file) could do no
more harm than sending a big book order to the credit card
owner's address, where it could be refused. However, smaller
companies might not be so careful, and access to someone's
computer or cookie file could result in loss of valuable personal
information. Even worse, incompetent sites might embed credit
card or other sensitive information directly in the cookies
themselves, rather than using innocuous identifiers which are
only linked to real users on the server.
The point of all this is twofold. First, due to real and
perceived privacy problems, some users turn off cookies. So, even
when you use cookies to give added value to a site, your site
shouldn't depend on them. Second, as the author of
servlets that use cookies, you should be careful not to trust
cookies for particularly sensitive information, since this would
open the user up to risks if somebody accessed their computer or
cookie files.
NEXT
This tutorial is now available as a book: Core Servlets and JavaServer Pages by Marty Hall, published by Sun Microsystems Press.
Read all about it at CoreServlets.com
Server-Side Web Applications using Java Servlets versions 2.1/2.2 and JavaServer Pages (JSP) version 1.0: A Tutorial
© 1999-2000 Marty Hall.
All source code freely available for unrestricted use.
Created for work in the Research and Technology Development Center of the Johns Hopkins University Applied Physics Lab, for courses in the Johns Hopkins Part-Time MS Program in Computer Science, and for various industry seminars and on-site Java short courses.
Please note that this is a first draft of the tutorial, so please send corrections, comments, and suggestions to me at hall@apl.jhu.edu.
Reprinted with permission from the author. Click here to visit the original version
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
