[TAC] Fool Bot Honey Pot

[TAC] Fool Bot Honey Pot [Paid] 3.0.32

No permission to buy ($29.00)
DOB is never modified via FBHP, so it can't be that
I've changed execution order, just in case another add-on tries to update the standard template before fbhp makes the changes

If you have made template edits to the registration_form, can you revert them

@giorgino can you try upgrading with this XML:
 

Attachments

I'm getting the same error - no modifications to the registration form. It appears it's detecting the time zone field as a hidden field and despite me having a valid time zone in there as it believes it is a hidden field it is rejecting registrations.

--------------------------------------------
Please correct the following errors:
  1. Sorry, you've been detected as an automated program (a bot), if you believe this is a mistake, please contact the administrator(s) for this forum
  2. Please select a valid time zone.
--------------------------------------------

Hidden Fields Modifed, FoolBotHoneyPot: Detected As A Bot - Registration Blocked
A moment ago
generated_by_username_attempt: testaccount
generated_by_email_attempt: testaccount@testdomain.com.au
IP Address: x.x.x.x:60417
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; MAAU; rv:11.0) like Gecko
Time Taken To Register: 32 (seconds)
Basic Proxy Detection: No Proxy Detected
JavaScript Enabled: TRUE
Browser Plugins Detected: flash=12
Altered Hidden Fields
timezone => Australia/Brisbane

Registration Errors
fbhp => foolbothoneypot_sorry_youve_been_detected_as_an_automated_program
timezone => please_select_valid_time_zone
--------------------------------------------
 
timezone => please_select_valid_time_zone
--------------------------------------------

Okay, thanks .. we are getting somewhere

timezone => please_select_valid_time_zone

This implies that time zone has not even been switched to the fbhp version (there are no hidden fields for timezone?),
possibly since it has not found this in your registration_form template (can you check to see if it is there, exactly as show):

Code:
<dl class="ctrlUnit" style="display: none">
        <dt><label for="ctrl_timezone">{xen:phrase time_zone}:</label></dt>
        <dd>
            <select name="timezone" class="textCtrl {xen:if $fields.timezoneAuto, 'AutoTimeZone'} OptOut" id="ctrl_timezone">
                <xen:foreach loop="$timeZones" key="$identifier" value="$name">
                    <option value="{$identifier}" {xen:selected "{$identifier} == {$fields.timezone}"}>{$name}</option>
                </xen:foreach>
            </select>
        </dd>
    </dl>


Can you send me a link to your forum (with FBHP switched on if possible)
 
Last edited:
damn it, it was me who had made the modification to my template

I should have been searching for this

Code:
<dl class="ctrlUnit">
        <dt><label for="ctrl_timezone">{xen:phrase time_zone}:</label></dt>
        <dd>
            <select name="timezone" class="textCtrl {xen:if $fields.timezoneAuto, 'AutoTimeZone'} OptOut" id="ctrl_timezone">
                <xen:foreach loop="$timeZones" key="$identifier" value="$name">
                    <option value="{$identifier}" {xen:selected "{$identifier} == {$fields.timezone}"}>{$name}</option>
                </xen:foreach>
            </select>
        </dd>
    </dl>

(no style="display: none")

I'll search for both and update this plugin, yes that last version is void :oops:
 
Last edited:
If you installed 2.2.17, un-install and install 2.2.17b

-- People, you need to complain if it doesn't work (that way I can confirm it's happening with every install, and not related to other add-ons / template mods)
15 quick downloads, but only 2 mentioned the issue, so I assumed it was a plugin/modification

... thanks for letting me know those that found the issue

Should be fixed, but always test a manual registration after updating this plugin (it worked fine for me, since I did have display:none for the timezone)

template modifications can be seen here
yoursite.com/admin.php?template-modifications/

7 out of 8 of the fbhp template registration_form modifications should be applied
 
Last edited:
If you installed 2.2.17, un-install and install 2.2.17b

-- People, you need to complain if it doesn't work (that way I can confirm it's happening with every install, and not related to an other add-on / template mod)
15 quick downloads, but only 2 mentioned the issue, so I assumed it was a plugin/modification

... thanks for letting me know those that found the issue

Should be fixed, but always test a manual registration after updating this plugin (it worked fine for me, since I did have display:none for the timezone)

