Hi everyone, thank you for all your comments so far on this topic. They are very helpful.
@anru - really I'm wanting to know about every aspect that would affect an eCommerce system - security, obscurity, etc. - yes I mean if the cart is stored in session, database cleanup wouldn't be required. @Andre - in our case the SilverStripe eCommerce cart is saved to the database (as an uncompleted order) before redirecting to the payment gateway. Afterwards the order can be checked to see if the price matches the payment, or perhaps a hash could be verified as Dan suggests. This checking isn't yet implemented though. Jeremy On Jul 20, 9:37 pm, Dan Khan <[email protected]> wrote: > 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]
