[TAC] Fool Bot Honey Pot 3.0.32

• Moved methods around so the cache can be accessed quicker (before api calls)
• Extended so that Simple Portal, XenZine-Articles, EWR-Portal, Widget Portal can all make use of the spam-bot server resource reduction

Added an option so that the entire core forum can benefit from a reduced server usage from spam bots that attempt to hit your site many times (these spam bots ips are cached locally for x minutes, they are only cached if they have attempted to register, altered many hidden fields and done this within seconds and also have no javascript! so there is no doubt these are spam bots)

FoolBotHoneyPot_v2_3_01
Release 30/03/2014

Since we have some very good methods to detect bots without a shadow of a doubt, I've added the option to cache the known bot IP addresses locally (This is optional, and can be turned off by setting to 0)

Known bot IPs are only cached if they have modified multiple hidden fields, have no javascript detected and have attempted to register very quickly.

Using cached Known bot IP addresses, we can then use a 0 query method to 401 unauthorised, or redirect them to a page of your choice.

We can therefore stop bots that try to brute force the registration page (after detection, they will not be able to resend another attempt for 48 hours by default), we do this with a 0 query method and should reduce server impact that bots usually have when brute forcing the registration page.

If you want, you can redirect these bots to a page on your site telling them that their IP has been stored for x hours as it has been detected as a bot.

However, if you redirect them to a forum page, bare in mind, brute force bots will hit this page over an over, I recommend leaving the default 401 unauthorised page

• Cache known bot IPs of x hours
• Prevent re-attempts for x hours (optionally redirect bots / 401)

I've re-added 'AUTOCOMPLETE = "off"' back to the registration form (using template modifications) to avoid password managers (some how this was missed when converting to template modifications)

A more robust way of avoiding password manager detection. The honeypots for password/username are not only reset on page load now, but also form submit (since it seems some password managers were setting password after page load, and after reset)

FoolBotHoneyPot_v2_2_20.zip
Release 14/03/2014
Change Log:

• Added a legacy option, to use an independent registration_form template instead of template modification (this should not be needed in most cases, if any!)
• Template modifications now rely on regex, meaning the registration_form can be manipulated without issues (as long as the expected ids remain in the template)

If you make changes to your registration form, it's still recommended, any changes to the registration_form template should be done via the EXTRA.css where possible. The regex will be able to find and replace a lot of cases, but adding new nodes to the registration_form template might cause the regex to not find a match

Always check that the regex is working for this add-on when installing by checking your template modifications area (if you have made registration_form template changes):
yoursite.com/admin.php?template-modifications/

If you have not made registration_form template changes, there is no need to worry, this plugins works out of the box.

To prevent hammering of the StopBotters API, the API response is now saved in the session

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), and even if duplication of the class occurs, it does't matter since the JavaScript will update all elements of that class.

I now look for the unmodified time zone (this should have been what I was looking for in the previous version)

• If XF >= 1.2 I now use template modifications to modify the registration form. This means it should be more compatible with many more add-ons that also manipulate the registration form