AdBlock Tracker & Usergroup Swap

AdBlock Tracker & Usergroup Swap [Paid] v2.4.2

No permission to buy ($45.00)
Overview FAQ Updates (49) Reviews (4) History Discussion
Btw able to add recebt tracking history block on user account even if user is all clear and not blocking please
 
Wutime updated AdBlock Tracker & Usergroup Swap with a new update entry:

v2.2.4

  • Added user-edit "AdBlock history" buttons:
  • Reset: Clears AdBlock Status, decrements swap counter, sets current nondetects and current detects to 0
  • Delete: Removes user and deletes all device history (essentially a hard reset)
  • Ignore: Resets user and removes the from tracking and log list
  • When hidden or deleted by an admin, the user will ALWAYS have their AdBlocking usergroup removed
  • When "ignored and hidden", their status will be cleared
  • When "deleted" or "reset"...
Click to expand...

Read the rest of this update entry...
 
Stuart Wright said:
@Wutime are you certain that the Ignore these usergroups option works 100%? I have some moderators who are in the adblock usergroup.
Click to expand...

Yes, that shouldn't be possible after this update. All resets/hides will clear AdBlock user-group. Also, even if cached, the API that handles detection checks if they should be ignored. Previously it relied on assuming the tracker was never placed on the page.

Stuart Wright said:
Also when editing a user, the Adblock history tab throws the following error:
Click to expand...

I can't reproduce, but did find something that might resolve it.

tajhay said:
Btw able to add recebt tracking history block on user account even if user is all clear and not blocking please
Click to expand...

Added three buttons:
  • Ignore & Do Not Track
    • Removes user-group if set
    • Removes user from tracking and displays (unless showing hidden)
  • Reset Current Status
    • Removes user-group if set
    • Sets current detects to 0
    • Decrements role changed by 1
  • Reset & Delete
    • Removes user-group if set
    • Deletes the entire user record and user's device history
 
Wutime said:
I can't reproduce, but did find something that might resolve it.
Click to expand...
Still getting the error with 2.2.4.
I've identified the specific instance where it happens. If the user has a space in their name, then the server error reports their user name with the space removed and a '1' on the end.
E.g. user name Chris Chapman, the URL under their name is
[domain]/admin.php?wutime-adblock-tracker/view/687899/Chris%20Chapman/1
which throws
Oops! We ran into some problems.
The requested page could not be found. (Code: invalid_action, controller: Wutime\AdBlockTracker:Detected, action: ViewChrisChapman1)
Click to expand...
Whereas a user with a name with no space has a URL of
[domain]/admin.php?wutime-adblock-tracker/view/255775/electrosmith/1
and displays the modal fine.
 
Stuart Wright said:
Do you have any information on how you mitigate rapid clear page loads to remove the adblock flag?
Click to expand...
There's a flood check setting. The default is 8 seconds. You can increase that. So any page views below 8 seconds that are "Clear" won't count towards their "Clear" page views. If you know the average usage between page loads is more like 30 or 60 seconds under normal usage, you could increase to 25 seconds for instance.

Note, if you make it too high, the user will never be able to record a "Clear" page load unless they revisit minutes later, etc.

Also, the page they're viewing their "AdBlock History" on is excluded from Tracking by default: account/adblock-tracker. This prevents ANY tracking, clear or AdBlocking, from registering on that page. This can be changed in the options as well, including adding additional routes you may want to exclude from tracking.
 
Actually, you could set flood check to something like "900" (5 minutes). Any page views within 5 minutes would NOT count as Clear. But the next "clear" page view after 5 minutes would count as 1. Then, the same again, any "clear" page views within 5 minutes would NOT cont as Clear, but their next page view after 5 minutes would count as 1.

If they visit the next day, their first page view would count as 1 Clear page view because it's after the 5 minutes.

Note, there's also an admin option that's OFF by default: "Any AdBlock detection resets current non-detects back to zero". If enabled, it'll immediately set their "Clear" page views back to 0.

