CGIs and 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

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.

State Maintenance - Hidden Fields

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.

• 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

print "Content-type: text/html", "\n";
print "Set-cookie: MeLove=Cookie%20Monster", "\n\n"
print ";.....rest of Web page

print "Cookie:", $ENV{'HTTP_COOKIE'}, "\n";

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

• 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 "cllick-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:

• http://home.netscape.com/newsref/std/cookie_spec.html
• http://www.illuminatus.com/cookie.fcgi
• http://www.etrust.org/
• http://catless.ncl.ac.uk/Risks/18.19.html#subj3
• http://catless.ncl.ac.uk/Risks/18.20.html#subj11

CGI and Database Integration

• 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 programs must interface to the database, probably using SQL. For example, the defacto Web database is a href="fixthis">mSQL, and there are several freebie Perl modules designed to interface to this product.
• Proprietory databases such as Microsoft "Access" can be used in conjunction with an associated proprietory Web server such as IIS.
• At the "big end" of town, companies like Oracle are positioning themselves as major Web database vendors.

Java (and JavaScript) Applications in E.Commerce

• Interactivity can, if well done, make a page more attractive to some viewers.
• 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)

Web Transaction Security

Site Certificates

issued by a trusted service, these digital signature-based certificates are sent by a server to prove that it is who it purports to be; that is, that it really is (eg) http://amazon.com and not http://hackers-r-us.com masquerading as them.

Secure Sockets Layer

SSL is a public key encryption system. A server can publish its public key in association with its site certificate. The public key can then be used to communicate securely. You can tell if a server uses SSL for a document if the URL starts with https://... Also, if you're using Netscape, the little "key" icon will appear in one piece. On the other hand, encryption is computationally heavy, so it's typically not used for normal Web pages.

There's an excellent "white paper" on this stuff at:

http://search.netscape.com/newsref/ref/128bit.html