I would suggest maintaining state either with a session ID and all the data on the server or an encrypted param hash (using say Crypt::CBC and Crypt::Blowfish) - stored in a single 'hidden' field. Cookies are not secure. Nor can you rely on them being available so a hidden field holding either a session ID MD5 hash or an encrypted param hash is the way to go IMHO. You also need to have some sort of timeout mechanism to expire sessions so cached data rapidly becomes useless. In some applications of mine I will reset the timeout to say 10 minutes each time the client hits the server - no activity for 10 minutes and a new login is required (old state data is then restored). This avoids a malicious user being able to steal a session from cache very easily. When forcing a re-login you need to loose the old session data if the login username/pass is not for the expected session.

One major issue is how you want to handle BACK. You can use no cache but users expect to be able to use the back button. For this reason I favour maintaining state with a well encrypted param hash embedded in the page rather than a session id with data on the server. This way the state relating to that page is always accurate. If you use a session ID and data on the server if a user goes back the web page and the session data are no longer in sync. It is simply not possible to consider all the possible permutations that can occur when users go back but you avoid the issue if the state data is *securely* embedded in the page.

It has been said again and again but you should never trust the client (even with encrypted data) and always validate prices on the server side before confirming the order.

If you don't keep credit card numbers you are far less likely to have them hacked from you. I prefer sites that always ask to the number again. If using an encrypted param hash in the pages I would just store a reference to the credit card number embedded on the page with the actual number kept on the server. Perhaps just paranoia but this ensures the CC number only ever makes one pass through the ether when the client submits it.

For added security there is no particularly good reason not to run the whole cart on an https server, including the initial login. Also to protect from know plaintext attacks on your encryption you can double/triple encrypt the param hash which makes it a little harder and more time consuming. If the cart is going to be offered to others I always automate the setting of the salt/key for the encryption when the thing is setup - if you do not do this and rely on the installer to make the required change your encryption is trivial to break in the case where the default salt is used. People will forget and you will get blamed! The encryption has to be two way and with the salt/key the decode is a no brainer.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print