Mini-shopping cart and hardcoding prices

One item, one price

[mipapage]

Hello,

I'm coding up a simple shopping cart using session variables, and have a question about the price and security etc.

---

The display of the quantity and prices is handled with the session varibles. This is passed on to a "cart summary" page where the user then clicks a button and the details of the purchase are passed on to a TPV via 'Post'.

I've seen it mentioned that there are some security issues if you pass on the price with the session variable vs. referring to a database as a user can type in a different price for the price in the addressbar (am I right about this?).

As this client is only selling one product, I have only one price to which I add the shipping cost, which is also a single unchanging price. Rather than use a database, and to get around the security issue above, I was planning on just hardcoding the price as another variable into the backend PHP. So, although a session variable will display the price, I will have another variable set with the price that goes with the post.

Is this okay, or am I missing something?

[PCInk]

I would hard-code it or use a database. There will not be many who understand how to change it but some will (I know a car leasing company that puts the price in the address bar and I keep thinking I should go back and change the price to £20 per month for a Porsche!).

One way of doing this would be to create a separate library PHP file (I don't know PHP, but I'm sure someone can point you in the direction if you don't know what that is) with one function that returns the price. Then you can use this function wherever the price is displayed or used, so when the price changes, it only has to be changed in the one file.

It may sound like work now, but believe me, when you change price it will make life so much easier.

[mipapage]

PCInk,

Great idea! I really appreciate the feedback. Although this script is quite simple, doing it that way will make it that much quicker to custamize should I use on a somewhat-larger project.

I forgot to mention in the first post - I'm retrofitting the cart to a statically built site that has just one product - so I was hoping to hard code to stay away from using a database for something so 'simple'.

[PCInk]

If you set up the code with a variable (product code) and send the product code to check the price, if the site suddenly expands to sell three products, the foundation is there for returning more than one price.

You need to think larger, one product to three is not unreasonable, one product to 20,000 is unreasonable and I would avoid database unless you do expect a large quantity of products.

My site, for example, has 3000 products, not enough to warrant a database, I use a flat file format which is almost as quick as a database. I could not use a simple function like your site can, a database would have been over-the-top for my site. It all depends on scale and what is best for the individual site - but if you think the right way in the first place, upgrades are so simple. For example, you could expand the above file to include a function to return the price and a seperate function to return shipping and a third to return the tax percentage (even if you are not charging tax now - you may in the future). This method is called 'redundancy': the idea being, only have one item being stored once, so when you need to change something it is a simple procedure.

[mipapage]

You need to think larger, one product to three is not unreasonable, one product to 20,000 is unreasonable and I would avoid database unless you do expect a large quantity of products.

Thanks. I have talked with the clients and this site is staying at one product, but I realize that this method is limited (but could work for a few more).

I'm surprised to hear that you would say 3000 products is too small for a database, but alas, I am but a rookie when it comes to the php/mysql world ;-]