Subjects ->
Computer Networks ->
Lectures ->
Lecture #20
Lecture 20: Web Commerce #1
CGIs and Web Commerce
FORM-based Web pages and CGI are the key enabling technologies for
Web Commerce.
Web sites can sell either tangible goods (merchandise)
or content. Important issues include:
- Marketing
- getting customers to your site, and
presenting and selling your product, ultimately convincing them to
order something.
- Ordering
- typically managed by a
shopping cart application, see next
slide.
- Order Processing
- check order, verify payment,
address, etc. Possibly send customer email confirmation.
- Order Fulfilment
- packaging, shipping, etc
Shopping Carts
A shopping cart application is a CGI-based set of Web
pages which allow a user to browse items, and add them to their "cart"
at the click of a button.
The user can (usually) examine and modify the contents of their "cart".
When they are ready, they move to a final "commit" page, where they
finalise the ordering process, with (for example) a credit card number,
shipping address and an email contact address.
Image used with permission of
Raven
Records, the "THE ULTIMATE IN REISSUES".
State Maintenance -- Hidden Fields
A shopping cart application is more difficult to implement than it may
seem. Because the HTTP protocol is stateless, a Web
server regards every connection as entirely new, with no relationship
to any previous or future connections.
However, a shopping cart
application requires persistent state maintenance -
each HTML page sent contains information derived from earlier pages.
A hidden field within a form is the simplest way to
maintain state. A hidden field is like any other FORM entity; it is
simply not displayed by the browser. It can be inspected using, for
example, the "View Source" option of the browser, where it will look
something like:
<input type="hidden" name="sid" value="XYZZY">
.
- When an initial connection is made to the server, the HTML page
which is sent contains the indentifying hidden field value within
the page FORM.
- A subsequent HTTP CGI request issued by the browser to this server
will thus also contain the hidden field.
- The CGI which processes the FORM at the server can return the same
hidden field to the browser. The hidden field value thus acts as a
"session identifier" between the shopping cart application and the
browser.
State Maintenance -- Cookies
Whilst hidden fields are a simple technique for state maintenance, they
are not a general solution. A cookie is a small piece
of information which a server can store "within" a Web browser. For
example, the following segment of Perl CGI code sends a cookie:
print "Content-type: text/html", "\n";
print "Set-cookie: MeLove=Cookie%20Monster", "\n\n"
print "<HTML">;.....rest of Web page
This stores "MeLove=Cookie Monster
" with the
browser. The following Perl CGI code reads a cookie:
print "Cookie:", $ENV{'HTTP_COOKIE'}, "\n";
Each cookie can have several extra attributes:
Name=Value
- this
attribute is compulsory, and more than one is allowed. Both
"
Name
" and
"Value
" can be any ASCII
string.
expires=DATE
- defines the
lifetime of the cookie. Default is the current browser session.
domain=DOMAIN
- an Internet
domain name to which this cookie may be sent.
path=PATH
- defines the
subset of URLs within a domain for which this cookie is valid and
may be sent.
Security and Cookies
Cookies have caused a great deal of debate. The following are some of
the issues:
- Some users don't like the idea that a Web server can write to their
hard disk, however innocuously. In fact, there is no (real) danger
in accepting cookies - for example, cookies cannot spread
viruses.
- Users worry that cookies might be used to send secret information
about them to a server. In fact, the cookie which is returned is
exactly the same as that which was sent.
- Users are concerned that other Web servers might find out
information about you by reading cookies set by different servers.
In fact, browsers follow very strict rules to ensure that cookies
are only returned to the server (and/or specific CGI program) which
originally sent them.
- Users worry that Web servers can track their "click-through"
behaviour using cookies. In fact, this is true, and is a potential
privacy issue.
- Browsers allow the user to turn off acceptance of cookies, and some
users do this. Therefore a shopping cart application cannot rely on
the existence of cookies to maintain state information.
Some sites with useful information on cookies include:
State Maintenance and Sessions
Most modern Web Commerce sites use the concept of a Web
session -- a series of Web requests and responses
linked together by a state variable called a session
identifier. A first visit to the sites "home page" creates a
new session, and the HTTP response is associated with a new session
identifier, or SID. All subsequent transactions are labelled with the
same SID.
- The session identifier is commonly generated as some combination of the
current time, the IP address of the client, or maybe just as a random
number.
- Session management can be rather messy on the server, since
information must be maintained about all "current" sessions, and
decisions must be made as to the deletion of "expired" sessions.
- The SID must (obviously) be passed back and forward between the
server and the browser on every transaction. Modern practice is to
use a "belt-and-braces" approach here, with the information
duplicated in hidden fields, cookies (which may be disabled in the
browser) and also in dynamically-generated Extra Path
Information URLs. For example, the CDnow page on your lecturer's browser at
this instant has the URL (some sections deleted to fit):
http://www.cdnow.com/cgi-bin/mserver/SID=1391321707
It's obvious that every URL in the page has to have exactly the
same information, and a quick "View Source" verfies this. At this
particular site, the same information is also sent as a cookie,
although hidden fields are (apparently) not used.
CGI and Database Integration
A shopping cart application almost certainly needs a "back end"
database to store product and inventory information, as well as
transaction records of purchases, etc. There are several options:
- For "small scale" operations, this can be done using simple text
files. Many Unix utilities are designed to manipulate data stored
in files of this type, and Perl is very well suited to the job.
These utilities can be "glued" together to build quite advanced
systems.
- If the task is sufficiently large or complex, there are many "low
end" cheap, or free, database solutions. In this case, the CGI
program interfaces to the database, normally by sending SQL
queries. The standard Perl database access module is
DBI::, which interfaces to virtually all DMBSs in
a standardises way. The current defacto Web DBMS is probably
mySQL, but lots of others are available.
- Proprietory databases such as Microsoft "Access" can be used in
conjunction with an associated proprietory Web server such as IIS.
Perl's CBI:: can also talk to most of these.
- At the "big end" of town, companies like Oracle are positioning
themselves as major Web database vendors.
Java (and JavaScript) Applications in E.Commerce
The Java and Javascript languages execute programs or applets in the
browser. However, since not all browsers will necessarily have this
functionality, it's doubtful whether a Web Commerce system should
utilise them -- certainly they shouldn't depend on
them. Nevertheless, they can be useful:
- Interactivity can, if well done, make a page more attractive to
some users.
- A Java applet can communicate with the server using other protocols
than HTTP. This opens up a range of possibilties.
- An applet (or a Javascript program) can be used to check FORM
information for consistency and completeness before allowing it to
be sent to the server. For example:
- check if all important TEXT boxes have been filled in.
- perform limited syntax check of email addresses, phone
numbers, addresses, etc.
- check credit card numbers for correctness (prefix and
checksum)
The tutorial for this lecture is
Tutorial #20.
[Previous Lecture]
[Lecture Index]
[Next Lecture]
Copyright © 2003 by
Philip Scott,
La Trobe University.