Wrong Attributes on Order

I am using v1.3.8 from a new installation.

We are getting an intermittent problem. From time to time, a person will select a product and complete some attribution information for that product and add it to their cart. When they go to the cart to checkout, they find someone else's attributes on the item in the cart. The only way they can proceed is to delete the item from the cart and start again.

This might be something that happens when we are having higher volumes (like 20 orders an hour or something), but that's not a hard fact.

Sometimes we end up with people not noticing and proceeding with paying for their order. This gets us into refunds, etc.

The whole thing makes our order site look pretty shaky and kills confidence in our customers who have encountered this.

Has anyone got any idea what is going on with this?

I am at 1.3.8a. (This is our busy season and upgrade is planned for upcoming down time.)

We are a club which holds running races open to the public. Our "products" are races for which people are purchasing registration. There are a number of attributes associated with a registration, such as gender, name, address, shirt size, etc. (We don't use the customer fields because one person in a family tends to register others.)

This is what is happening. Person A selects the race product, fills out the attributes, adds to cart, confirms, pops over to PayPal and pays, comes back and completes the order. No problem.

At some point a little later (or sometimes they are on the site at the same time) Person B also selects this race, fills out their attributes, and adds to cart. But when they go to the confirm screen, the attribute information shown is for Person A. A number of people don't even look at this and go right through the payment process and pay for a registration of the wrong attributes for them. This gets us into the hassle of refunds, getting in touch with them to redo registration, etc.

This all makes our payment collections site look a little hokey and we are getting people expressing fears about the security of their data and purchase information.

This seems to happen more when the site is a little busy. We had 85 registrations yesterday and I had to refund 8 of them and advise the person to go again. I also fielded a number of calls from people who spotted the problem and had to explain what to do. And then there were probably a few people who figured out how to fix it themselves.

Can someone explain what is happening and how to fix it?

Thanks!

Check to make sure that you have not inadvertently added zenid to some of the coded links and make sure your config files are correct as to matching the need, or non-need, for www.

Thaks for getting back to me!

I'm not sure I follow what you are suggesting. I'm not sure where coded links come into this as I don't believe there is any linking going on here. Same goes for the www and config files.

I want to note that now that the initial rush to register for our next race is over, there has not been a single instance of this situation where another person's attributes (or basket) is attached to the ordering client. I am highly suspicious that it has something to do with multiple users making a similar purchase at the same time, or nearly the same time.

Sometimes a zenid is coded into a link. It should not be. When this happens, clicking on the link can change the session so that any cart items available for the link's ID become available to the new customer.

On rare occasions, setting the config to http://www.yourdomain versus http://yourdomain can create session problems as well.

Most reputable hosts will not have the www problem, but it's something to check.

Lastly, check to see that the Sesssions settings in the Admin >> Configuration menu are correct. Google "site:www.zen-cart.com sessions" without the quotes to see some items that might be helpful.

Okay, sounds like stuff I should check out. How will I recognize a "zenid" in a link?

You should have some suspect area of the cart. You can look at the links in the problem area. Just hovering over them should show a link at the bottom of the browser.

You can also use the Developer's Tool Kit to search. You should have zenid in four files (if you're using 1.3.9e). Any other spots are suspect.

Okay, finally got a chance to check this stuff out.

There are no extra zenids around - nix that. Mu Config-Sessions seems to line up with all the standard settings that I could find - nix that.

No issues with www - nix that.

I can report the following. After the initial rush of registrations, the rate of ordering slowed significantly. The problem went away. Friday night a message went out that the race was half full, generating another rush of orders, and the problem reappeared for at least one customer.

I am more convinced then ever that this is related to volume of usage. I can't explain why volume could be causing this, but it certainly seems related.

maybe your server/hosting is too slow and returns 500 errors during the checkout. Causing the customer to resubmit the order.

Can also happen when the php script does not have enough time to execute.

I was thinking that it might be something to do with the speed of the processing, affected by volume.

How are we supposed to see 500 errors when they occur. Does zen cart trap such errors?

Not sure what to do about the speed of our web hosting, if that is the issue?

I doubt that this is about the speed of your server or the volume your processing. At Kuroi we have who clients whose sites peak at over 100 orders an hour and we've never seen the problem you're describing, let alone with a 10% error rate.

Each customer's order details should be held in a separate php "session" and if the server were overloaded all that should happen is that everything slows down and grinds to a halt, not that information from one visitor's session becomes available to another.

This sounds to me like a candidate for problems with how php has been configured on your server, rather than the Zen Cart application code.

But you'd need somebody with more expertise in that area than me, to comment further. It might help though if you could post some information about your server, php version, and how php is configured to run on the server.

Seconding Kuroi's observations, we definitely need more info...

1. Tell us about your server setup. Is it shared hosting, VPS, or dedicated? What OS?
   
2. Did you install Zen Cart yourself -- downloaded source directly from this website -- or did you use some installation service provided by your host?
   
