iTP Secure WebServer System Administrator's Guide (Version 7.0)

Administering Session Identifiers for Anonymous
Sessions
iTP Secure WebServer System Administrator’s Guide—523346-012
11-2
Tracking
Tracking
Conventional Web technology makes tracking a single user through a Web site difficult.
The HTTP protocol treats every request for a Web resource as a separate,
independent connection. For example, if a user requests a Web page that contains four
graphics files, the server interprets the request as five independent requests—one for
the HTML file and one each for the four graphics files. The server receives little
information to indicate that all five requests originated from the same user. The server
does receive the IP address of the requesting browser, but this can be misleading
because many users might have the same perceived IP address when proxy servers
are being used.
For content providers, this situation makes analyzing how users are accessing their
Web pages difficult. Although the number of accesses (hits) to each file can be
counted, it is hard to know how many of those hits were made by the same user. In
addition, there is no way to track a single individual’s access pattern—that is, which
URLs the user requested and in what order.
Ticketing identifies a user for a specified duration so user activities can be tracked
throughout a single Web session or across multiple sessions.
Ticketing and Tracking Example
To understand how tracking works, consider this:
A company called Universal Technology, Inc., has put all its marketing literature on the
Web. Universal Technology does not want to limit access to these files, but it does
want to know how many individuals are looking at each file. It also wants to know
which links are accessed most frequently.
Universal Technology obtains this information by configuring its iTP Secure WebServer
to support anonymous ticketing, a type of ticketing that provides tracking information
but no authentication or authorization.
When the Universal Technology WebServer receives a request for a resource, it
generates a ticket for the user and redirects the user’s browser to the same content,
but with the ticket inserted in the URL. The Web client resends the request, this time
with the inserted ticket.
The iTP Secure WebServer detects the ticket, validates it to check that it has not been
tampered with and has not expired, and then returns the requested resource (as
shown in Figure 11-1 on page 11-3). The request, along with the ticket, is recorded in
the server’s log file.