There's lots of ways to setup a shopping cart like you described, but the general idea is you want your CGI to allow a customer to order an item, surf around, order some more, then (eventually) check out. In order to do this the CGI needs a unique way to track who's who. Cookies are one way to do that, because wherever a customer goes, so goes their cookie. Without cookies your CGI will have to compute and assign a unique identifier to anyone who orders anything, and then pass that identifier into every page the person sees on your website.

This gives you a couple of challenges. First, the identifier must be pretty much guaranteed to be unique (otherwise your CGI will get confused as to who's who.) One way of doing this is to calculate an id off of (say) the current UNIX time, plus maybe the first 3 letters of their first name plus the first 3 letters of their last name. For example, if I order something my unique ID might be "123456789GARBLA". It'd be pretty unlikely that anyone would hit your shopping cart at exactly the same time with exactly the same combination of letters. Bang. Unique identifier.

After you have an identifier, you'll need to have some way to store the current (incomplete) order somewhere so that your CGI can pick it up where it left off. You can do this by creating a temp file named the same name as the unique id, or you can create a DB entry with the unique id as the row identifier. Either way you'll need to account for the build-up of unfinished orders by cleaning up any temp files/rows after say 6 hours if they don't consumate their order.

Lastly you'll need to pass this unique identifier to all the customer's pages. Best way to do this probably by modifying the URL of all their future pages like "http://www.coolband.com/index.html?id=123456789GEBBLA" or something. Index.html still gets displayed, but the next time they surf back to the order page (or checkout page) your CGI will know who they are, and then, by accessing their pending order on the server (via temp file or row) your CGI will know what they've ordered up till then.

You mentioned that your site uses SSL... if so you probably won't have to worry about encrypting your unique id. Reason is that until they check out the only thing recorded is their current order ("T-shirt: 1, Coffee Mug: 5") which isn't exactly top-secret info. You'll only get their credit card information as the last step in the checkout process, and since you're using SSL that part of the transaction will be secure.

Of course, the easy way around figuring out how to do all this is to simply bag the whole idea of a shopping cart... when a customer wants to order something, just send 'em to a secure order page and have them order everything at once. Saves lots on the overhead... you're going to spend a lot of time ironing out the details of letting them "shop/surf/shop/surf" like the big catalog merchants do. If you don't have a huge catalog, it'll probably be easier to stick to a simple order page.

Didn't mean to be so long-winded... :-D

Gary Blackburn
Trained Killer