The upgrade won't work if we just simply upgrade it? I just upgraded 11 sites using the upgrade method. Do I need to uninstall and upgrade those 11 again?
 
Just uninstalled and reinstalled on one site and get this in my template modifications area:

Screenshot 2014-02-20 06.05.43.webp

Looks like the last one didn't apply?
 
Yeah, that's fine.. since it is caught by timez_field_hidden (you seem to do the same as me). You should be able to register without issues...

I didn't realise you could see these modification, but thats' a good way of telling it's set-up correctly.
All of them should be applied (apart from 1). Only one of the timez_field_hidden or timez_field needs to be applied
 
Last edited:
Just uninstalled 2.2.16 and reinstalled 2.2.17b

I made a registration test and i get this error :

Hidden Fields Modifed, FoolBotHoneyPot: Detected As A Bot - Registration Blocked
11 minutes ago
generated by username attempt: testaccount
generated by email attempt: test@testdomain.com
IP Address: xx.xxx.xxx.xxx:xxxxx
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Time Taken To Register: 30 (seconds)
Basic Proxy Detection: No Proxy Detected
JavaScript Enabled: TRUE
Browser Plugins Detected: flash=12,java=10
Altered Hidden Fields
password => mypassword

Registration Errors
fbhp => foolbothoneypot_sorry_youve_been_detected_as_an_automated_program

Template modification :

templatemodification.webp
 
Last edited:
That's strange, you have a value of 2, it should be 1..
Doesn't the 2 imply the match has been found twice (that is strange)

The 3 numbers indicate the number of times the modification matched (green), the number of times the modification failed to match (grey) and the number of times the modification caused an error (red).

I don't think those counts of 2 are due to this (since this was fixed)
http://xenforo.com/community/threads/admin-template-modifications-counters.62753/

@kezako Do you know of any reason why these areas might have matched twice (It's as if you registration_form template is being displayed twice on the same page?), I have a feeling one of your add-ons might be forcing all templates to renderer twice (I might be completely wrong, and it might be something else, this is just a guess at the moment)

I tried to register on your forum, and registered successfully (So, I assume you must have rolled back to a previous FBHP version)

If you try switching each of your add-ons off one at a time, does this green value suddenly drop to the value 1, if so which add-on does this occur with?
 
Last edited:
Registration work now.

About count of 2, i try to disable all add-on and there is alway 2
Peraps problem come from the UI.X theme

templatemodification2.webp
 
@kezako think I have identified your issue


I have seen why this might happen on your registraion_form page, but not any others


On your registration form, in the html source, you have an extra bit of code:

Code:
        <dl class="ctrlUnit">
            <dt>
                <label for="ctrl_password">Do you already have an account?</label>
            </dt>
            <dd>
                <ul>
                    <li><label for="ctrl_not_registered"><input type="radio" name="register" value="1" id="ctrl_not_registered" tabindex="105" />
                        No, create an account now.</label></li>
                    <li><label for="ctrl_registered"><input type="radio" name="register" value="0" id="ctrl_registered" tabindex="105" checked="checked" class="Disabler" />
                        Yes, my password is:</label></li>
                    <li id="ctrl_registered_Disabler">
                        <input type="password" name="password" class="textCtrl" id="ctrl_password" tabindex="102" />
                        <div class="lostPassword"><a href="lost-password/" class="OverlayTrigger OverlayCloser" tabindex="106">Forgot your password?</a></div>
                    </li>
                </ul>
            </dd>

The problem is , this shouldn't be here on the registration form, and it certainly shouldn't have an id of ctrl_password and ctrl_confirm_password since these are already used in the registraion_form:

Code:
<fieldset>
    <dl>
        <dt><label for="ctrl_password">Password:</label></dt>
        <dd><input type="password" name="password" class="textCtrl OptOut" id="ctrl_password" autocomplete="off" value="xxxxxx" readonly="readonly" /></dd>
    </dl>
    <dl class="zro ctrlUnit">
        <dt><label for="ctrl_confirm_password">Confirm Password:</label></dt>
    <dd>
        <input type="password" name="password_confirm" class="textCtrl OptOut" id="ctrl_confirm_password" autocomplete="off" value="xxxxxx" readonly="readonly"/>
        <p >Enter your password in the first box and confirm it in the second.</p>
    </dd>
    </dl>
</fieldset>

ID's should NEVER be used more than once in the page, element ids should be unique, and it might explain why your password was remembered by your browser, this bit of code by fbhp:
$('#ctrl_password').val('xxxxxx');
$('#ctrl_confirm_password').val('xxxxxx');
Would not have known which id to set, since there should only ever be one element with the id ctrl_password

- What this bit of code does, is essentialy reset the default hidden password. This value is already set, but the script sets it too (just in case the browser remembers it from previous attempts, or somebody tries to use a password manager.. we then prevent any human issues... the script will always reset the hidden field)

But, it can't do this if there are 2 elements on the page with the same id (this is also invalid html... talking of which, I've just seen an open class I need to close)


