Scary bug/flaw? Showing checkout

also, because you are using multisite, it might be worth verifying that the COOKIE_DOMAIN settings are correct, and if you are using the domain mapping plugin.

-jeff

Also, what version did you upgrade from?

I ask because if the visitor or visitor meta tables have not been created correctly every visitor would be assigned the visitor ID 1.

Because you are running multisite, if you enabled multisite without going through the WP-eCommerce installation and setup it is possible that the visitors table and visitor meta table were not created with your second site database prefix.

jeff

Jeff,

The cookie shows a “1”, but isn’t this really just symptomatic? That is, the cookie is set like that because the system identified the initial request as coming from a bot before there was a cookie. Obviously the system is going to carry on treating it as a bot once the cookie is set, but it’s the initial determination that’s at fault, surely?

Further debugging leads me to suspect something in the _wpsc_create_customer_id() function. Here’s output from a single page load, output from wpsc_get_current_customer_id() in customer.php. Because the calls overlap, I create a random number at the top of the function so I can distinguish one call from another, and that’s the first number. The second is the line number, then there’s a description of the state of things. Im only including the first three calls because everything after that is the same as the third:

8606	27	Array
(
    [__unam] => 81c065-14dc3792a53-2d2bcdd-12
    [_ga] => GA1.2.526016832.1433503607
    [PHPSESSID] => c4d482ded5f218308260c02a21ab8485
    [ADMINDYNSRV] => lin234
)
7427	27	Array
(
    [__unam] => 81c065-14dc3792a53-2d2bcdd-12
    [_ga] => GA1.2.526016832.1433503607
    [PHPSESSID] => c4d482ded5f218308260c02a21ab8485
    [ADMINDYNSRV] => lin234
)
7427	49	$visitor_id_to_set was sent as a param to this function, so we set $visitor_id to it: 1
7427	56	$visitor_id is not false, so we just return it: 1
8606	95	One or both of $visitor_id and wpsc_get_visitor_last_active($visitor_id) is false, so we use _wpsc_create_customer_id(): 1
8606	100	Finally, we return 1
2768	27	Array
(
    [__unam] => 81c065-14dc3792a53-2d2bcdd-12
    [_ga] => GA1.2.526016832.1433503607
    [PHPSESSID] => c4d482ded5f218308260c02a21ab8485
    [ADMINDYNSRV] => lin234
    [wpsc_customer_cookie_de4edf5e10836d598091518036358b5f] => 1|1434025927|f9e34cb884b83646c5c82d46d5d961d9
)
2768	56	$visitor_id is not false, so we just return it: 1

The system is deciding I’m a bot before the cookie is set – doesn’t that dispose of cookies as the culprit? Or am I missing something? I can’t seem to get any debugging output from customer-private.php yet, but it looks like there’s some funny business there.

I posted two user agent strings above. Here they are again:

Safari produces this:

[HTTP_USER_AGENT] => Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.3

Firefox (developer edition) this:

[HTTP_USER_AGENT] => Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0

This is not a multisite install.

When you say “…what version did you upgrade from?” are you talking about WP or WPEC? Either way, I can’t remember the version numbers, but we initially installed about nine months ago with the latest versions of everything, and we’ve consistently installed all upgrades, both to the core system and to the plugin. It was working fine until this last upgrade.

Also, TSO have weighed in saying that it’s definitely not a server problem. I’m still hoping they might come up with something, and of course I’ll let you know if they do.

Cheers,
Ben

Ps – forgot to say that in the above debugging output I’m echoing out the cookies at the top of the function.

Ben

my suggestion is to put the statement

error_log( __FUNCTION__ . '::' . __LINE__ );

at each of the decision points in the function where the cookie/user id is set and find out which condition is causing the user id to be set to the reserved user id.

You should be able to quickly determine which test is causing the problem by looking at your debug.log

– jeff

I’ve got it.

