Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Any tips on writing a shopping cart?

by mt2k (Hermit)
on Dec 22, 2002 at 19:27 UTC ( #221760=note: print w/replies, xml ) Need Help??


in reply to Any tips on writing a shopping cart?

As already mentioned by someone who posted as Anonymous Monk, merlyn wrote an article, along with an example script (like always), on the best (and only) way cookies should be used (if they need to be used at all). Here's the article, which contains good advice and suggestions. Obey what you read here :)

That being said, definitely don't trust anything you get from the client. The cookie should only indicate which browser (notice the word 'browser', not 'user', since the same user should be able to have multiple sessions open with your web applications) is accessing the script. All data should be contained within a database, including prices (do NOT put prices in hidden html fields), all contact info, and anything else you can possibly think of. Also, make sure you expire the session from the database after a reasonable amount of inactivity. What is 'reasonable' is up to you, but don't leave inactive sessions around for too long, unless you want these picked up by somebody other than the original session creater :)

More from a view of making things work the way you expect, rather than security (but security can always hold a place in these things), is making sure the data you are being forced to receive from the client is the data you are expecting. What if a user tells your script they want 0.5 pairs of shoes? Your script had better insure that the only data it is accepting for quantities is a whole integer: no alpha characters, no decimal, etc etc. If you don't, your web app will charge your shopper the price of one shoe rather than the pair of them. And are you willing to ship out one shoe? :) Even worse, what do you do when someone tells your app "I want to purchase -10 pairs of shoes."? Will your app reject this value or will you be offering a refund for the amount of 10 pairs of shoes?

Are there any non-obvious security-related tips (i.e. besides "use taint checks well" and "encrypt credit card numbers" ...
Um... encrypting credit card numbers? No. Just don't do it. Don't even save the shopper's credit card number in your database, I don't care how safe you think you've encrypted it. If you can decrypt it to the true credit card number, then so can someone else who might find their way into your database. Will this require shoppers to re-enter their credit card number every time they buy something? Yes. Will it make them feel more secure? Perhaps. Will it make you feel better and more responsible when you find out your database has been hacked into by someone else? Definitely!

-------------------------------------
eval reverse@{[lreP
=>q{ tsuJ\{qq},' rehtonA'
,q{\}rekcaH },' tnirp']}[1+1+
1,1-1,1+1,1*1,(1+1)*(1+1)];
-------------------------------------
  • Comment on Re: Any tips on writing a shopping cart?

Replies are listed 'Best First'.
Re: Re: Any tips on writing a shopping cart?
by BrentDax (Hermit) on Dec 22, 2002 at 19:59 UTC
    As already mentioned by someone who posted as Anonymous Monk, merlyn wrote an article, along with an example script (like always), on the best (and only) way cookies should be used (if they need to be used at all). Here's the article, which contains good advice and suggestions. Obey what you read here :)
    Good article. Thanks, Merlyn! In this case, I'm using hidden form fields instead of cookies, cause I hate cookies and they're hard to handle.
    That being said, definitely don't trust anything you get from the client...All data should be contained within a database, including prices (do NOT put prices in hidden html fields), all contact info, and anything else you can possibly think of.
    Prices are in a Perl data structure that's refreshed every time one of the constituent scripts is accessed. Everything else is in a session DBM.
    Also, make sure you expire the session from the database after a reasonable amount of inactivity. What is 'reasonable' is up to you, but don't leave inactive sessions around for too long, unless you want these picked up by somebody other than the original session creater :)
    Done.
    More from a view of making things work the way you expect, rather than security (but security can always hold a place in these things), is making sure the data you are being forced to receive from the client is the data you are expecting. What if a user tells your script they want 0.5 pairs of shoes?
    if($q->param("$name:copies") =~ /^\d+$/) {
    Are there any non-obvious security-related tips (i.e. besides "use taint checks well" and "encrypt credit card numbers" ...
    Um... encrypting credit card numbers? No. Just don't do it. Don't even save the shopper's credit card number in your database
    I was speaking about client-to-server. The (still encrypted) credit card number is e-mailed to the order-processing people; once they've processed it, all electronic data about the order is destroyed.

    =cut
    --Brent Dax
    There is no sig.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://221760]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2022-08-18 19:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?