I'd normally hash the cart contents with a secret key before going to checkout, then reverify the hash after checkout to ensure no mid-checkout tampering.
Cheers, -Dan On 20 July 2010 12:12, Nick Jenkin <[email protected]> wrote: > Here is what we do: > * Store all cart items in a table > * Once user starts the checkout process the contents of their cart is > transferred to a session, this is to prevent mid-checkout cart > manipulation > * Disable the cart items in table after checkout > > Don't worry about performance/speed, if you are of any decent size you > are going to be running a) multiple db servers b) multiple web > servers. Typically load balancers don't remember connections (I know > some can) so it's possible for them to redirect users to multiple web > servers, so your sessions are going to have to be centralised > somewhere (e.g.db or memcache). I would argue memcache isn't ideal for > sessions unless you can guarantee the cache won't fill up (e.g. huge > amounts of standby RAM), otherwise your going to get some very > confused users. > > > On Mon, Jul 19, 2010 at 7:34 PM, aaron v1.4.10 > <[email protected]> wrote: >> Personally I prefer it all in a database. It's far easier to manage, >> you're probably going to need to query the database anyway to get >> information such cart contents, recommended items, storing cart >> contents for registered users, totals and loading up the newer prices >> and stock level if a customer returns to finish the order over a few >> sessions over several days. Also makes it easier to crunch all that >> data about what people are looking at buying etc... >> >> Just make sure you include a clean up routine to drop carts older then >> say a month and extend your sessions to several days. I usually shop >> for things over several days. >> >> If you are worried about database performance, then storing a cart >> summary in a file based database cache may give you some increase >> performance where the database is getting hit hard and disk use it >> low. I don't know anything about Redis, memcached or APC, but could be >> useful for storing those common/seldom change summary info. >> >> Security, once a hacker has found an exploit they have your data, both >> sessions and databases are stored on disk. Phpmyadmin adds a slight >> side door perhaps, maybe. Storing it all in a cookie is very unsecure, >> dont do that. >> >> -- >> NZ PHP Users Group: http://groups.google.com/group/nzphpug >> To post, send email to [email protected] >> To unsubscribe, send email to >> [email protected] > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
