Re: [PHP] Creating an OO Shopping Cart
Richard Lynch [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Contact the bank with which you already HAVE a merchant account for your point-of-sale credit card swiper thingies. You're already working with them, paying them good money for essentially the same services. Different Service Almost-for-sure they would be happy to provide you with on-line merchant account for not too much more than you already pay them. Not necessarily. In shop POS services are not generally provided by the banks either. They are usually provided by a seperate entity (which may be *owned* by a bank or several banks [aka Streamline in the UK] and do not necessarily provide online clearance as well [Streamline don't for example]. There are, however, a number of organisations that do online cc clearance and will work in partnership with most of the offline clearing houses. Your existing offline clearing-house/bank will usually provide you with a list of these, although, they generally *won't* recommend any particular one. If not, I'm guessing that their competitors WILL do a package deal of on-line and POS merchant account, for the same price you're paying now, to lure you away from your current bank. Firstly, they are not competitors - they are business partners with your POS provider and provide a service in conjunction with your existing provider. They will not replace it - for the simple reason, these online clearance companies are not banks - they are online payment *clearance* companies - the actual payments are still conducted through your existing bank accounts. SNIP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
On Wed, May 3, 2006 5:15 pm, Chris W. Parker wrote: Steve mailto:[EMAIL PROTECTED] on Friday, April 21, 2006 5:58 PM said: So everyone's aware, I have NO intention of storing credit card #'s. I don't see why anyone needs to.. especially after reading Richard's past posts in the archive. Perhaps if you don't use a merchant account and process all your cards in house instead?? We keep the cc numbers stored until the card has * But if we did get a lot of orders I would reconsider even the current implementation and decided whether or not it was suitable. In fact I'm going to be redoing the entire thing coming up soon so this is good. Contact the bank with which you already HAVE a merchant account for your point-of-sale credit card swiper thingies. You're already working with them, paying them good money for essentially the same services. Almost-for-sure they would be happy to provide you with on-line merchant account for not too much more than you already pay them. If not, I'm guessing that their competitors WILL do a package deal of on-line and POS merchant account, for the same price you're paying now, to lure you away from your current bank. If you're re-doing it anyway, you might as well do it right. :-) Because, frankly, the way you are doing it now is just not an acceptable risk... Who has access to the computer which is used to get the admin data? How long do you think it would take a disgruntled employee or even a customer to add a key-stroke monitor application to that computer, and come back a week later to steal your login? Game Over. Is that computer on the Internet? Even the BEST virus-protection software is reactive rather than proactive for the most part. How long before some virus infects it and that virus snoops on your login? Game Over. You're using SSL for all the admin pages, right? If not, Game Over. How do you transfer data from that screen to the POS device? Is it only in the admin user head, with the computer right next to the POS, or does he write them down and/or print them out? If the CC#s go onto paper, it's Game Over. I don't care if you shred the paper after -- what about the hold sideways pencil rubbing on the next sheet trick? Obviously you gave this some thought and are minimizing your risk to what you think is an acceptable level. But if those 5 current numbers do leak out, I do believe you are required by law to inform ALL your customers that you leaked CC numbers. Are you prepared to send out that mail? If you're really prepared for this, sit down and write that mail, and have it on file, as a contingency plan. You'll need it in an awful big hurry if you ever do need it. If you can't bring yourself to write that letter as a contingency then you're not really prepared to accept your current Risk. :-) Believe me, I know where you're coming from. I *ALMOST* did the same thing you are doing for a tiny store that already has POS, because I had the owner on my back every day for months wanting this, and they didn't want to spend $$$ on the on-line merchant account. Thank [deity] others on this list educated me about all the ways this can go wrong. I've maybe hit 10% in this email. I started describing these things to the store owner. After the blood came back to his face, he realized just how badly he did NOT want me to do this the wrong way. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
Richard Lynch mailto:[EMAIL PROTECTED] on Thursday, May 04, 2006 2:06 AM said: Contact the bank with which you already HAVE a merchant account for your point-of-sale credit card swiper thingies. Already have the info in front of me. :) If you're re-doing it anyway, you might as well do it right. :-) I totally agree. Thanks Richard! Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
Steve mailto:[EMAIL PROTECTED] on Friday, April 21, 2006 5:58 PM said: So everyone's aware, I have NO intention of storing credit card #'s. I don't see why anyone needs to.. especially after reading Richard's past posts in the archive. Perhaps if you don't use a merchant account and process all your cards in house instead?? We keep the cc numbers stored until the card has been run at which time the site attendant clicks an icon in the administration side that does two things (1) sends an email giving some shipping details to the customer, (2) changes the cc number from 4111--- to ---. We don't get a lot of orders* so at worst if the db were stolen there'd be possibly 5-10 cc numbers in there. Some people (possibly Richard) would have a heart attack to hear something like that but we've decided that it's a reasonable risk. This is the implementation we decided to take with the cart I wrote myself. It's better than the old version which never removed or protected the cards in any way. (It was an out-of-the-box solution.) I would be extremely interested to learn about the flaws in our current implementation so that I can continue to improve it (short of using an online cc processor). Thanks, Chris. * But if we did get a lot of orders I would reconsider even the current implementation and decided whether or not it was suitable. In fact I'm going to be redoing the entire thing coming up soon so this is good. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
On May 3, 2006, at 5:15 PM, Chris W. Parker wrote: We don't get a lot of orders* so at worst if the db were stolen there'd be possibly 5-10 cc numbers in there. Some people (possibly Richard) would have a heart attack to hear something like that but we've decided that it's a reasonable risk. Ahh!! *thud* Count me in the heart attack group. So would it be a reasonable risk if it was *your* cc # that was stolen? And do your customers *know* that you're handling their sensitive info in this way? I.E. is there a big red lettered notice that they see before they hit submit? Would *you* be willing to have your cc sitting in the db at all times? I'd think that would be a reasonable request. Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
Edward Vermillion mailto:[EMAIL PROTECTED] on Wednesday, May 03, 2006 4:15 PM said: Ahh!! *thud* Count me in the heart attack group. So would it be a reasonable risk if it was *your* cc # that was stolen? And do your customers *know* that you're handling their sensitive info in this way? I.E. is there a big red lettered notice that they see before they hit submit? Would *you* be willing to have your cc sitting in the db at all times? I'd think that would be a reasonable request. Overall I think you bring up a good point but I don't think our method is unreasonable. There's risk involved in everything and I do in fact think it is a reasonable risk, even for my cc. I bought something oversees once and my cc was used to buy jewelry in another country. That was a number of years ago and I've since made numerous other purchases on the internet (without any problems). Those purchases were made on both well known and mompop shops around the world. I'm definitely open to suggestions on how we can minimize our customers' risk. Even moving to an online cc processor if need be. In fact I wouldn't be surprised if our current merchant account company has the ability to process cards online. But until that kind of system can be implemented what suggestions do you have for me right now? Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
Chris W. Parker wrote: I'm definitely open to suggestions on how we can minimize our customers' risk At least run GPG on the data immediately, keep the private key somewhere other than on the server, and decrypt only for the moment its needed. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
Nicolas Verhaeghe wrote: [snip] I'm creating my own Object Oriented PHP Shopping Cart. Okaaay. ... To answer our friend, he seems to have to learn to develop simple applications before starting building something as complex as a shopping cart. Not only complex, but also sensitive, because the end of the process is to handle credit card numbers, and I would not trust a beginner to handle that type of information. get ready for a 'Richard Lynching' with regard to the CC statement. ;-) unless your name is VISA (or somethin gin a similar vein) you don't ever touch a creditcard number - ever, ever, ever. this saves you getting sued, your house being sold from underneath and consequently your wife leaving you. Richard Lynch has given very detailed responses to the issues of handling credit cards on numerous occasions on this list - do yourself a favor and search the archives and read what he had to say - his is sound advice imho. Functions that perform operations such as manipulating objects (a shopping cart is an object, after all, so are the items, and the client's information) are simply performed at the top and the functions which display the changes or prompts the buyer for operations are shown at the bottom, it's all very straight and linear. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
Nicolas Verhaeghe wrote: [snip] I'm creating my own Object Oriented PHP Shopping Cart. Okaaay. ... To answer our friend, he seems to have to learn to develop simple applications before starting building something as complex as a shopping cart. Not only complex, but also sensitive, because the end of the process is to handle credit card numbers, and I would not trust a beginner to handle that type of information. get ready for a 'Richard Lynching' with regard to the CC statement. ;-) unless your name is VISA (or somethin gin a similar vein) you don't ever touch a creditcard number - ever, ever, ever. this saves you getting sued, your house being sold from underneath and consequently your wife leaving you. Richard Lynch has given very detailed responses to the issues of handling credit cards on numerous occasions on this list - do yourself a favor and search the archives and read what he had to say - his is sound advice imho. Functions that perform operations such as manipulating objects (a shopping cart is an object, after all, so are the items, and the client's information) are simply performed at the top and the functions which display the changes or prompts the buyer for operations are shown at the bottom, it's all very straight and linear. -- Actually you do not touch a credit card when your name is Visa. Credit card authorization is done with credit card processors and of course you have to touch credit card numbers in order to communicate with those. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
On Thu, April 20, 2006 11:24 pm, Steve wrote: Yes, there is a TON of source code, and Yes, most of it is very very very badly-written, and Yes, that's because they started typing just like you are now instead of actually figuring all this [bleep] out in advance. :-) Thank you for taking the time to respond and assist me. Do you have any specific shopping carts that you would recommend I take a look at? Any that ARE well written. Donning my flame-retardant underwear... No. They all suck. There is no decent security-concious well-designed Open Source / Free PHP Shopping Cart available to date. So examine all the big-name ones and see where they went wrong. Let the flames begin. Or not, as I'm betting not one of you can say something I haven't heard yet... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
Richard Lynch wrote: Or not, as I'm betting not one of you can say something I haven't heard yet... When I close my eyes I see images of donkeys with unicorn-like horns jumping over the moon with ponies on their backs. To be perfectly honest it does worry me sometimes. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
On Fri, April 21, 2006 5:09 am, Jochem Maas wrote: Nicolas Verhaeghe wrote: get ready for a 'Richard Lynching' with regard to the CC statement. ;-) Oh, let's do the children's version today. :-) You know that game Hot Potato? Yeah? Good. A CC # is just like the Hot Potato in that game. You do NOT want it in your hands a nano-second longer than it has to be. [subtle shift to adult computer design version] You certainly don't want to put it into anything like permanent storage like your database or on your hard drive! You want to hand it off to your Merchant Account API ASAP!, and you want to ERASE that CC number from your memory banks *FOREVER* as totally wiped out gone forever as you can. If you could, you'd like to apply a Stun Gun right to that portion of RAM and just WASTE the 16 bytes into a burned-out shell of useless nano-circuitry... Okay, that's a little extreme (and impossible) but it is not that far off from the desired philosophical goal. Every beginner on the planet seems to make this mistake, at least in their initial design. I know quite a few have made it all the way past development, implementation, review, launch, and long-term usage! Some guys are shaking their heads in denial on this, but I swear to god, I have seen it. I am not making this [bleep] up. Credit card numbers have been sitting for YEARS in some boutique home-rolled shopping cart system MySQL database with the oh-so-clever username/password of nobody/nobody or www/www Hell, I'll even posit that SOME have managed to configure MySQL with % access for the hostname -- Though I personally have never seen that. I can only hope that my continued (and freely-admitted annoying) rant on this topic stops at least ONE beginner from making this mistake. Cuz god knows somebody on this list was kind enough to stop ME a decade ago when I was about to do it, and it's foolish, incredibly risky, and carries penalties beyond comprehension. Thanks. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
-Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 2:18 PM To: Steve Cc: php-general@lists.php.net; Richard Lynch Subject: Re: [PHP] Creating an OO Shopping Cart On Thu, April 20, 2006 11:24 pm, Steve wrote: Yes, there is a TON of source code, and Yes, most of it is very very very badly-written, and Yes, that's because they started typing just like you are now instead of actually figuring all this [bleep] out in advance. :-) Thank you for taking the time to respond and assist me. Do you have any specific shopping carts that you would recommend I take a look at? Any that ARE well written. Donning my flame-retardant underwear... No. They all suck. There is no decent security-concious well-designed Open Source / Free PHP Shopping Cart available to date. So examine all the big-name ones and see where they went wrong. Let the flames begin. Or not, as I'm betting not one of you can say something I haven't heard yet... -- No flaming from me, I would add fuel to the fire. First of all, unless you are really a newbie, do not ever use a shopping cart solution which hackers could download to analyze the flaws. Second, like you, I think they all suck. Either they have too many bells and whistles, or are poorly coded, or have includes calling includes calling includes. The best example of this is OsCommerce, because it has the three flaws listed above. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
[snip] Some guys are shaking their heads in denial on this, but I swear to god, I have seen it. I am not making this [bleep] up. Credit card numbers have been sitting for YEARS in some boutique home-rolled shopping cart system MySQL database with the oh-so-clever username/password of nobody/nobody or www/www [/snip] I know what you are talking about, I have seen that type of tables with literally thousands of CC numbers collected over the years, along with name on the card and expiry, of course. As a programmer it is your duty to report this to your client and to keep track, because if one day someone resells this list, you could be liable. Unless, of course, you are a Soprano. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
On Fri, 2006-04-21 at 17:59, Nicolas Verhaeghe wrote: [snip] Some guys are shaking their heads in denial on this, but I swear to god, I have seen it. I am not making this [bleep] up. Credit card numbers have been sitting for YEARS in some boutique home-rolled shopping cart system MySQL database with the oh-so-clever username/password of nobody/nobody or www/www [/snip] I know what you are talking about, I have seen that type of tables with literally thousands of CC numbers collected over the years, along with name on the card and expiry, of course. As a programmer it is your duty to report this to your client and to keep track, because if one day someone resells this list, you could be liable. *hahah* I've seen it too, in the database, and then the guy also had a debug log that wrote the data to the log file. Bigger problem was that the log file was xwrxwrxwr right smack in request land with no access restrictions :/ He never turned the debug log off. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
Richard... you're amazing. Good on you for just standing up there, stating your position and defending it like there's no tomorrow! So everyone's aware, I have NO intention of storing credit card #'s. I don't see why anyone needs to.. especially after reading Richard's past posts in the archive. Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
At 05:14 PM 4/20/2006, Steve wrote:
I'm creating my own Object Oriented PHP Shopping Cart.
I'm confused about the best way to call the functions of the class
given the static nature of the web.
For example, if I have a function addItem($code), how will this be
called from the catalog or product description pages where the BUY buttons are?
On the product description page (say for product ABC213), there will
be a BUY button, but when the button is clicked, obviously I cannot
immediately call $cart-addItem('ABC213'). So how is this done?
Steve,
One way to preserve your cart object between page requests is to keep
it serialized in the session.
When the PHP program wakes up:
// begin session processing
session_start();
// if the cart already exists...
if (isset($_SESSION[cart])
{
// read the cart from the session
$oCart = unserialize($_SESSION[cart]);
}else{
// or create it
$oCart = new CartObject();
}
Before the PHP script ends:
// save the cart to the session
$_SESSION[cart] = serialize($oCart);
In the body of the script, you'll use $_GET and/or $_POST arrays to
feed user input into the cart object, and echo functions to write
each new page in response.
Does this help clarify, or am I stating only what you already know?
Paul
_
Refs:
http://php.net/session
http://php.net/session_start
http://php.net/serialize
http://php.net/unserialize
http://php.net/isset
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
On Thu, April 20, 2006 7:14 pm, Steve wrote:
I'm creating my own Object Oriented PHP Shopping Cart.
Okaaay.
You're doing this just for fun and education, right?
Cuz, seriously, it's about 100 X harder than you think to get a bunch
of details you've never even thought about correct.
And there are about 100 shopping carts already out there.
I'm confused about the best way to call the functions of the class
given
the static nature of the web.
I think you mean stateless...?
For example, if I have a function addItem($code), how will this be
called from the catalog or product description pages where the BUY
buttons are?
On the product description page (say for product ABC213), there will
be
a BUY button, but when the button is clicked, obviously I cannot
immediately call $cart-addItem('ABC213'). So how is this done?
The BUY button should have HTML elements which will pass in 'ABC213'
via POST or GET data.
Your script, at a minimum, would then do:
?php
session_start(); //this is how you make HTTP sort of stateful.
$item = $_REQUEST['item']; //assuming your HTML BUY button has
name=item
require 'Cart.php'; //Load in the OO class you are writing.
$cart = new Cart(); //Make an instance of your Cart.
$cart-addItem($item);
?
So, actually, if you get all the OTHER details right, there isn't much
more to it than what you typed...
I thought of making the BUY button link to the cart itself, like so,
but
doesn't this mitigate the whole point of designing with classes:
a href=Cart.php?action=addcode=ABC123goto=viewcartBUY/a
The Cart.php would then redirect the user to view the contents of the
shopping cart.
There is no reason why you need to go directly to Cart.php -- Just
require the Cart.php script into the product/catalog pages.
Do that at the tip-top, and you can include all kinds of nifty info on
the product/catalog pages like:
You have 10 items in your cart totaling $192.37
Do you have any tips, or are there any resources that may help me
think
more clearly about this?
You should read the source to several other shopping carts.
Yes, there is a TON of source code, and Yes, most of it is very very
very badly-written, and Yes, that's because they started typing just
like you are now instead of actually figuring all this [bleep] out in
advance. :-)
My aim is to build a Cart that is very flexible that I can use in many
situations in the future.
I'm pretty sure that was everybody's aim for every shopping cart ever
built. Nobody wants to build the damn thing a second time. :-)
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
The $_SESSION array is already being serialized before saving it to the
session datafile. You'll only have to:
$_SESSION['cart'] = $cart;
And before session_start():
require_once 'fileWhereClassIsDefined';
.
.
.
session_start();
If the class isn't defined before serialization (session start) an instance
of stdclass is created.
You should define the magic member functions __sleep and __wake if you
need to reopen any resource needed for your object (resources, as in opened
files, opened mysql connectios, mysql queries, ARE NOT serialized)
2006/4/20, Paul Novitski [EMAIL PROTECTED]:
At 05:14 PM 4/20/2006, Steve wrote:
I'm creating my own Object Oriented PHP Shopping Cart.
I'm confused about the best way to call the functions of the class
given the static nature of the web.
For example, if I have a function addItem($code), how will this be
called from the catalog or product description pages where the BUY
buttons are?
On the product description page (say for product ABC213), there will
be a BUY button, but when the button is clicked, obviously I cannot
immediately call $cart-addItem('ABC213'). So how is this done?
Steve,
One way to preserve your cart object between page requests is to keep
it serialized in the session.
When the PHP program wakes up:
// begin session processing
session_start();
// if the cart already exists...
if (isset($_SESSION[cart])
{
// read the cart from the session
$oCart = unserialize($_SESSION[cart]);
}else{
// or create it
$oCart = new CartObject();
}
Before the PHP script ends:
// save the cart to the session
$_SESSION[cart] = serialize($oCart);
In the body of the script, you'll use $_GET and/or $_POST arrays to
feed user input into the cart object, and echo functions to write
each new page in response.
Does this help clarify, or am I stating only what you already know?
Paul
_
Refs:
http://php.net/session
http://php.net/session_start
http://php.net/serialize
http://php.net/unserialize
http://php.net/isset
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating an OO Shopping Cart
Richard Lynch wrote: Yes, there is a TON of source code, and Yes, most of it is very very very badly-written, and Yes, that's because they started typing just like you are now instead of actually figuring all this [bleep] out in advance. :-) Hi Richard Thank you for taking the time to respond and assist me. Do you have any specific shopping carts that you would recommend I take a look at? Any that ARE well written. Thanks Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Creating an OO Shopping Cart
[snip] I'm creating my own Object Oriented PHP Shopping Cart. Okaaay. You're doing this just for fun and education, right? Cuz, seriously, it's about 100 X harder than you think to get a bunch of details you've never even thought about correct. And there are about 100 shopping carts already out there. [/snip] [slightly OT] I too created my own shopping cart because I realized that by the time I managed to adapt somebody else's solution to what I need, I would be done programming my own shopping cart. Reinventing the wheel? Somewhat. It's about making a wheel that fits the vehicle that you build. Just like in motorcycle building. You can either buy an engine and a chassis and build around or you can make your own motorcycle from scratch. It depends on what you want to do in the end. Be a simple integrator or propose products that are deeply adapted to your clients' needs. I also have never found a shopping cart that I liked, and always thought I could do better, but that's me. [/slightly OT] To answer our friend, he seems to have to learn to develop simple applications before starting building something as complex as a shopping cart. Not only complex, but also sensitive, because the end of the process is to handle credit card numbers, and I would not trust a beginner to handle that type of information. Functions that perform operations such as manipulating objects (a shopping cart is an object, after all, so are the items, and the client's information) are simply performed at the top and the functions which display the changes or prompts the buyer for operations are shown at the bottom, it's all very straight and linear. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