Example: The user has 5 of 9 clear page views required to remove their AdBlock status. If, on their 6th page view they re-enable their AdBlocker, or visit from a different device that has an AdBlocker enabled, they're "Clear" page views will immediately be reset to 0 of 9 required.

If the option is NOT enabled, their clear page views will remain at 5 of 9 required to clear.

Note, under either scenario their AdBlock status is AdBlocking and they remain in the AdBlocking usergroup.

After writing this out, I'm thinking the default for the flood check should be something more appropriate for typical community usage, like 30 or 60 seconds. Note, all page visits count towards tracking (except routes excluded), so while some are navigational (forum list, thread list), others are functional, thread create, thread post.
 
Last edited:
Wutime said:
Note, there's also an admin option that's OFF by default: "Any AdBlock detection resets current non-detects back to zero". If enabled, it'll immediately set their "Clear" page views back to 0.

Example: The user has 5 of 9 clear page views required to remove their AdBlock status. If, on their 6th page view they re-enable their AdBlocker, or visit from a different device that has an AdBlocker enabled, they're "Clear" page views will immediately be reset to 0 of 9 required.

If the option is NOT enabled, their clear page views will remain at 5 of 9 required to clear.
Click to expand...
Thanks for clarifying that. Enabled. It probably should be enabled by default?
Wutime said:
After writing this out, I'm thinking the default for the flood check should be something more appropriate for typical community usage, like 30 or 60 seconds. Note, all page visits count towards tracking (except routes excluded), so while some are navigational (forum list, thread list), others are functional, thread create, thread post.
Click to expand...
Before I read this, I set it to 60.

I'll install 2.2.4 PL1 and test in the morning, thanks.
 
Hi @Wutime
We're seeing errors like this:

Code: 
XF\Db\InvalidQueryException: MySQL statement prepare error [1064]: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(PARTITION BY user_id, os_type ORDER BY created DESC) AS row_num ' at line 7 src/XF/Db/AbstractStatement.php:228 
Generated by: Unknown account


Stack trace

            DELETE d
            FROM xf_wutime_adblock_tracker_device d
            LEFT JOIN (
                SELECT entity_id
                FROM (
                    SELECT entity_id, 
                           ROW_NUMBER() OVER (PARTITION BY user_id, os_type ORDER BY created DESC) AS row_num
                    FROM xf_wutime_adblock_tracker_device
                    WHERE created < (UNIX_TIMESTAMP() - (365 * 86400))
                ) AS ranked
                WHERE ranked.row_num <= 300
            ) AS preserve ON d.entity_id = preserve.entity_id
            WHERE d.created < (UNIX_TIMESTAMP() - (365 * 86400))
            AND preserve.entity_id IS NULL;
------------

#0 src/XF/Db/Mysqli/Statement.php(196): XF\Db\AbstractStatement->getException('MySQL statement...', 1064, '42000')
#1 src/XF/Db/Mysqli/Statement.php(39): XF\Db\Mysqli\Statement->getException('MySQL statement...', 1064, '42000')
#2 src/XF/Db/Mysqli/Statement.php(54): XF\Db\Mysqli\Statement->prepare()
#3 src/XF/Db/AbstractAdapter.php(94): XF\Db\Mysqli\Statement->execute()
#4 src/addons/Wutime/AdBlockTracker/Cron/Cron.php(80): XF\Db\AbstractAdapter->query('
            DE...')
#5 src/addons/Wutime/AdBlockTracker/Cron/Cron.php(13): Wutime\AdBlockTracker\Cron\Cron::deleteDeviceDetailsCron()
#6 [internal function]: Wutime\AdBlockTracker\Cron\Cron::run(Object(XF\Entity\CronEntry))
#7 src/XF/Job/Cron.php(34): call_user_func(Array, Object(XF\Entity\CronEntry))
#8 src/XF/Job/Manager.php(253): XF\Job\Cron->run(G)
#9 src/XF/Job/Manager.php(195): XF\Job\Manager->runJobInternal(Array, G)
#10 src/XF/Job/Manager.php(79): XF\Job\Manager->runJobEntry(Array, G)
#11 job.php(42): XF\Job\Manager->runQueue(false, 8)
#12 {main}
 
