• Resolved codynew

    (@codynew)


    Hi

    I have WP 4.2.2 + WPEC 3.9.3 on a multisite.

    I have a very scary bug where if I visit the checkout page for the shop, I can see the billing address details of the previous customer who has has been on the site even if its NOT me.

    Even if I visit the link using incognito mode and visit the checkout link directly, I can clearly see all their details.

    Can anyone advise please? Really freaked out πŸ™

    https://wordpress.org/plugins/wp-e-commerce/

Viewing 15 replies - 1 through 15 (of 26 total)
  • Thread Starter codynew

    (@codynew)

    note: I can even see their cart, and all the item(s) which they have in their basket.

    I’ve even tried deactivating and activating the plugin again and no luck.

    Plugin Author Justin Sainton

    (@justinsainton)

    Hi codynew,

    Interesting, this is the first I’ve heard of such an issue.

    I wonder if there is a plugin or theme function that is hooking into the user meta system and creating conflicts or issues with data exposure.

    Happy to help debug, but I’m quite certain there is something else at play here.

    It’s somewhat likely that this is a web server or WordPress content caching issue. Quite simply something is not properly configured.

    Thread Starter codynew

    (@codynew)

    Thanks @jeff – I’m running a mirror of the same sites on the same server but not had this issue before.

    @justin – is there a way to PM you?

    Thanks

    Plugin Author Justin Sainton

    (@justinsainton)

    Hi codynew,

    Sure thing, shoot me an email at justin at zao dot is.

    Justin,

    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

    Only two things I can think of that are causing the issue, both are caching related.

    You need to answer these two questions:
    (1) Is the web server getting a valid user agent string? If the user agent string corresponds to the user agent string of a known crawler the user id will be set to a user id reserved cor web crawls. User id “1”. That would mean every web request will see the cart from user id “1”

    (2) Is the cookie used to store the user id and authenticator token is not being correctly passed to the web server, and instead a cached cookie is being passed, the same symptoms will be present.

    I have seen both of these issues when an ISP mis-configures a Varnish cache, but any number of web server misconfigurations, .htaccess configurations, or plugin configurations could cause the same symptoms.

    Turn on debugging, and echo the user cookie, the user agent, and user id into the debug log and see what is happening. If you see the issue start following the request back through your stack until you find the issue.

    jeff

    Plugin Author Justin Sainton

    (@justinsainton)

    I’m curious, spuntotheratboy and codynew – what host are you both on? If it’s the same host, it may point to a configuration issue on that host.

    We’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.

    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

    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.

    Your close to finding the cause,

    I would suggest you dump dump the $_COOKIES array so we can see if there is a cookie set that is invalid and forcing the bot selection.

    the line:
    error_log( var_export( $_COOKIE, true ) );

    should put the information info your debug log.

    I am a little suspicious that you may be hitting the invalid cookie check in at the start of _wpsc_is_bot_user()

    You might also want to confirm that the wpsc_bot_user_agents and wpsc_is_bot_user filters are not being used by any themes or plugins.

    what is the url of your store?

    I’m getting this same bug as well, where a previous customer’s ordering details are presented to the current customer. Last time I put a ticket into support I was told this was not possible (though possibly due to a caching plugin or out of date Gold Cart). There are no caching plugins active on my site and the problem seems to have re-occured once upgrading from Goldcart 2.9.7.8 to 2.9.9. Really need a fix for this.

    Jeff 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.

    Definately something wrong here. wpsc_customer_cookie_* should never start with “1” for a real user. The “1” is the visitor id reserved for a bot.

    Still not seeing the user agent in the debug dumps above? you want to

    error_log( var_export( $_REQUEST , true ) );

    and

    error_log( var_export( $_SERVER , true ) );

    to get the whole picture.

    What is the url of your site?

    -jeff

Viewing 15 replies - 1 through 15 (of 26 total)
  • The topic ‘Scary bug/flaw? Showing checkout’ is closed to new replies.