Topic awaiting preservation: Cookies or Sessions for a shoppnig cart? (Page 1 of 1)

Thinking about it i would probably use sessions to handle a shopping cart for a user, because i dont really want their selections saved if they have closed the browser.

Anyone have any idea on the general practice for this, and what/why is the best path to take? thanks.. (Of course cookies will still be needed to track that they are logged in)

For any ecommerce operation you will want to handle as much on the server side as possibe. The less data the client has to save the better and more secure your site will be. You will find that most largish ecommerce sites use a Java based solution as the user's thread exists until the user is gone.

Finally. You will be using sessions and cookies for most of your site, but you will also want to have temporary databases. These would be for keeping track of what the user currently has in their shopping cart, etc, etc. You wouldn't want all of this information in either sessions or in cookies, you should keep the really important information in a semi-permentent enviornment. Just imagine the user's web browser crashed and their cookies were not saved, then the system reboots and by the time they get back to your website their session was purged, if you have the DB table of the user's items when the user eventually gets back into the site they will not have to go looking for their items again.

When doing any ecommerce site you want as much redundancy and as many fail safes as possible. The slightest screwup or lose of data can ruin a sale and any chance of that customer returning to your site.

Dan @ Code Town

Oh ok, that sounds good too me. I *thought* they were generally done as u can fill your cart until you close your browser kinda thing i.e sessions..

I would prefer to no java at all if that is possible... i could store the session id a cookie so that its timed instead of session based, then the temporary database details could be stored in that session..

Having said that if their browser crashed and they lost the cookies then they still would have to start over... infact is there actually a way around this? You mentioned java, im assuming you mean javascript, but even using js you would need some cookie data to remember where you were surely. Unless you check the users ip and see if they were doing something in the temporary database- that might be an alternative solution.

It would be rare for your ip to change in the time you want to do the shopping, so when a user comes onto the site this could be cross referenced with a database to check if they were shopping - this could actually remove the need for cookies and sessions all together?

Can you see any reason not to doo it this way?

What I did in the latest project was to skip the session/cookies for the shoppingcart and managed it through the db.

Works perfectly for logged in customers (which was a requirement in our case)
I had one table for carts (cart_id, customer_id, created_date) and one table for cart_items (cart_item_id, cart_id, product_id, quantity)

This I manage through a shoppingcart object that holds methods to add/edit/delete data in these two tables.

As a customer logs in I check if he has a cart, if so, I load it if there are any items, if he doesn't have a cart I create one for him.

Then he goes on a shoppingspree (hopefully)...

As the cart is checked out I do a lookup on price, shippingcost and so on for each product, then I insert the cart data plus costs and so on into the order and order_item table (similar structure as for the cart), then I get paid (the site that is) then I clear and delete the shoppingcart for that customer.

Auto clearing of the shoppingcarts is done through a cron job that checks if a cart is older than 24 hrs (configurable) from its creation date, if it is I clear and delete the cart.

Lastly I offer the admin to manually clear carts at any interval he chooses.

As I did all this in OOP style I could reuse very much and saved lot's of times.

Note that if you want to be able to allow a user to shop w/o beeing logged in you need to use temporary tables, sessions and cookies in some combination. If you do this, lead the user into logging on as soon as possible in the process so you can store their temporary data and use that storage instead.

And no, don't rely on IP to keep track of the user, it will fail if several customers are behind a router/proxy that shows one IP to the outside and differentiated on the inside... Sooner or later you'll end up with 50 ppl manhandling the same shoppingcart... There are many other drawbacks as well, but that one guarantees that it will fail.
Go with serverside sessions instead for temporary storage and tracking.

btw, I do believe Warmage was referring to Java as in real Java, not JavaScript when he said "java". Do not mix these two!
Java happens on the server, JavaScript in the browser and never do the two meet
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Thanks for that, clears some things up - i thought that could be a problem with the ips.

Just out of interest, did you run the entire site as secure ssl? Or did u separate pages.. i havnt had much exp with this, but ive been playing with my shared ssl lately..

I know there is a difference with java and js, just wanted to make sure... i havnt done any Java for websites, if its not client side i figure you can do it in php nehow. Ill probably do a similar thing, however it would be nice to be able to shop without logging in.. not all shopping carts require to you login? You can shop then enter your details/cc details and purchase alot of the time..

Either way i guess your method essentially is the cookie/session method nehow, you could do exactly what you are doing without the need to login? even if it isnt a temporary table. Instead of their login data being stored in the cookies etc u just have what they need for the shopping cart.

I will have to see what works out the best :/

I was speaking of Java as the server side language that would be used. Java tends to be used on larger sites because it is easier to scale and tends to be very very fast. You can however do it with any of the other languages, such as PHP in your case.

You will want to go with the cookie/session thing but you will also want to incorporate the DB tables into the shopping cart. It just makes a lot more sense to keep track of that information in tables. That is what MySQL is all about.

As for the IP issue. You might want to keep track of the IP address for record keeping purposes, and it is a helpful tool in validation, but like Dan mentioned above, when you run into people who are hidden behind a huge dialup NAT you will have multiple people with the same IP address, this can get ugly.

Dan @ Code Town

Hello!

I tried a lot of ready made carts and they were so difficult to customize to according to my needs that i created my own very basic cart. Now what i have done is:

i have created a table called 'cart' which has the following fields:

userid - md5 sessions id
itemid - item's id
qty - quantity
price - item price
totalprice - qty * price
timeadded - time stamp

this is working good and is pretty simple to use. Now the problem is...i don't wanna user login before adding stuff to cart. So any user who visits the site has a cart available. Now suppose if a user visist and add's stuff to cart and never purchases and leaves and never comes back to the site. Now the items in the cart table exist and the user will never come back.

Is there any possibility that the userid may get matched with some other user who visits the site ? If no then also how can i clear items in the cart table for the users who have not purchased or will never come back ?

I hope to hear from all you experts soon!

BTW my cart is php and mysql based.

Thanks!

Delete old carts if stored in db...

quote:

---

Auto clearing of the shoppingcarts is done through a cron job that checks if a cart is older than 24 hrs (configurable) from its creation date, if it is I clear and delete the cart.

Lastly I offer the admin to manually clear carts at any interval he chooses.

---

Sessionbased carts would die as the session expires

Cookiebased carts you can kill by adding an expire date to it as you create it.

And no, if you create an md5 hash as cart identifier from a different value each time it's very unlikely that you will assign the same id to several visitors.
/Dan

{cell 260} {Blog}
-{ ?Computer games don?t affect kids; I mean if Pac-Man affected us as kids, we?d all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music.? (Kristian Wilson, Nintendo, Inc, 1989.) }-