[TAC] Fool Bot Honey Pot

[TAC] Fool Bot Honey Pot [Paid] 3.0.32

No permission to buy ($29.00)
I've modified the add-on's registration form template to include some custom terms - if I upgrade the add-on will it overwrite the template? Will I have to re-apply my changes?

Cheers,
Shaun :D
 
no, if you have made changes it wont overwrite them
For any plugin, you need to update templates that have been modified individually

Copy out your template to a text file (just in case). For this version, there have been no changes to the registration template, so it shouldn't even need to update it.
But if you are updating from an older version, I would recommend updating the registration template ( 2.1.0.4 : Minor Fix For Password Managers, contained some registration template changes)
 
Since the standard XF regform is replaced(extended?) by FBHP, how would we implement http://xenforo.com/community/resources/add-icons-to-your-registration-form.1399/ on our FBHP reg forms?

In exactly the same way (add it to your extra.css), the fields all use the same class names as before

Actually, it's going to be harder, give me a minute

In that example, the extra css is targeting the field names (these have all of course been changed since the standard fields names are now honey pots)

To do this, you need to add a class to each of the real fields, but you need to know which ones are real

The real fields in the template are named:
$uuids.1 // visible username
$uuids.2 // visible email
$uuids.3 // visible password
$uuids.4 // visible password_confirm
$uuids.5 // visible timezone
$uuids.6 // visible gender

The actual names of the real fields change every time the page is loaded (making it very hard to inject text into). For this reason, they also can't be targeted with css

So, to change the style of the username, update the following template: Foolbothoneypot_uuid1_namefield1

and add ctrl_username to the class, like so:

Code:
<dl class="ctrlUnit">
    <dt><label for="ctrl_{$uuids.1}">{xen:phrase name}:</label></dt>
    <dd>
        <input type="text" name="{$uuids.1}" value="{$fields.uuid1}" class="textCtrl ctrl_username" id="ctrl_{$uuids.1}" autofocus="true" autocomplete="off" />
        <p class="explain">{xen:phrase this_is_name_that_will_be_shown_with_your_messages}</p>
    </dd>
</dl>

and then in extra.css, add (note the dot, not a #):


.ctrl_username {
background-image:url(linktoiconhere);
background-position:8px;
background-repeat:no-repeat;
}

You can then repeat the same logic for each of the other fields.
Location of 'real' visible fields:

username is in template: Foolbothoneypot_uuid1_namefield1
email is in template: Foolbothoneypot_uuid2_emailfield1
password is in template: Foolbothoneypot_uuid3_4_passfield
password_confirm is in template: (also) Foolbothoneypot_uuid3_4_passfield
timezone is in template: Foolbothoneypot_uuid5_timezfield
gender is in template: Foolbothoneypot_uuid6_genderfield
 
Is there any plans to allow the manual reporting of spammers from the logs into StopBotters?
Example: FBHP allow a registration as it detects as human. That account then spams and is banned. From /admin.php?foolbothoneypot/logs it would be good to have a 'submit' button (eg, just below the delete button in the top right corner) against the registration record to be able to submit these account/registration details to StopBotters.
 
I've never trusted and never will trust human added data... .sorry to all those that are human out there.

I think you'll need a different approach for humans (an additional mechanism/plugin/api).
I will be looking at Human Spam (but it will be a different plugin)

One of the things I've seen with Human reporting on anti spam APIs, is the huge amount of false positives
StopBotters does not surfer this... it's very clean and detects a high percentage of bots
As soon as we allow human reporting, it wont be as clean

StopBotters / StopProxies does avoid human errors being introduce by humans falsely reporting IP addresses (maliciously or accidently) as a bot. I've seen this over and over on most anti-spam API's, the reason for this is the introduction of human reporting, or incorrect use of their reporting mechanism. That can not happen with StopBotters/StopProxies, nobody has access to use it or manually report forum users to it

It's also a closed network, nobody can query that database or use the database apart from XenForo forums. The reason for this is that it has been noticed that the effectiveness of many API's has started to dwindle and will continue to slip as more XRumer users use the open networks to know when to change their settings, or use things such as Xblack.txt, this allows the spam bots to go unnoticed for much longer.

By removing the information from the bot users, making the methods unobtainable and not making the data public we put XenForo users that use StopBotters in a much stronger position
 
StopBotters does not surfer this... it's very clean and detects a high percentage of bots
Maybe, but I'm considering turning it off and am querying it's value. I've not had one StopBotters detection is recent weeks that hasn't been detected by no javascript and hidden fields completed. Since it's providing no value for human/manual spammers, I see little point in slowing down registration checks with StopBotters when the other FBHP inbuilt methods are successfully detecting them all.

As soon as we allow human reporting, it wont be as clean
I disagree, completely. There is no substitute for human validation/reporting. The anti-spam service provider just needs to be smart about it and only allow reports from approved developer add-ons. Such add-ons would only allow reporting under defined constraints, ensuring that the account information and matching registration information as well as the offending posted message was included in the human/manual spam report, for review and acceptance And the add-on has further constraints such as the account being submitted as a spammer has already been banned on the submitting XF system and can only be done via the admin control panel etc. If you properly constrain your human reporting, and perform final validation, then the data remains clean - probably cleaner than via automated reporting from bot detection.
 
Maybe, but I'm considering turning it off and am querying it's value. I've not had one StopBotters detection is recent weeks that hasn't been detected by no javascript and hidden fields completed.
That's true, since the mechanisms in FoolBotHoneyPot already detect 100% of bots, the API only really confirms what you already know... it's a bot.
There is a chance that bots might learn to get around the mechanism, in which case StopBotters will still detect a high % of them


I disagree, completely. There is no substitute for human validation/reporting
We'll have to agree to disagree, keeping it clean and preventing any false positives ever being introduced is essential for StopBotters,
it is targeting bots after all, and we already have mechanisms that detect bots... something different will be needed to stop human spammers

... I have started a free resource for adding Any Api which I will release shortly
 
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolBotHoneyPot : Fix when using XenUtils (non spam) utilities side by side

  • Added a fix related to XenUtils (if XenUtils was installed, it expect a timer field within the template, this was causing the XenUtils error: Your registration was rejected due to a security error; press back, refresh the page and try again
  • Keep in mind, AnyApi (free) should be used for the AntiSpam Apis settings

Read the rest of this update entry...
 
From v2.2.01 I'm getting log block/stopped entries in both FBHP and AnyAPI for the same registration attempt. I would have thought that if the registration form failed under FBHP then there would need for a lookup via AnyAPI? Or do I require the "Dont check API if captcha fails" ticked/selected for this?
 
That's right, they work together ...

The reason for this is so you can compare every API's statistics... (some people want to compare API's)

The logs that you see in AnyApi are different to FBHP, AnyApi logs tell you what the response from the API was and how your logic interpreted this
The logs in FBHP tell you ... it was found via mechanism x.. and it's spam

In FBHP logs, when a bot is found, it will often be found via many FBHP mechanisms and many API's (this gives the forum Admin confidence that the user was in fact a bot / spammer)


There is already an option in AnyApi: if failed CAPTHCA, do not bother with API's. If this option is ticked and you have a CAPTCHA, it will get rid of the vast majority of unnecessary/"confidence building" additional API checks (if you using CustomImgCaptch, most bots will fail this, if your using ReCaptcha /QA...or a common CAPTCHA, bots could potentially pass the CATPCHA)

I could extend AnyApi further (which seems to be what you are asking):
1) If failed via FBHP, do not bother with API's (If FBHP is installed)
2) Stop checking APIs on finding the 1st failed API