Dragonfruit said:
Hi @Wutime
We're seeing errors like this:
Click to expand...
Ah, that's the cron that runs to clear out old records.

Do you know what version of MySQL you're running? And whether it's MariaDB or MySQL? I suspect you're on some version of MySQL < 8.0 but want to confirm.

I can rewrite the SQL to be more version friendly.
 
Wutime said:
Ah, that's the cron that runs to clear out old records.

Do you know what version of MySQL you're running? And whether it's MariaDB or MySQL? I suspect you're on some version of MySQL < 8.0 but want to confirm.

Curious to know. I can rewrite the SQL to be more version friendly.
Click to expand...

Oh yeah, I was able to figure that from the logs and didn't think these were urgent.

It's MySQL, 5.7.x.

Thanks!
 
There will inevitably be members who have been detected blocking ads but insist that they are not using an ad blocker.
I have had an instance of this already.
What are the chances of getting a false positive?
I want to be able to write specific advice on how we and they can double check what is happening in order to come to a resolution.
I would look at their adblocking history, of course.
Do you have any suggestions?
 
Stuart Wright said:
There will inevitably be members who have been detected blocking ads but insist that they are not using an ad blocker.
I have had an instance of this already.
What are the chances of getting a false positive?
Click to expand...

Sometimes users are not aware that their traffiic is filtered.

This can be done by their company, by their provider or simply by the person who admins their internet router.
You cannot help those people, they have to find any unfiltered internet access by theirselves. In our case, they can update to an add-free paid account.

Suspected false positives are real positives. If the ad script cannot be loaded (no matter what reason) the ad block detection is triggered. Even if the person does not directly use an ad blocker with his browser.
 
Stuart Wright said:
There will inevitably be members who have been detected blocking ads but insist that they are not using an ad blocker.
I have had an instance of this already.
What are the chances of getting a false positive?
I want to be able to write specific advice on how we and they can double check what is happening in order to come to a resolution.
I would look at their adblocking history, of course.
Do you have any suggestions?
Click to expand...

I think the best case is to narrow it down and prove it first.

Ask them to show the browser's included adblock has been disabled, and have them go through the process of disabling all addons. With everything off, if it works, there's obviously an addon that's causing it. They can turn addons back on 1 by 1 to find it.
 
Stuart Wright said:
What are the chances of getting a false positive?
Click to expand...
I've never come across a false positive and can't think of a way it's even possible, so I'd like to say 100% not possible. But what's 100% in life. To be certain I'd need to know what browser and version they're using to test. But otherwise, yeah, not possible. The system assumes they're not AdBlocking unless/until they are.

What is possible, as I've found, is the complete ignorance that you're running an AdBlocker.

Assuming you have not enabled "Remote Loading Detection" and "Network Request Detection" (see screenshot), the possibilities get a bit simpler.

Off the top of my head, for simple detection:
  • They're running an AdBlocker but don't see the extension because it's not pinned
  • They're not technical and their kids installed an AdBlocker
  • They're using a browser that natively does AdBlocking and they're unaware
  • They're using some other form of AdBlocking on their device and forgot it was installed, or didn't know it was installed
Note: If you're using the other two methods of detection it get's a lot easier for the user to be honestly ignorant that their computer is AdBlocking. It could be their VPN, Raspberry Pi, DNS, and all sorts of other "behind the scenes" systems that are natively AdBlocking; despite their actual browser being clean (ie. NOT having an AdBlock extension installed).

Specific to "simple detection", I'm confident if the system is detecting them as AdBlocking, they're AdBlocking.

What's impossible to know is whether they're ignorant to the fact they're AdBlocking, or just saying they are.

Are you only running Simple Detection? If not, you should consider only enabling that option.

If possible, ask the person what OS, Device and Browser they're using and let me know.
 

Attachments

  • Screenshot 2024-08-11 at 7.31.14 AM.webp
    Screenshot 2024-08-11 at 7.31.14 AM.webp
    30.9 KB · Views: 2
You must log in or register to reply here.
Back
Top Bottom