I'm setting up SMart prior to going live. It appears to me that the "unique" ID for each shoppers cart is their IP address?

I'm concerned that this will be problematic with

a) users who receive different (ie dynamically allocated) IP addresses between visits, but more significantly:

b) a look at my user log suggests that various cache servers and the like as listed by IP address. Is it safe to assume that the IP address belongs to the user/shopper, and not to some intermediate device?

Regards

Stewart

-- Stewart Hutton (webmaster@circustuff.co.uk), January 09, 1998

Answers

Hi Stewart,

Good point. I did some research on your question and found that your suspicions were right.

If someone (user/shopper) accessed the shopping cart from a network through an intermediate device, all users/shoppers from that network could potentially have the same IP address. This would be especially true of sites that went through a firewall, which are most businesses. That means, each user from that network would share the same cart. Opps!

Thank you! I immediately coded a work around for my implementation of the script. I simply generate a unique id for each cart (instead of using the IP). I then pass this ID on each subsequent call to the script.

Here is the a code snippet I used to generate a unique ID: srand (time|$$); $cartid = int(rand(10000000)); $cartid .= "-$$"; $reffile = "$tmpdir$delim$store-$cartid.cart";

So, instead of calling the get_host routine, I now call this to get a cart id. It was just a little tedious to insure that the cart id was passed on each call.

Good luck and thanks again,

Tom

-- Tom (tom@haddonfield.com), January 11, 1998.

Tom's solution to the script is not workable at all. There is no good way to pass unique ID's to the script unless you're using a totally encapsulated environment, like ASP.

Basically using the IP is the only way, without using cookies, which is a whole new headache. General preception of cookies, and the same problems with firewalls, etc, render them non-effective.

-- Barry Robison (brobison@rcinet.com), January 11, 1998.

Your dead wrong Barry!

Not only will my solution work, I can prove it.

Don't get your feelings hurt because your method of using an IP address sucks.

I either pass the ID with the command ie. Smart.cgi?ID=$cartid or in a hidden field on my forms. If the ID does not exist (it was not passed to the script), I simply create a new one. Works great!

Don't tell me it doesn't work, I'm doing it!!!!

I would suggest that everyone (including you Barry) read "CGI for Commerce" by Solena Sol. This is exactly how he does it! Maybe someone should inform him, his shopping script doesn't work. There are other Shopping scripts that work the same. Yes, they do pass unique IDs with Perl!

I would also suggest that everyone goto www.netcart.com. They will setup and configure a shopping cart for you ( intended for bigger businesses ). Their demo works the same way. Could it be that everyone else is wrong and Barry is right?

Certainly it is possible to create a unique id (isn't it?). And, it is a fundamental part of CGI scripting to pass variables (isn't it?)

So, stop being so sensitive and admit you are wrong.

Let's see if you are man enough to let this update stay.

-- Tom (tom@haddonfield.com), January 11, 1998.

Ok, maybe I need to clarify my position somewhat. There is no good way of using unique IDs, passed from page to page, in a flexible system, like S-Mart. Take this scenario for example. A shop has custom made shopping pages (not using the DB). A customer goes to page A and orders an item. The script dosn't see a Unique ID, so it gives the user one. The customer continues browsing, goes to page B. Orders a item. There is no unique ID on that page, therefore the script does not recognize the two orders as beloning to one customer.

Also take for example the way headers and footers work. Instead of using simple HTML pages, these would have to be embedded in the script, so that links to Review, Buy , etc could have the unique ID attached to the URLs.

I hope you see where I am coming from, I never said it wasn't possible, I said there was no good way to do it. Maybe other systems look better to you, and if so please go use them. BTW over 50 sites use S-Mart, selling thousands of items a day, so the system does work.

-- Barry Robison (brobison@rcinet.com), January 11, 1998.

Barry,

First, you have a great shopping cart and I do thank you for sharing it with everyone. I have made some changes to it to suit my needs, but that should be expected.

I continue to monitor this discussion group to get help and hopefully help others.

When a fundamental problem arises, we should all keep an open mind to possible solutions.

Your scenario is not valid. If the cart id is passed from page A to page B, the items will be added to the same cart.

Here is an excerpt from Solena Sol's book....