3. Ditto your PHP/Apache setup: any idea where/how those were installed & configured?

Our web site is provided by a hosting service - Total Choice Hosting. We downloaded Zen Cart from their cPanel. I set it up myself.

Server OS: Linux 2.6.18 - 194.26.1.el5

MySQL: 5.0.91 - community

PHP: 5.2.14 (Zend: 2.2.0)

Zen 1.3.8a

With respect to upgrading to 1.3.9h, I am quite willing to do so. I was waiting for a quiet time in usage to do so, and I should probably look after it shortly. I am a little worried, however, since this would be my first major upgrade. I hope I have done my customizations correctly, so they are not lost. I also am worried about any issues that I might have to deal with in an upgrade. Should I expect it to just be a smooth process without any difficult steps?

I have to say, I no longer think it is a volume issue. The most recent round of registration that showed this problem was for a fun run by our club. We had about 30 or so registrations.

Here's how one string of problems showed.

One of the items I have defined is Volunteer and Social, and it is no charge. It has two attributes - "Name", and "Shirt Selection".

One member "ordered" this item to register for the social. Then another member tried to order the same item 7 minutes later. The name and shirt size of the first member was displayed in the attributes when the item was displayed, and could not be changed. The 2nd member went through with the registration anyway.

Then 10 minutes later, a 3rd member tried to order the item and the 1st persons information was displayed again. And then again, 12 minutes later, a 4th member got the same situation. (We know this because I have all the orders).

In the past, when this happened, I often got an email from the person before the order was completed. The work-around was to delete the item from the cart and start again from scratch.

It seems that on occasion a set of attribute values "persists" and continues to be picked up by subsequent attempts to order the item. Just crazy!

How is Zen Cart configured to store sessions, database or file ?

This is what is in the Sessions item in the administration section:



Session Directory /home/anwuttb/public_html/cart/cache
Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true

Hi,

Should have made my question a bit clearer.

What I was after was what setting you have in your configure.php for

define('STORE_SESSIONS',

It is set as "db"

Quote:

---

Originally Posted by sdelaney

One of the items I have defined is Volunteer and Social, and it is no charge. It has two attributes - "Name", and "Shirt Selection".

One member "ordered" this item to register for the social. Then another member tried to order the same item 7 minutes later. The name and shirt size of the first member was displayed in the attributes when the item was displayed, and could not be changed.

---

"Could not be changed"???? That's very odd.
Got a link for that page URL?

Well, here is the selection for the three items that people were "ordering" in order to register for our event.

https://athleticsnortheast.com/cart/...=index&cPath=5

The problem of not being able to change the value of the attributes only happens when this bug shows itself. If the person selects the item, and it already has the values filled in (from someone else's order), then those values remain. I think the person can change them on the screen, but when they add them to their cart and go to checkout, the initial values reappear. This is why the 2nd person actually has to delete the item from their cart and start their order over from the beginning to get it to work okay.

I admit, this is crazy. I have worked a lot in IT in former years, and this sort of behaviour has me stumped. I can't imagine the chain of events that might cause something like this. And of course, it is extremely hard to duplicate the problem because you basically have to wait for someone to report that it is happening, seemingly at random.

Steve

You aren't by any chance advertising to people to come to your site to do sign-ups, but the link you're giving them includes a zenid=xxxxxx parameter are you?

Publishing links containing zenids can cause an ugly phenomenon called session-hijacking, in which case subsequent visitors to that same link will see the information entered by previous visitors. Zen Cart attempts to protect against this in several ways, but if you're out publishing such links, you're directly inviting such problems.

Not sure if you're doing that or not, but it's something to keep in mind.

Also, are you always publishing "https" addresses, instead of just "http"?

I am quite sure we are not including any zenid= elements in our links. (For example, I don't believe I sent you one, correct?) We actually direct them to the login screen, and from there they need to select the correct registration item.

HTTPS is new to us, and although I make sure to start any link with https, some of my club mates may not be so careful. In fact, I specifically recall that one message on registering for this fun run was lacking the "s" on the http. Do you think that might be causing this?

Steve

I would recommend you point people to the HTTP version of your links, and let Zen Cart flip them into https links when it needs to protect their session by using ssl, such as during login and checkout.

So other than directing them to the http instead of https, I leave it to Zen to flip them to https as needed?

And if I am sending them to the login page as my link, still http?

Steve

Hmmm ... I guess if you're sending them to your login page directly, then it's appropriate to use the https URL.
Even the login page will still use SSL when the customer submits the form, because the page is configured to use the SSL version of the address automatically for sending the details to the server.
So: short answer: either one is fine.

Just don't use https URLs if you're NOT pointing them to the login page. :)
(Because it's the switching to SSL during login that triggers much of the session hijacking protections.)
(Granted, if you're never publishing URLs with zenids in them then it's somewhat moot.)


Still very puzzled by the other symptoms discussed earlier though. :(

Okay, thanks for the tips ...

Yes, the behaviour is bizarre ...