in reply to using session ids
A session id should not be much more than a key used to get state information kept on the server side. Common ways to implement this are:
- Pretty standard, supported by most (current?) browsers although disliked by some users. Tend to remain in the computer, so this may be an issue with users in public access terminals.
- Hidden (or not so) variables
- Usually complicate your design and may get in the way. A variant, using visible variables with the GET method can be problematic if the user bookmarks the page (the variable will stay with the link forever).
- Mangled URIs
- Similar to exposed GET HTTP variables, this technique consists in mangling the URI to keep there the session id.
(I may have left some other way outside of this node). Keep in mind that it should be as hard as possible/practical to guess the value of another user's session id. In your case, this may lead to leaked user information or tampered carts.
If you configure it properly with mod_usertrack, Apache will supply a good enough cookie to your users, which you may use for referencing the data you keep on the server side. This of course, requires users to accept your cookies.
As implied by my above statements, never use the session id to directly store the information you want to preserve. By its nature, the session id comes and goes from the client to the server and back. Not following this advice, may lead to compromised customer information (the session info you kept in the id) or even succesful attacks against your web application, as an attacker may forge the contents of the session id. Sorry if you already knew this or if I sound alarmist, but in my line of work, I find this mistake over and over again.
-lem, but some call me fokat