Re: Session tracking

On Wed, 10 May 1995, Jared Rhine wrote:

> [The topic was session-tracking proposals, esp the proposed "Session-ID"
> header.]

I have just joined this mailing list, so I have only seen one message in
this thread, but I have a few comments.

User-tracking is much better than session-tracking.  You can track a session
by tracking a user, and additionally you can keep user specific information
between sessions.

Magic cookies are an over-complicated idea that could also be much better
handled by user-tracking.  The shopping basket or any other user specific
info should be kept at the server side.  The problem of abandoned baskets
could be handled essentially as it is in the supermarket, by timing out
inactive baskets and then restocking the items.

>   JP> 1) identify sessions (esp. from firewalled domains)
>   JP> [...]
>   JP> If the 'From:' field is widely used, you'd have what you wanted(1).
> 
> No, I don't believe so, because one of the stated requirements is that we be
> able to identify sessions without compromising the identity of the user.

I have posted a suggestion for how to handle user-tracking in several
newsgroups, where it was ignored.  Here is the suggestion again:

There is no reasonable way to uniquely identify users from a CGI script. 
HTTP_FROM (which contains the user's e-mail address) would work, but it
generally isn't supported because people do not want their e-mail address
distributed without their permission.  So I would like to propose a new
environment variable called HTTP_FROM_CRYPT which would contain the user's
e-mail address encrypted (in a consistent way).  (For example, the Unix
crypt() function could be used with a standard "salt" value.) This would
provide a safe unique identifier for each user.

Received on Wednesday, 17 May 1995 18:29:21 UTC