Personally, I wouldn't bother using more than one good API, since FoolBotHoneyBot stops 100% bots, I use FBHP + StopBotters (bot verification) + StopForumSpam only (for human spam)... there is generally no need for multiple APIs (and can slow the experience for real users), but some forum admins feel more confident with multiple API's (and have requested them), and they feel more confident with multiple fails from various mechanism + apis

A fail in only one mechanism, or only one API will still prevent the bot/spammer from registering
 
I could extend AnyApi further (which seems to be what you are asking):
1) If failed via FBHP, do not bother with API's (If FBHP is installed)
Yes, this is what I was intending. Another tick on /admin.php?options/list/anyApi to not do API's if failed by FBHP, if the admin so desires (that would be me, I have confidence in FBHP, so am only looking at API for human spam checks)

Personally, I wouldn't bother using more than one good API, since FoolBotHoneyBot stops 100% bots, I use FBHP + StopBotters (bot verification) + StopForumSpam only (for human spam).

Yes, my config too. I turned off API's for Bot Scout (dreadfully ****e), and Spam Busted is slightly lower in pickups than StopForumSpam.
 
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolBotHoneyPot - Dont Check Apis if Detected via FBHP Option + Fixes

  • Now when selecting the option "Don't Check APIs if Bot is Detected via FBHP" in AnyApi, there will be no API checks (apart from StopBotters if turned on) when FoolBotHoneyPot detects the user as a bot. You will need the latest version of AnyApi (1.0.2). So if the API is turned on, but failed by FBHP, the FBHP will just display "detected on .. : FALSE"
  • Removed additional empty template fields in FBHP ACP options to control additional APIs (these did nothing and were only there until...

Read the rest of this update entry...
 
Yes, this is what I was intending. Another tick on /admin.php?options/list/anyApi to not do API's if failed by FBHP, if the admin so desires (that would be me, I have confidence in FBHP, so am only looking at API for human spam checks).

Done, it doesn't turn off StopBotters, but turns off any of the APIs defined in AnyApi if detected as a bot by FBHP (this is a tickbox option in the ACP)
So... they will only show up as "Detected on [API NAME]" : False In the FoolBotHoneyPot logs, and will not show up at all in the AnyApi logs (unless they have not been detected by the FBHP mechanism)


You'll need to updgrade both FBHP and AnyApi for this update
 
Top Bottom