> Only a suggestion, not a correction or bug. What do you think of the > idea of adding a "Created DATETIME NOT NULL," field in the session_sku > table so that basket housekeeping could be managed by date in addition > to session?
Hmmm.... are you suggesting that baskets should expire independently? I'm struggling to come up with a reason for doing this. Maybe you're boosting session lifetime but you want baskets to expire before then. Or are you simply trying to avoid getting the list of valid sessions before cleaning baskets? > I also think it would be a good idea to store Name, number, and exp date > related to credit card as hash data in addition to storing the last 4 > for display purposes. That way no one can ever use the info and if the > hash is generated with a unique key added to the user password which is > itself a one way hash, then only the person with the key can unlock the > data if necessary. I've done that in the past and I feel it was > practically foolproof. Just a thought I think this was a subject of the mailing list a couple years ago. My thoughts on this are that if someone hacks into your database server, encrypting the credit cards offers no resistance. They simply add code to save the credit cards in another place before it's saved in the database. I suppose it does protect historical credit card numbers if you encrypt them with a public key. Just make sure the private key is not on the same machine. It may be just as good to delete the credit card info as soon as it's not needed anymore. If you validating with CyberSource or CyberCash, you may not need to store it in the database ever. If you're saving invoices for batching to a fulfillment house, then you can delete (or truncate) the credit cards after you send a batch. Leon _______________________________________________ FreeTrade-dev mailing list [EMAIL PROTECTED] http://share.whichever.com/mailman/listinfo/freetrade-dev
