> Sure - I believe in magic, depending on your definition of it. I KNOW
> there's a 4th method, because I've seen it work. There is an e-commerce
web
> site which uses an outside cart programmed in CGI (Perl?). The original
web
> site passes no identifying marks such as the session ID through the URL or
> through the form's submit button to add an item to the cart. I know,
because
> I designed and created the web site.
>
> However, when the visitors hit the submit button, they are taken to
another
> program/website containing their shopping basket filled with their items.
I
> have figured out that it relies somewhat on the IP address, but not
> completely, because I have tested it behind the firewall and the other
> computer behind the firewall with me does not share the same basket.
>
> Once I am at that screen (viewing the contents of my cart on the program),
> there are other links which contain a session ID of sorts carried via the
> URL. The thing that is driving my head crazy is how they identify the user
> in the first place to create the links with the session ID.
>
> I accidentally caught them during testing or something and got a variable
on
> the URL line. (I substituted the domain name - it's not really cart.com)
>
http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848
> E
>
> cartidnum seems to be:
> $IP-Address + "T" + Unix-TimeStamp + "R" + Unknown number + "E"
>
> By the way, the session only seems to active until the browser completely
> shuts down. Any ideas?
Sure sounds like a cookie to me. What makes you think it isn't one? Or
else they just don't care who you are until you hit the shopping cart, and
then they keep your identity with URLs and hidden form fields.
- Perrin