So, where does the above bit of code come from, does it come from the style IU.X?

You can tell this by turning the style on and off and looking for that bit of source code, does the id "ctrl_password" still occur twice in the source? It should never occur twice

- I would usually fix other things even to support other add-ons, but in this case, an important ID appearing twice on the page is fairly hard for me to work around. I think the designer that added that bit of code via their add-on may need to solve this issue for you (IDs should always be unique for a given page, otherwise js issues like these are unavoidable)

I haven't rolled this out in the free / pack releases yet.. but I will, and it's an issue that needs to be solved.
 
Last edited:
There is a way around this.

I could add my own dummy class (I shouldn't have to since IDs should always be unique, see http://www.w3.org/TR/html5/dom.html#the-id-attribute). Since other add-ons might also make the mistake of adding elements with the same ID values that already exist on the page, I want to avoid having to worry about this.

So now, I simply add a dummy class to the honeyPots:

.honeyPass .honeyConfirm .honeyEmail .honeyUsername

These classes do nothing, other than allow me to select them to reset the honeypot elements back to default. They will never exist twice on the page, and even if they should exist twice, the script selects all members of the class

So now, even if another add-on (for what ever reason) adds elements that have non unique ids, we no longer have any dependency on the id (better compatibility even for other add-on strange behaviour)

In short: FBHP is now more robust even if other add-ons commit duplication of ids

@kezako by the way, the 2 value I think was a red herring (don't worry about it)
 
Last edited:
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

Avoid dependency on IDs (other add-ons have abused unique IDs in the past)

Resetting the default values of the honey-pot fields no long relies on IDs.

Even though element IDs should be unique, some plugins were abusing this. This meant, it's very hard to know which element the JavaScript is actually pointing to. To avoid this, I now add a honey-pot class to the honey-pot fields I want to reset. This means, I no longer have dependence on IDs (other plugins can abuse away without affecting FBHP),...

Read the rest of this update entry...
 
Last edited:
@kezako this issue wasn't caused by FBHP (it was causes by a duplication of a unique identifier from another add-on). However, the above release will probably fix it ;)
 
Not sure if this has been requested or not, but any chance to add an ip address to the ban list after X registration attempts blocked?
 
Not sure if this has been requested or not, but any chance to add an ip address to the ban list after X registration attempts blocked?

Using the core banned IP address (and email addresses):

yoursite.com/admin.php?banning/ips
yoursite.com/admin.php?banning/emails

This might result in a very long list (and will keep building up) are you sure this is a good idea (in the last couple of months StopBotters has stopped over a million unique bot attempts)

Currently repeat offenders are blocked automatically by an API (stopbotters), consider this like a shared list of IPs/Emails that are banned. These IP's get dropped every few weeks from the API (so, IP addresses that were once used by bots, and are now used by humans do not get picked up as bots) <= Avoids false positives that so many other APIs seem to suffer with

However, a local list should be quicker than an API request, I'm just not sure it is a good idea to use the core lists like this
1) It will build up into a large list very quickly (making the APC area hard to manage)
2) The IPs don't get dropped automatically from your local database (so banned IPs would remain banned, even its old and now used by a human)

- I'm not sure using the core banned IPs / emails to store these locally is a good idea. However, maybe extending the existing FBHP one, and use the core banned functionality

I'm not sure if you know this, but one already exists. The stopbotters API response remains stored in the database for 5 minutes (to prevent repeat API requests)
- I could use a similar method to optionally ban the user too (and extend the time to an optional period - 1 day - X days)
 
Top Bottom