This is an intriguing idea. The only thing I'm leery on is what happens to HTTP_REFERER when the user clicks a back button? If you encode a valid HTTP_REFERER into the URL, and the user clicks back, the HTTP_REFERER in the URL probably wouldn't match the HTTP_REFERER in %ENV hash.

Am I missing something here with this system?

When the user clicks on the back button, most browsers that I know of do not attempt to reget the page, but use the version from the browser's cache, which means they'll see the page as if they never moved from it in the first place. But you do have to consider the few oddball browsers, as well as some that send HTTP_REFERERs when the URL is entered manually or from bookmarks, as well as ones that don't send HTTP referers at all.

As was discussed in the CB, you've got to decide for yourself how much inconvience do you want to give the customer for a possibility of a malicious cracker to modify the cart prior to them entering the secure part of the site, vs whatever secure that you lose by running the storefront without cookies or SSL or other Apache-based features. Since the worst that the cracker can appear to do is run up a lot of items on the shopping list, you simple need to make sure that in the secure area, the user has the ability to review the shopping list and delete items he/she does not want at that time.

If you do that, then all you need simply for handling the 'refering' of a product to the second user is a time out on the sessionid of 5 or so minutes, with the sessionid being refreshed with a new time out every time it is successfully accessed.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain