spuntotheratboy
Forum Replies Created
-
Forum: Plugins
In reply to: [Contact Form 7] Handling arraysBump… I’d be really grateful if someone could have a little think about this! If I still don’t get any answers then I’ll stop nagging.
Cheers,
BenSorry Javier, do you mean there should be a password column, but empty? Or there should be no password column?
Thanks
Thanks Javier.
What if there is no password column? Should I add a blank one?
The behaviour I want is that new users have a password generated for them, and a notification email, while for existing users the username, email address and password are left alone and other data updated.
Thanks a lot for your help, I really appreciate it!
Cheers,
BenForum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutI’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,
BenForum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutPs – forgot to say that in the above debugging output I’m echoing out the cookies at the top of the function.
Ben
Forum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutJeff,
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,
BenForum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutJeff et al.,
There are no references to wpsc_bot_user_agents or wpsc_is_bot_user anywhere except in the shopping cart:
bash-3.2$ grep -r wpsc_bot_user_agents ~/public_html/wp-content/ ~/public_html/wp-content/plugins/wp-e-commerce/wpsc-includes/customer-private.php: $bot_agent_strings = apply_filters( 'wpsc_bot_user_agents', $bot_agent_strings ); bash-3.2$ grep -r wpsc_is_bot_user ~/public_html/wp-content/ ~/public_html/wp-content/plugins/wp-e-commerce/wpsc-includes/customer-private.php: if ( _wpsc_is_bot_user() ) { ~/public_html/wp-content/plugins/wp-e-commerce/wpsc-includes/customer-private.php:function _wpsc_is_bot_user() { ~/public_html/wp-content/plugins/wp-e-commerce/wpsc-includes/customer-private.php: $is_bot = apply_filters( 'wpsc_is_bot_user', $is_bot ); ~/public_html/wp-content/plugins/wp-e-commerce/wpsc-includes/customer.php: if ( _wpsc_is_bot_user() ) { bash-3.2$
Here’s $_COOKIE. I’m echoing this at the beginning of _wpsc_is_bot_user(), and the page I’m loading is the checkout:
Array ( [ADMINDYNSRV] => lin113 [PHPSESSID] => 3354e8cd3570a0d1dcb73df044633b55 [wp-settings-8] => editor=html&libraryContent=browse [wp-settings-time-8] => 1433422588 [wpsc_attempted_validate] => Tue Jun 09 2015 10:12:34 GMT 0100 (BST) [wpsc_customer_cookie_de4edf5e10836d598091518036358b5f] => 1|1434014028|068ebb51b8b032a0a35156729d8927d5 [__unam] => 81c065-14dbe747038-4bb9b915-66 [__utma] => 100069506.1441442529.1415100215.1415100215.1415178910.2 [_ga] => GA1.2.1441442529.1415100215 [_gat] => 1 )
…and here’s another one using a different browser:
Array ( [PHPSESSID] => 1d5202077e07522550aca52e6b4c2c3c [wpsc_attempted_validate] => Tue Jun 09 2015 10:20:35 GMT 0100 (BST) [ADMINDYNSRV] => lin234 [_gat] => 1 [wpsc_customer_cookie_de4edf5e10836d598091518036358b5f] => 1|1434014569|df241bc16f7aa9e41875e000790ac85c [_ga] => GA1.2.1954724724.1433421944 [__unam] => 81c065-14dbe9b17f9-79df4d08-11 )
Interesting that the wp-settings ones don’t show up in the second browser, but I don’t imagine that’s significant. The value of
wpsc_customer_cookie_de4edf5e10836d598091518036358b5f]
is different, which seems right. I don’t really know how to interpret any of this – it looks OK to me, is there something wrong here?Thanks.
Forum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutSafari 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
They look pretty sound to me. I’m logging from wpsc-includes/customer.php in wpsc_get_current_customer_id() – here’s the line (repeated a few times throughout the function):
fwrite( $log, __LINE__.': '.$_SERVER['REMOTE_ADDR'].' : '.$visitor_id."\n" );
__LINE__ so I can keep track of which condition is being met; $_SERVER[‘REMOTE_ADDR’] so I can make sure I’m seeing me and not an actual robot or crawler; and $visitor_id (or $id in one case) so I can see what’s being returned. Every single user is being assigned the ID 1 – here’s a single page load from the log, with xs where my own IP address shows up:
56: xx.xx.xx.xx : 1 80: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1 48: xx.xx.xx.xx : 1
Line 56 is where this happens:
if ( _wpsc_is_bot_user() ) { $visitor_id = WPSC_BOT_VISITOR_ID;
…the line number would be lower except for my debugging strings. Basically, the first time the function gets called it determines I’m a bot, assigns me the id 1 on that basis, and subsequent calls just return that.
So it’s definitely because your system thinks I’m a bot. I can’t see anything iffy in the user agent string, though.
What do you think? This pretty much eliminates cookies, I think?
Thanks again for your help.
Forum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutWe’re on a TSO cloud host. It was all working fine for some time until the most recent update of the plug-in, without any changes in server config.
I’ll certainly look into your suggestions when I can – but those cases should be dealt with and taken into account in the plug-in, really, even if one of them does turn out to be involved. We’ve had plenty of other systems – including yours until recently – where this wasn’t an issue, on these same servers.
Thanks for your help.
Forum: Plugins
In reply to: [WP eCommerce] Scary bug/flaw? Showing checkoutJustin,
This is happening for me too: WP 4.2.2 and WPEC 3.9.3
It’s almost certainly not a caching issue. It seems that the function wpsc_get_current_customer_id() is returning the information for the previous customer – unless the user is logged in, in which case it correctly finds their stored information.
For the moment I have used jQuery to clear the fields, but apart from being an inelegant hack and ignoring the root issue, it doesn’t remove the information from the source code.
We really need to get this sorted quickly. Did you get anywhere with codynew’s issue?
Thanks very much