XF Bot Guard 1.0.6 is now considered the first stable release of the add-on.
This release focuses on making the 1.0.x foundation safer, quieter, faster, and easier to monitor on real production XenForo forums. The core protection model remains the same, but the internal behaviour has been hardened for serious forums running conservative settings.
The main goals of this release are:
- Reducing event log noise
- Separating operational counters from audit logs
- Improving hot-path performance
- Adding clearer admin health/status visibility
- Improving cleanup and retention behaviour
- Keeping defaults conservative for stable production use
First stable release
Version 1.0.6 is the first XF Bot Guard release marked as stable.
Earlier 1.0.x versions established the core challenge flow, browser collector, trusted crawler handling, scoring model, and verification behaviour. This release hardens that foundation for broader production use.
The add-on is still disabled by default after installation, and the default operating mode remains conservative.
Operational counters are now separate from audit logs
XF Bot Guard now keeps lightweight internal counters separately from the main event log.
Previously, some scoring and rate-limit decisions relied heavily on recent rows in the audit event table. That made it harder to safely reduce noisy low-value logging, because suppressing those rows could also affect scoring visibility.
In 1.0.6, short-window operational counters are stored independently and used for decisions such as recent request activity, recent error-route activity, recent sensitive-route activity, and CAPTCHA failure rate limiting.
This means XF Bot Guard can now reduce audit log pressure without weakening the scoring and rate-limit behaviour that depends on recent activity.
Reduced event log pressure
Low-value audit rows are now controlled separately from important security and verification events.
By default, XF Bot Guard no longer writes ordinary low-value allow/skip rows for every normal safe guest request.
This helps prevent busy forums from filling the Bot Guard event table with endless routine browsing activity while still retaining useful security events.
Important events continue to be logged when audit logging is enabled, including:
- Challenge required events
- CAPTCHA pass/fail events
- CAPTCHA rate limiting
- Known crawler allow decisions
- Collector failure events
- Collector nonce/proof failures
- Hash secret or collector hash configuration problems
- Browser re-collection requests
- Error-route activity
Administrators who want the more verbose beta-style logging can re-enable low-value event logging from the Bot Guard options.
Optional allow-event sampling
A new allow-event sample rate option has been added.
This allows administrators to keep a small sample of otherwise low-value allow rows for visibility without logging every normal safe request.
For example, a busy forum can keep audit logging enabled for security events while sampling only a small percentage of routine allow decisions.
The default sample rate is 0%.
Hot-path performance hardening
Several relationship-count checks have been throttled so they are no longer recalculated on every eligible request.
XF Bot Guard still tracks useful relationship signals such as visitor/IP relationships, visitor country/ASN variation, and IP/fingerprint relationships, but these are now refreshed periodically instead of repeatedly queried on every scored request.
This reduces database pressure on normal repeat guest browsing while preserving the same general scoring signals.
Counter cleanup and retention
The new operational counter table is automatically cleaned up by the existing Bot Guard cleanup cron path.
Counter rows are short-lived and are pruned after approximately 48 hours.
This keeps the counter table focused on recent operational decisions and prevents it from growing indefinitely.
Existing event, visitor, session, fingerprint/IP, and online challenge cleanup behaviour remains in place.
New ACP health/status page
XF Bot Guard now includes an admin health/status page to make production setup easier to review.
The health page provides clear OK, warning, and error rows for important configuration and runtime checks, including:
- Bot Guard enabled/disabled state
- JavaScript collector status
- XenForo CAPTCHA configuration
- PAGE_CONTAINER template modification status
- Bundled Bot Guard JavaScript asset presence
- Bundled FingerprintJS asset presence
- Audit logging status
- Low-value audit logging status
- Allow-event sample rate
- Event, visitor, and session retention settings
- Known crawler trust status
- Known crawler origin-lockdown acknowledgement
- Approximate event table size
- Approximate counter table size
- Hash secret / XenForo global salt availability
The health page is intended to help administrators quickly confirm whether the add-on is configured sensibly before relying on it in production.
Known crawler origin-lockdown warning
This release adds a new origin-lockdown acknowledgement option for forums that enable trusted crawler handling.
Trusted crawler decisions depend on crawler-related request headers being reliable. Those headers are only trustworthy if visitors cannot bypass the proxy/CDN layer and hit the origin server directly while spoofing headers.
If known crawler trust is enabled but origin lockdown has not been acknowledged, XF Bot Guard now shows a warning in the health page.
This does not block operation. It is an admin safety warning only.
Decision timing metadata
Retained decision/security events can now include lightweight timing metadata.
This may include decision time, risk-data time, scoring time, counter time, and whether full scoring was run.
This is intended to help diagnose production behaviour without exposing debug output on public pages.
Stable defaults review
The stable defaults remain conservative.
In particular:
- Bot Guard remains disabled by default
- Guest-only protection remains the default scope
- Challenge methods remain conservative
- Known crawler trust remains disabled by default
- Hard deny remains disabled by default
- AJAX exclusion remains enabled by default
- Strict no-browser/no-grace behaviour remains enabled
- Bootstrap allow behaviour remains enabled
- Important audit logging remains enabled
- Low-value allow-row logging is disabled by default