Oh wise and beneficent Elder Brethren and Sistren, of your wisdom tell me:

Without getting into a religious debate over the value or not-value of cookies, what would be the best way of saving a session ID without them?

Here's the issue, see: I have a situation where we want our band's online catalog wants to live at the band's site, but the actual (secure) ordering service lives elsenet. The way the admin of the ordering service has set it up is that a person has to sign in, and their session ID gets preserved (in a db store, I think) through all their navigations through the site until they logout again, thereby making sure that their "shopping cart" effectively follows them around. Aforementioned admin doesn't want to use cookies to save state because he (not to say numerous of his friends and colleagues) stands on the anti-cookie side of the aforementioned debate.

But I want to be able to have our customers order from our catalog without necessarily having to have (hm, that was redundant) a pre-existing login on the other site.

BBQ wrote, in the "Who Needs Shopping Carts?" thread:

A real Shopping Cart should be a cookie-free, stateless and still be persistent.

Wonderful! I thought. Just what I need! But specific details of how to set this up (with examples for boneheaded neophyte me) were not forthcoming thereafter. I did read pretty deeply in that thread, and others like it, and it looks, based on what I could glean there, like my offsite ordering guy is on the right track with his login idea. Clearly, he could automatically set a session ID and then pass the ID back and forth in hidden inputs. So I guess the real question is, how specifically do we set up our forms to receive and keep and transmit this number again? This is all across an https connection, by the way.

I have faith that in Perl (and probably even more specifically in CGI.pm) lieth the answer. How may our respective goals be achieved?

Thanks for your attention,

     - Muse