"passing along the location of the cart ($cartid) as either hidden form data or URL encoded information, depending on whether the customer uses a Submit button or a hyperlink to navigate through a store. As long as the customer follows the path provided by the application, she will never lose her cart."

The note about the customer following the path provided is a key point. But, I should mention that your script would not work at all if the customer did not follow the path provided. The 'command=' , 'pos=' or 'type=', if not passed properly would stop the script in it's tracks. So, adding 'id=' would be the same. For example, if 'command=listitems' was not passed, the customer would never see the items.

I am sure the 50 sites that use S-Mart work great, but there is a possibility that they would not work properly all the time using the IP method.

Please forgive my outburst, but it infuriates me when someone tells me that what I said was wrong when I'm doing it and it works great. There are other updates in this forum that point to other problems of using the IP for the cart name. Like, If person A connected to an ISP and received an IP address, then added items to a cart and disconnected from the ISP. Then, person B connected to the same ISP and the ISP assigned the same IP address to person B that person A once had. And if this person was to access the shopping cart, they would see the items that person A left in the cart. I know this sounds like a way out scenario, but it is likely to happen.

Thanks again and keep up the good work, but please keep an open mind.

Tom

-- Tom (tom@haddonfield.com), January 11, 1998.

Sorry, I forgot to mention in my last update. That, one of the first things I changed with S-Mart was the static links in the footer html file. I added them to the script itself, this way I only show the checkout link if there are items in the cart. I also don't show the checkout link if order.html is being viewed.

Barry, you are right, this would also have to be changed in other peoples implementation of the scripts in order to pass unique ids, but I believe that is all. It is worth it.

Tom

-- Tom (tom@haddonfield.com), January 11, 1998.

the passing of unique ID's in the query string, seems to be a better a better idea, it solves the facit of people using proxys and whatnot, but also, the name/ip problem when using a secure server. i believe secure servers only see an IP when using a REMOTE_HOST call while the non-secure server will possibly pass on a name for the client instead of its IP. thus the shoppers file is unattainable for the prog. so if people don't know how to add the routine that adds an ID to the query(like me), they could just search and replace REMOTE_HOST with REMOTE_ADDR and that will take care of half of the problems, and give the 10 million zanny AOL users access to a secure purchase, at least i think it should. this would also help those with the server switching the id. so if someone wants to post the routine that can be added to the script and query, or i will just figure it out. if this doesn't make sense, i might agree....

-- justme (nomailforme@here.thanks), January 12, 1998.

I've looked into this further, understand S-MART more, so here's my summary:

There is a potential issue with using IP address as I suspected. The problem will only arise (I think)if you have 2 shoppers at the same time (or within the same cart expiry period) who are coming through the same firewall/proxy/whatever. Risk will vary with your visitor numbers. HOWEVER - the big advantage of this approach is that it allows the vistor to detour into any area of your site (directed or otherwise) - or even off site - and return to an intact cart.

Unique IDs remove the risk identified above, BUT must be passed around with the user WHEREVER they go. As soon as they browse outwith your "managed" - ie unique-ID-passing - environment, the unique ID and cart are lost, and will not be there when the visitor returns.

In short, with unique IDs, any pages which you may wish to refer shoppers to will have to include code to pass the unique ID. The S-MART way allows you to refer to html product pages etc without coding them.

On balance, I'm happy with the S-MART way - and I think it's a good cart overall. I think I can have it up and running faster than any others I've looked at - including code modifications for our shipping methods etc.

Stewart

-- Stewart Hutton (webmaster@circustuff.co.uk), January 12, 1998.

umm... i guess i'll give my two cents....

why would someone add items to a cart and then wander around your site? and who cares if they have to re-add them?

the unique id sounds the best to me. seems the abilty to wander with the ip way isn't worth the risk....

-- Ron Richards (rrichards@hotmail.com), January 12, 1998.

I don't think replacing REMOTE_HOST with REMOTE_ADDR fixes the problem with AOL users. I was wondering if anyone else could confirm this?

I think the idea of generating Unique cart IDs is the best idea. I was wondering if anyone would be willing to help me do this to my script?

Thanks, JS

-- Jeremy Smith (pancakepan@usa.net), November 10, 1998.

I have implemented cookies with my cart. If you are interested to know more, email me at patrickccf@hotmail.com.

--
God bless!

-- Patrick Chan (patrickccf@hotmail.com), March 20, 2000.