Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Any tips on writing a shopping cart?

by tachyon (Chancellor)
on Dec 23, 2002 at 00:24 UTC ( #221784=note: print w/replies, xml ) Need Help??


in reply to Any tips on writing a shopping cart?

I would suggest maintaining state either with a session ID and all the data on the server or an encrypted param hash (using say Crypt::CBC and Crypt::Blowfish) - stored in a single 'hidden' field. Cookies are not secure. Nor can you rely on them being available so a hidden field holding either a session ID MD5 hash or an encrypted param hash is the way to go IMHO. You also need to have some sort of timeout mechanism to expire sessions so cached data rapidly becomes useless. In some applications of mine I will reset the timeout to say 10 minutes each time the client hits the server - no activity for 10 minutes and a new login is required (old state data is then restored). This avoids a malicious user being able to steal a session from cache very easily. When forcing a re-login you need to loose the old session data if the login username/pass is not for the expected session.

One major issue is how you want to handle BACK. You can use no cache but users expect to be able to use the back button. For this reason I favour maintaining state with a well encrypted param hash embedded in the page rather than a session id with data on the server. This way the state relating to that page is always accurate. If you use a session ID and data on the server if a user goes back the web page and the session data are no longer in sync. It is simply not possible to consider all the possible permutations that can occur when users go back but you avoid the issue if the state data is *securely* embedded in the page.

It has been said again and again but you should never trust the client (even with encrypted data) and always validate prices on the server side before confirming the order.

If you don't keep credit card numbers you are far less likely to have them hacked from you. I prefer sites that always ask to the number again. If using an encrypted param hash in the pages I would just store a reference to the credit card number embedded on the page with the actual number kept on the server. Perhaps just paranoia but this ensures the CC number only ever makes one pass through the ether when the client submits it.

For added security there is no particularly good reason not to run the whole cart on an https server, including the initial login. Also to protect from know plaintext attacks on your encryption you can double/triple encrypt the param hash which makes it a little harder and more time consuming. If the cart is going to be offered to others I always automate the setting of the salt/key for the encryption when the thing is setup - if you do not do this and rely on the installer to make the required change your encryption is trivial to break in the case where the default salt is used. People will forget and you will get blamed! The encryption has to be two way and with the salt/key the decode is a no brainer.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

  • 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 mt2k (Hermit) on Dec 23, 2002 at 07:45 UTC
    One major issue is how you want to handle BACK. You can use no cache but users expect to be able to use the back button.

    I just had a great realization here. I can't believe I never really thought about users using the BACK button on their browser. I can imagine the amount of confusion and damage done with this. Besides using a param hash in a hidden field, I suppose you could use the "Cache-control: no-cache" and then keep a 'step' number/key in the database as well. This identification token could then indicate which step in the process the user is working on, and load only the page that step corresponds to, unless the parameter to change the step is sent to the script. So in a shopping cart app, after saying "I want 10 pairs of shoes", and hitting the "Add to cart" button, say I want to change it to 5 pairs. I might hit the 'back' button, but this would load the same page I'm already looking at, perhaps with a 'sorry, do it the long way around' message.

    I'm not sure how efficient what I am saying would be to implement and use, so I am going to give it a whirl of a test to see how it does work out. The only downside I can come up with is huffy, puffy users who want their BACK button functionality to function the way it's supoosed to :) I'm going to put something together, and then perhaps throw it in the code catacombs or code snippets. We'll see...

    -------------------------------------
    eval reverse@{[lreP
    =>q{ tsuJ\{qq},' rehtonA'
    ,q{\}rekcaH },' tnirp']}[1+1+
    1,1-1,1+1,1*1,(1+1)*(1+1)];
    -------------------------------------
    

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2022-09-30 15:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer my indexes to start at:




    Results (126 votes). Check out past polls.

    Notices?