Ubercart

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?

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

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.

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

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.

Just wanted to let you know that we are still experiencing this issue. (or something with identical symptoms)
We have since turned off caching ... so.. we'll see if that resolves it...

We also noted that the there are two session cookies present when we saw this issue.
Our server loads sometimes spike very high (moving to a new server shortly) that may contribute to our ability to see this issue.
This may cause the PHP.cgi to issue different cookies?

Let us know if you have discovered any further information.... we will do the same.

Thanks,
Janice

Hi there,

I'm reopening this old file since I'm facing this behavior today with the most recent version of UC : I've shared a cart with my client, he was anonymous and I was logged as admin.

I think the problem is caused by Boost and I'll correct it locally, but maybe some other tests would be necessary in order to prevent people using Boost with UC, or at least to take some precautions.

Regards,
TahitiClic