Re: Session tracking

Lou's notion of servers issuing cookies can be made to work for session
tracking, but may not work across user sessions. Problems will occur on 
shared machines that do not require logins, i.e. most PC/Macs. So, your 
server issues me a cookie, I use it, leave; later, another user using
the same client and machine visits your site.  While you may be able to 
demarcated sessions, you do not have the same user, who now may have 
inherited a shopping basket, or some other statefull user based 
representation entertained by the server.  Additionally, since cookies need
to be unique, some server side mutex will be necessary, which could turn into
a bottle neck for active servers. Some solutions might include:

   * As Brian proposed, have the cookies cleared upon browser restarts,
     though this conflicts with Lou's goal of having "the client save state
     information within the client."

   * Another would be for start ups of multiuser PC/Mac browsers to ask 
     for some non-informative identification string. I personally 
     do not endorse this method, though it does move in the direction 
     that David Chom posits of multiple, user-defined alias - one can
     be who one wants to be without anyone knowing it's me.

   * Another solution is to restructure one's approach to the problem,
     seeing as multiple goals are trying to be accomplished via one
     mechanism.

Specifically, if seems that we want to accomplish the following three things:

   1) identify sessions from server logs (esp. from firewalled domains)
   2) enable unique, but changeable user identifications
   3) freely pass data as first class objects between client/servers 

The first issue is quite doable without any modifications to existing
protocols (I wrote code a year and half ago, before the referrer field, 
that accomplishes this with a high degree of certainty that the paths 
inferred are the paths actually traveled. See "WebViz: A Tool for WWW 
Access Log Visualization" from the First WWW Conference Proceedings).

The second issue is digital signatures.  Use of Netscape's ip/uid/+* 
based signature, which btw is not very well conceived :(, or some other 
scheme can produce the desired results.  No doubt, better, more robust
schemes exist and will be adopted in the future.  No modification
to HTTP headers are required since From: is already specified.  Note
that use of signatures solves the first issue.

The third issue is first class data passing.  Java is a very strong initial 
starting point.  Multi-part encapsulated MIME for clients and servers could
also be made to fit this problem.  I personally would prefer a separate
protocol as to facilitate modularization and interoperability.  The data
object could be used to contain shopping basket updates and checkouts,
as well as correctly process multi-server shopping malls.

Jim.

Received on Friday, 21 April 1995 13:14:52 UTC