as of late last week, the folks at SCW are getting many customers reporting that they are getting the wrong cart contents when they go to the checkout.
when viewing the cart/ page, customers will see their order, but when clicking checkout, it shows them order details from a completely different customer. obviously this is a serious problem, and we are actively trying to track it down. as yet, i've been unable to reproduce the bug, but we have a strong suspicion it's related to a similar problem experienced by another client who's using ZenCart. also, we have determined that the other customer is one who is also shopping at the exact same time- it appears whichever of the two orders completes first then takes over the cart of the second order.
this thread (and this one too) describes a problem where customers coming from behind a big ISP proxy will end up experiencing something similar to the problem we're seeing on ubercart because the session handling code gets its wires crossed as shoppers appear to be coming from the same IP.
in the case of ZenCart, we solved the issue by turning on the following options:
- force cookie use
- Check SSL Session ID
- Validate the SSL_SESSION_ID on every secure HTTPS page request.
- Recreate Session
- Recreate the session to generate a new session ID when the customer logs on or creates an account (PHP >=4.1 needed).
unfortunately, afaict there are no analogous settings in drupal/UC, since cookies are always used to track user sessions. i've hunted through drupal.org and ubercart.org extensively, and can find no reference to this kind of problem.
the closest i could find were threads like this one which appears to be unresolved, tho i can't really tell if some other solution to this problem was implemented at some point. i also know that drupal has had one XSS vulnerability that was fixed in 4.6, but i assume this is no longer an issue.
one other relevant point: having decided that the site launch was successful and most of our development efforts complete, i turned on the "standard" drupal page caching mechanism late last week. reports of this problem only began after that configuration change, and so i'm guessing it may be related (in the meantime, i've turned caching off again).
anyway, any help/insight/feedback on this is greatly appreciated, obviously 
thanks!
spidey
Re: customers losing cart contents in checkout - session crossin
Oof... caching is on my list of things to revisit. I'm curious to know what sort of details they're seeing from other customers... is it actually filling out form fields for them (very bad) or is it just displaying the wrong cart contents? Either way, I'm not sure if that would be a caching problem or not, and I haven't heard of the session issue before. Is there any way to duplicate the issue?
Maybe related... on the same machine, I can login to this site using IE and Firefox and have two different sessions, so I'm not sure if this would be related to IP address. Did that matter to the issue as experienced by Zencart?
oof indeed.
ya, this is a nasty one- it *is* actually filling out form fields, tho fortunately the cc masking code is kicking in, so people are just seeing address/contact info for ppl they don't know (bad enuf, but could be worse).
i've had trouble reproducing the error, although i was told today that the client was able to do so by running two orders through at *exactly* the same time.
as i understand, in the case of zencart, it appeared to have to do with the way that AOL and other big ISPs force all web traffic through a load balanced set of proxy servers, causing users to "change IPs" mid-session, or something like that.. it also seems to happen if for some reason multiple users come from the same IP (NAT, or multiple browsers, as you suggest).
in any case, i'm keeping my fingers crossed that it's a cache problem, and waiting to hear confirmation that they haven't had any further reports of this error since we turned drupal caching *off*.
meantime, maybe the morning will bring fresh ideas
*sigh* what a day..
spidey
Re: oof indeed.
Yeah, let me know. Caching is on my list of things to address (and I thought I had done some already). I also thought I had implemented a double check based on the referrer URI to prevent someone else's data from being displayed, but I'll revisit that code.
caching seems to be the source
we have a tentative confirmation today that the problem is resolved. they are no longer able to reproduce the error, and as yet have received no further complaints from customers. we are working our way through the bunch of orders that are "in checkout" but already processed, and keeping our fingers crossed that caching was indeed the source of the trouble.
Ryan: thanks for your thinking on this, and i hope your review of the relevant chunks of code reveals something helpful
Quick download of my findings...
Hi there,
After a review of when / how this issue seemed to be happening, I'm less convinced that it's got much to do with the ISP / IP / Proxy scenario, and more to do with the connection to the payment processor (in this case, Authorize.net). Turning off the caching does seem to solve the issue ... but, when you investigate, you may want to look at how the authorization or pre-auth is done.
From what I can tell, here was the chain of events:
* Customer goes to check out page and starts filling in the form sections
* At the Payment Method section, there seems to be a little pre-auth or something that happens for credit card orders
* At this point, two things happened: Customer A was charged for their cart order and Customer A was shown Customer B's information.
* And, Customer A's cart remained in a "checkout" state, not in a successful order state
When I looked at the logs, it appears that Customer As cart was created minutes before Customer Bs, but that the *credit card charge* got recorded at almost the exact same time as Customer Bs cart moved into a checkout status. Hence why I suspect that the authorization module + caching may be worth investigating.
HTH,
Phillip.