POST request made by a marketers.coop page does not always complete

[viraladmin]

Environment

Windows 10 64bit
Google Chrome Version 55.0.2883.87 m (64-bit)
Adblock Plus Version: 1.12.4
Updated: October 26, 2016

How to reproduce

1. Visit ​http://marketers.coop
2. Whitelist the domain in Adblock Plus
3. Login with username test and the password test.
4. Visit the "traffic exchange" link from the "MCC Exchanges" in the left hand sidebar menu.
5. Click the large red button with the clock icon.
6. Wait 10 to 12 seconds, a captcha will appear - click the matching image.

OR

1. Visit ​http://admin.marketers.coop/includes/captcha2.php
2. Whitelist the domain in Adblock Plus.
3. Wait 10 to 12 seconds and then click the correct captcha image.

Observed behaviour

The request for http://marketers.coop/includes/sur_crd.php doesn't always complete. When the request fails it's marked as "cancelled" by the Network pane of the Chrome developer tools but does not show up in the Adblock Plus pane of the developer tools.

Expected behaviour

For that request to always succeed.

Notes

The code that initiates that request looks like this (tweaked to remove HMAC check):

   id = $(this).attr("data-id");
    var ids = encodeURIComponent(id);
    
    $.ajax({
        'url': '/includes/test2.php',
        'type': 'GET',
        'data': {
            'id': ids
        },
        'success': function (data) { 
            if(true) {
                $( "#frame", top.document ).toggle(),
                $( "#frame2", top.document ).toggle(),
                $.ajax({
                    type: "POST",
                    url: "/includes/sur_crd.php",
                    data: '&title=Your Web Base App&siteuser=ChadW&surfer=test',
                }),
                parent.RemoveDiv();
            } else {
                alert(data);
            } 
        }
    });

• Under Chrome the request also fails when Adguard, uBlock and ​sometimes when no adblocker is installed.
• Under Firefox the problem does not apparently happen.

[mapx]

I tested in firefox, where's the clock ? Do I need clicking "ABP test" or the image on the left ?
I get no captcha.

[mapx]

clicking "red "surf now" button brings me to the same beginning page

[viraladmin]

I created 4 screenshots to help explain the issue:

(Edited by kzar to reduce the displayed size of the images which was breaking the Trac layout.)

[mapx]

yes, indeed I can reproduce the issue.
I can reproduce it using also ubo

so, only disabling the extension in the extension page it's working.
Does not work disabling the site in ABP (or ubo)

I see in the network tab a blocked request

http://marketers.coop/includes/sur_crd.php

Let's see what the developers will find out.

[mapx]

the site is broken in ABP, ubo, adguard
​https://github.com/gorhill/uBlock/issues/2317#issuecomment-273344179

[viraladmin]

Do we have any kind of updates on this?

[kzar]

I can reproduce the issue also but I do not have time to debug the website. If you can make a simple test page containing only relevant code that shows how a whitelisted domain can sometimes have requests blocked I'll continue to investigate.

[viraladmin]

This is the bare minimum we could get it down to to reproduce the issue. It seems to relate specifically to the removed, then readded iframe via jquery code that is causing it to be blocked. If we remove that code, the block doesn't appear to take place.

​http://admin.marketers.coop/abptest.php

[kzar]

Thanks that's a good start.

So I've had a go at making ​my own test page which doesn't use jQuery in an attempt to understand what's going on and also in order to have a simpler test case.

The page attempts to constantly remove and create the iframe in a similar way to how your page works. The iframe loads the image grumpy.jpg. The idea is that if you add the first filter grumpy.jpg the image should start to be blocked and then when you add the second filter @@||static.kzar.co.uk/4808-whitelisted-blocked^$document the request should (wrongly) continue to be blocked. (I also added the image to the main page outside of the iframe to illustrate if the image should be blocked or not at the time of page load.)

Unfortunately that's not working, when you add the second whitelisting filter the image stops being blocked. Any ideas how your page differs from mine? I've run out of time to investigate this for now, but if we can figure out how to reproduce the problem with my page I'm guessing we'll have a better idea what's happening here.

[viraladmin]

Well within what I already shared, it is specifically failing on the ajax POST request inside the success function of an ajax GET request on the page inside of the iframe. This is the page being called

​http://admin.marketers.coop/includes/captcha2.php

It is the last javascript on the page that seems to be failing.

Also I won't lie, I really don't know the first thing about your plugin, or creating plugins at all. When this is fixed, will it be fixed for ALL sites that download our software? As an opensource software, this is the real concern.

[viraladmin]

I will make this clear on this side of things as well... over on github they are trying to close my ticket claiming the problem is not on the end of the plugin because they still see the blocked request even when the plugin is disabled on my minimal test case, so they are claiming the problem is with the browser not the plugin... however the fact is, I have no idea how to make a minimal test case because outside of what I have posted... if one adds the plugins and check my site - despite the block error still being reported in the network screen - the fact is my site doesn't add credits, crypto rewards, or anything else as it should (and as noted above). However removing the plugin... also as noted above - does in fact solve the problem. So this is NOT on my coding end, nor does it relate to the Chrome browser. It specifically relates to the plugins.

[kzar]

Since it's not clear that this isn't simply a bug with your website I will ​follow Gorhill's lead and close this issue too.

Perhaps for example the requests take slightly longer when an extension is installed which means that the POST request doesn't finish before the iframe is removed? (That kind of timing issue could explain why Gorhill could reproduce the problem even without an extension installed, maybe his connection/computer is faster/slower than yours?)

I recommend simply incrementing the user's credit from test2.php if the check passes. What's the point of returning success / failed and then having the client perform the second request asking for the credit to be incremented? (Having the client side decide seems insecure anyway.)

[viraladmin]

And I will keep reopening the tickets, and then I will have everyone that uses the software come and start posting tickets, because now I have fixed the google error of blocking, and still your plugin is causing an issue with my site.

[viraladmin]

does this make it more clear the error is not on my end?

[kzar]

Please refrain from reopening this issue again.