_wpsc_create_visitor_id() would always end up using WPSC_BOT_VISITOR_ID because wpsc_create_visitor() was returning false – and that was because the insert into the wp_wpsc_visitors table would always fail – and that was because the table was corrupt.

mysql> ANALYZE TABLE wp_wpsc_visitors;
+--------------------------------+---------+----------+---------------------------------------------------------------+
| Table                          | Op      | Msg_type | Msg_text                                                      |
+--------------------------------+---------+----------+---------------------------------------------------------------+
| myriaded_irad.wp_wpsc_visitors | analyze | error    | Found key at page 1024 that points to record outside datafile |
| myriaded_irad.wp_wpsc_visitors | analyze | error    | Corrupt                                                       |
+--------------------------------+---------+----------+---------------------------------------------------------------+
2 rows in set (0.92 sec)

mysql> REPAIR TABLE wp_wpsc_visitors;
+--------------------------------+--------+----------+----------+
| Table                          | Op     | Msg_type | Msg_text |
+--------------------------------+--------+----------+----------+
| myriaded_irad.wp_wpsc_visitors | repair | status   | OK       |
+--------------------------------+--------+----------+----------+
1 row in set (0.11 sec)

mysql> ANALYZE TABLE wp_wpsc_visitors;
+--------------------------------+---------+----------+-----------------------------+
| Table                          | Op      | Msg_type | Msg_text                    |
+--------------------------------+---------+----------+-----------------------------+
| myriaded_irad.wp_wpsc_visitors | analyze | status   | Table is already up to date |
+--------------------------------+---------+----------+-----------------------------+
1 row in set (0.04 sec)

mysql>

So the fix was easy, once I’d tracked it down, and everything is peachy again on my client’s site. But this issue is bad for two reasons:

First, there seems to be a suspicion that the table became corrupted somehow as a result of the latest upgrade. I’m not sure why that should be the case and maybe it’s just a coincidence, but it seems as though a number of people began to experience this issue after upgrading, so I think someone ought at least to explore the possibility.

Secondly, a corrupt table shouldn’t expose users’ personal data. This is a very serious bug. Perhaps the decision to fall back to WPSC_BOT_VISITOR_ID is poor, or perhaps a user identified as a bot shouldn’t have “their” previous data loaded into the checkout form, or perhaps the solution lies elsewhere, but it really needs to be addressed in the plugin.

More generally, saying that the problem lies within the remit of the sysadmins or developers running sites where this issue appears is dodging the issue a bit – the plugin developers have a responsibility to make sure that sensitive data isn’t vulnerable to just any little malfunction.

I’m going to file a proper bug report. Thanks very much for all your help, I’m very relieved to have this sorted at last!

Cheers,
Ben

Hi,

I’ve been following this the last couple of days because a client had reported a similar problem (previous customer details). Late last night I looked into it more because now the cart wasn’t accepting items at all, which led me to this thread:
https://www.ads-software.com/support/topic/oops-there-is-nothing-in-your-cart-3
and after I fixed it I went to bed. I was going to report it here today but found that Ben (spuntotheratboy) had already got there.

And I agree 100% with his comment that “a corrupt table shouldn’t expose users’ personal data”. (Unless of course the database itself is returning someone else’s data).

I’ve got a feeling I’ve been here before: corrupt tables leading to strange checkout behaviour. But a quick search of my recent-ish email does not reveal anything.

Hi whitelamp,

Did you try your client’s site on the 3.9.4 release we shipped last night?

Hi Justin – I am using SiteGround.

Whats the latest on this, is it to try the latest update to resolve?

Hi codynew,

The latest is that it should be resolved in the 3.9.4 release. Have you been able to test that? On the Settings > Store > General tab, it should show a notice if your site requires the tables to be repaired.

Let me know!

Thanks Justin.

I tried it and got this error when I tried to repair (and optimise)the database:

mw_3_wpsc_claimed_stock: 10 clients are using or haven’t closed the table properly