XF Bot Guard 1.4.1

This is a minor maintenance release that refines how XF Bot Guard reports visitor activity within XenForo.

• Prevented the background browser verification collector from appearing as a visitor’s current page in XenForo’s online activity displays.
• Improved activity reporting so genuine visitors are less likely to appear as though they are viewing an internal verification endpoint while browsing normally.
• No challenge behaviour, verification logic, or visitor tracking decisions have been changed in this release.

New Bootstrap History Protection​

This update adds a new behavioural protection layer for clients that repeatedly receive bootstrap access but never complete normal browser verification.

This is designed to reduce cases where rotating-IP crawlers or scrapers repeatedly appear as fresh visitors and continue receiving short-lived bootstrap allowance without ever behaving like a real browser.

Behaviour-based bootstrap suppression​

XF Bot Guard now tracks recent bootstrap allowance history against normalised user-agent identities and broader user-agent families.

If the same client identity repeatedly receives bootstrap access but never completes fingerprint collection, XF Bot Guard can suppress further bootstrap allowance and send the request through the normal challenge flow instead.

This is intentionally not a user-agent allowlist or blocklist.

Code:

Repeated bootstrap access
+
No successful browser collection
=
bootstrap suppressed and normal challenge handling applies

No user-agent trust​

This feature does not trust user-agent strings as proof of identity.

User-agent data is only used as a behavioural correlation signal after cheaper and more direct checks have already run.

A user-agent string alone does not create an allow decision, and this update does not add manually maintained crawler names or crawler-specific user-agent rules.

Challenge flow integration​

The new check runs late in the Bot Guard decision flow, just before bootstrap grace would otherwise be started.

If recent history shows repeated bootstrap-only behaviour with no successful browser collection, XF Bot Guard adds a risk reason and lets the normal challenge decision continue.

This keeps the protection model consistent: legitimate browsers that complete collection are not treated the same as clients that repeatedly consume bootstrap access without ever producing browser proof.

Event log visibility​

When bootstrap allowance is suppressed by this new history check, XF Bot Guard logs:

Code:

bootstrap_suppressed

Relevant risk reasons may include:

Code:

ua_bootstrap_only_history
ua_family_bootstrap_only_history

These entries can help administrators understand when Bot Guard is challenging a request because that client identity or family has repeatedly failed to complete browser verification after receiving bootstrap access.

No new setup required​

This feature uses XF Bot Guard’s existing rolling counter system.

It does not add a new database table, admin option, cron entry, or setup step.

After upgrading, the protection begins working automatically as new request history is collected.

This is a minor maintenance release that fixes an issue where XF Bot Guard could be too quick to challenge some genuine visitors before browser verification had been fully established.

• Improved browser verification continuity so genuine visitors are less likely to be asked to verify again while browsing normally.
• Strengthened handling for clients that do not support JavaScript or cookies, so repeat automated requests are challenged more reliably.
• Refined visitor tracking logic for better consistency across sessions, devices, and browser behaviour.

Verified Crawler/Fetcher IP Allowlist & Counter Cache Optimisation​

This update adds XF Bot Guard’s own DB-backed verified crawler/fetcher allowlist, along with a XenForo cache-backed counter optimisation to reduce repeated database reads where a XenForo cache is configured.

This release bundles the 1.0.7 crawler/fetcher allowlist work together with the 1.0.8 counter cache improvement, so 1.0.7 has been skipped as a separate public release.

Version note: 1.0.7 was bundled into 1.0.8​

A 1.0.7 release was originally planned for the verified crawler/fetcher IP allowlist work.

Before public release, that build was held back so the counter cache optimisation could be completed and bundled into the same update.

As a result, there is no separate public 1.0.7 release. The 1.0.8 release includes both sets of changes:

• The DB-backed verified crawler/fetcher IP allowlist originally planned for 1.0.7
• The XenForo cache-backed counter optimisation added for 1.0.8

This avoids releasing two back-to-back updates and gives administrators both the crawler handling improvement and the database read-load reduction in one upgrade.

New verified crawler/fetcher IP allowlist​

XF Bot Guard can now allow requests from known official crawler/fetcher IP ranges before normal Bot Guard risk scoring and challenge handling.

The new decision rule is simple:

Code:

Request IP is inside an enabled official crawler/fetcher CIDR source
=
allow

This does not rely on user-agent strings, reverse DNS, or spoofable request headers.

The request IP is checked locally against DB-backed IP ranges populated from official provider-published JSON feeds.

Official crawler/fetcher sources​

This first version only includes sources with strong automation quality.

Included sources are:

• Google common crawlers
• Google special-case crawlers
• Google user-triggered fetchers
• Google-controlled user-triggered fetchers
• Google user-triggered agents
• Bingbot
• Applebot
• DuckDuckBot

These sources are provider-published, publicly accessible, machine-readable JSON feeds containing IPv4 and/or IPv6 CIDR ranges.

This update does not add support for Yandex, Baidu, Ahrefs, Semrush, Moz, AI crawlers, commercial SEO tools, DNS-only verification, user-agent-only verification, or manually maintained crawler lists.

New verified crawler option​

A new option has been added:

Code:

zeeBotGuardAllowVerifiedCrawlers

Admin label:

Code:

Allow verified search crawlers and fetchers

Default:

Code:

Enabled

This option is separate from the existing upstream/header-based known bot option:

Code:

zeeBotGuardAllowKnownBots

The older known bot option continues to handle trusted upstream verified-bot headers where administrators have a controlled proxy/CDN environment.

The new verified crawler option uses local DB-backed IP range matching from official provider feeds and does not require trusting request headers.

Automatic source refreshing​

XF Bot Guard now stores official crawler/fetcher source definitions and imported IP ranges in dedicated database tables.

A new cron entry refreshes the official sources automatically:

Code:

zeeBgKnownCrawlerRefresh

The refresh system is designed to be conservative and safe.

Successful source refreshes replace that source’s ranges transactionally. Temporary provider failures, invalid JSON, empty source updates, or failed refresh attempts do not wipe existing last-known-good ranges.

This means a temporary Google, Bing, Apple, or DuckDuckGo feed issue should not suddenly cause legitimate crawlers to be challenged again if valid data was already imported previously.

No request-time remote checks​

Normal request handling does not perform remote verification.

For eligible protected page requests, the new verified crawler path performs:

• One local indexed DB lookup
• No HTTP requests
• No DNS lookups
• No reverse DNS checks
• No user-agent verification
• No request-time CIDR parsing

This keeps the runtime path cheap and avoids delaying real visitors or crawlers due to remote provider lookups.

Challenge flow integration​

Verified crawler/fetcher IP matching now happens before Bot Guard risk data collection and scoring.

If the request IP matches an enabled official crawler/fetcher range, XF Bot Guard allows the request and logs the decision.

This is intentionally an allow decision rather than a risk-score reduction. A verified official crawler/fetcher should not be challenged just because it lacks normal browser-style signals such as JavaScript proof, stable browser fingerprinting, or CAPTCHA capability.

Requests that do not match an official range continue through the normal Bot Guard flow.

User-agent strings alone never create an allow decision.

Event log visibility​

Allows made by the new verified crawler/fetcher IP allowlist are logged with this event type:

Code:

verified_crawler_allow

Administrators can search the XF Bot Guard event log for:

Code:

verified_crawler_allow

The event metadata includes details such as:

Code:

provider
source_id
source_label
cidr
source_age_seconds
verification

Example metadata:

JSON:

{
    "provider": "google",
    "source_id": "google_common_crawlers",
    "source_label": "Google common crawlers",
    "cidr": "66.249.64.0/19",
    "source_age_seconds": 3600,
    "verification": "official_cidr_json"
}

This is separate from the existing upstream/header-based known crawler event:

Code:

known_crawler_allow

For the new verified official IP source feature, the event to check is:

Code:

verified_crawler_allow

Health check visibility​

The XF Bot Guard health check now includes visibility for the verified crawler/fetcher source system.

The health check reports:

• Whether verified crawler/fetcher allowing is enabled
• Known crawler source table status
• Known crawler range table status
• How many official sources are enabled
• How many sources have refreshed successfully
• Whether any enabled sources have never refreshed
• Whether any source data is stale
• Whether any recent refresh attempts failed
• Whether any known crawler ranges are currently available

After upgrading, administrators should check the XF Bot Guard health check and confirm that the official IP sources imported successfully.

If the option is enabled but no known crawler ranges are available, the feature will not allow crawler/fetcher visits until the official sources successfully refresh.

New database tables​

This release adds new database tables for the official source definitions and imported crawler/fetcher IP ranges.

These tables are created and lifecycle-managed by the add-on setup process.

The add-on seeds the official source rows automatically and attempts a best-effort initial import during install or upgrade.

If the initial remote import fails, install/upgrade should still complete. The health check will report the issue, and the scheduled refresh cron can import the sources later.

Source validation and safety​

Imported CIDR ranges are parsed and validated before being stored.

XF Bot Guard rejects invalid, empty, private, local, reserved, multicast, documentation, shared, or special-use ranges.

A source update with zero valid public ranges is rejected and does not replace previously known-good data.

The new system does not fall back to user-agent trust if official IP source matching is unavailable.

Counter cache optimisation​

XF Bot Guard’s internal counter store now uses XenForo’s configured cache where available to reduce repeated database reads for short-window counter checks.

This is used for Bot Guard’s rolling counter buckets, such as repeated request/event counts used during risk evaluation.

The counter store remains database-authoritative.

Counter increments are still written to the database first. Where a XenForo cache is available, the updated bucket value is then written through to cache.

Counter reads now attempt to read the relevant bucket values from cache first. If all required buckets are present, XF Bot Guard can calculate the total without querying the counter table. If only some buckets are missing, it fetches the missing buckets from the database and fills the cache for future reads.

If no XenForo cache is configured, or if the cache is unavailable, XF Bot Guard safely falls back to the existing database-backed behaviour.

Read-through and write-through cache behaviour​

The new counter cache behaviour is intentionally conservative.

• The database remains the source of truth
• Increments still use database upserts
• The updated bucket value is captured after the database write
• Cache entries are written after successful database updates
• Reads use cached bucket values where available
• Missing buckets are read from the database and then cached
• Cache failures do not break Bot Guard request handling
• Sites without a configured XenForo cache continue using the database path

This is intended to reduce repeated read load on the counter table without weakening the protection model or making cache availability required.

No new cache option​

There is no new XF Bot Guard admin option for the counter cache.

XF Bot Guard simply uses XenForo’s configured cache where available.

Sites already using a XenForo cache provider such as Redis or Memcached may benefit automatically.

Sites without a configured XenForo cache do not need to change anything; XF Bot Guard will continue using its existing database-backed counter behaviour.

See XenForo Cache for more information.

Setup and upgrade handling​

The setup process now creates and repairs the crawler source/range tables, seeds the official source definitions, ensures the new refresh cron exists, and attempts a best-effort initial source refresh.

Upgrade handling preserves existing source refresh state and last-known-good ranges where possible.

Uninstall removes the new known crawler source/range tables along with the existing Bot Guard tables.

The counter cache optimisation does not require a new database table, a new admin option, or a separate setup step.

Security model​

The verified crawler feature intentionally does not trust:

• User-agent strings
• Reverse DNS
• Spoofable request headers
• Manual crawler names
• Manual IP lists
• Request-time provider lookups

The trusted signal is:

Code:

Raw request IP matches an official provider-published CIDR range stored locally in the database

This keeps the new feature independent from Cloudflare or other upstream verified-bot headers while avoiding weaker user-agent based allowlisting.

The counter cache optimisation does not change the trust model. It is a performance optimisation only.

Admin action recommended​

After upgrading, administrators should check the XF Bot Guard health check to confirm that the official crawler/fetcher sources imported successfully.

The new verified crawler option is enabled by default:

Code:

zeeBotGuardAllowVerifiedCrawlers

To confirm the verified crawler feature is actively allowing visits, check the Bot Guard event log for:

Code:

verified_crawler_allow

No manual IP ranges or crawler names need to be configured.

Administrators who want the counter cache optimisation to be active should ensure XenForo’s cache is configured at the XenForo level. No XF Bot Guard-specific cache setting is required.

XF Bot Guard 1.0.6 — First Stable Release & Production Hardening​

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

This release favours predictable operational behaviour over aggressive new detection ideas.

Database schema change​

This release adds a new internal table:

Code:

xf_zee_botguard_counter

This table stores short-lived operational counters used for scoring and rate-limit decisions.

The table is maintained automatically by XF Bot Guard and cleaned up through the existing cleanup process.

Recommended admin review after upgrade​

After upgrading, administrators should review and save the Bot Guard options, as new options have been introduced.

Administrators using trusted crawler handling should also confirm their proxy/CDN and origin-server setup prevents direct origin access before acknowledging origin lockdown.

Administrators who previously relied on very verbose allow-row logging can re-enable low-value event logging or configure allow-event sampling in the Bot Guard options.

Administrations should also review the new Bot Guard health/status page, linked to from the logs page.

Summary​

XF Bot Guard 1.0.6 is a stability and production-readiness release.

It reduces routine event log growth, moves scoring counters out of the audit log, lowers hot-path database pressure, adds better admin visibility, improves retention behaviour, and keeps the default configuration conservative.

This is the recommended stable foundation for production XenForo forums using XF Bot Guard.

Redirect, Collector Hardening & Verification Flow Improvements​

This update improves XF Bot Guard’s verification flow, browser collector integrity, trusted crawler handling, and XenForo integration polish without changing the core protection model.

Fixed post-CAPTCHA return behaviour​

Fixed an issue where visitors who completed CAPTCHA could be returned to the forum homepage instead of the original page they were trying to access.

XF Bot Guard now preserves the originally requested safe URL through the challenge flow and returns the visitor to that page after successful verification.

This includes first-visit and new-session challenge flows, such as visitors opening a protected thread or forum page before they already have an established forum session.

Unsafe return targets are rejected automatically, including external URLs, Bot Guard routes, login/logout/register routes, API routes, admin/install paths, webhook-style paths, payment callback-style paths, and malformed values.

If the original return URL is missing or unsafe, XF Bot Guard safely falls back to the forum index as before.

Improved trusted crawler handling​

Known allowed crawler detection now works as a true allow decision when trusted crawler handling is enabled.

Previously, known crawler detection reduced the risk score but could still result in a challenge if the request scored highly enough for other reasons.

XF Bot Guard now still calculates and logs the score for observability, but verified known crawler requests can be allowed at the decision layer rather than being challenged unnecessarily.

This keeps crawler handling visible in the event log while making the trusted crawler setting behave more consistently.

Collector proof and replay hardening​

The browser collector now uses short-lived server-issued proof to better bind collector submissions to the current page, session, and timing window.

This makes collector submissions harder to replay or synthesize independently from a genuine page load.

Collector proof is validated before browser metadata is accepted as trusted collector evidence. Invalid, expired, reused, missing, or mismatched collector proof is handled safely and logged for observability.

This hardening is designed to fail safely without breaking normal page loads.

Suspicion-triggered browser re-collection​

XF Bot Guard can now request fresh browser collection when request context changes in ways that may make older collector metadata less reliable.

Examples include:

• User-Agent family changes
• Country changes
• ASN changes where available
• Stale collector metadata
• Suspicious route families
• Collector metadata missing despite an existing visitor fingerprint
• Fingerprint/session relationship inconsistencies

This does not immediately force CAPTCHA by itself. It provides a middle step where XF Bot Guard can refresh browser evidence before escalating to a challenge.

Conservative route-family scoring​

This update adds a small route-family risk layer for routes commonly associated with scraping or enumeration behaviour.

Examples include:

• Search pages
• Find-new / what’s-new style pages
• Member list and profile enumeration
• Deep pagination
• Repeated listing or index traversal

These are modest supporting risk factors only. They are designed to improve explainability and scoring accuracy without dominating the full risk score on their own.

Safer hash-secret behaviour​

Removed the predictable fallback hash secret path.

XF Bot Guard now uses the configured Bot Guard hash secret where available, or XenForo’s global salt where available.

If neither is available, XF Bot Guard avoids generating predictable hashes, fails open for visitor access where appropriate, and logs the configuration issue so the administrator can correct it.

Explicit cookie attributes​

Bot Guard marker cookies now use explicit modern cookie attributes.

Cookies now set SameSite=Lax, use Secure when served over HTTPS, and only allow JavaScript access where the browser collector genuinely requires it.

This improves cookie behaviour consistency across modern browsers while preserving compatibility with the add-on’s supported XenForo versions.

Improved Current visitors activity​

Bot Guard verification routes now display clearer activity text in XenForo’s Current visitors / online users area.

Visitors on the verification flow should now show generic verification-related activity rather than appearing as an unknown or unrecognised route.

The displayed activity text does not expose sensitive return URLs, visitor hashes, IP hashes, fingerprint IDs, nonce values, or challenge metadata.

Improved logging and observability​

The existing XF Bot Guard event log now provides clearer visibility for the new behaviours.

New or improved event visibility includes:

• CAPTCHA return URL restored or safely discarded
• Known crawler decision-layer allow overrides
• Collector proof validation failures
• Browser re-collection requests
• Route-family risk modifiers
• Hash secret / global salt configuration issues

Reason codes and metadata continue to use the existing event log structure.

Internal sanity and health-check tooling​

This release includes an internal developer sanity and health-check harness used to improve release testing.

The harness covers key behaviours such as CAPTCHA trust overrides, known crawler overrides, return URL validation, unsafe return rejection, Bot Guard self-route rejection, collector proof validation, metadata sanitisation, entropy scoring fixtures, route classification, excluded paths/routes/methods, and Bot Guard online activity support.

This internal tooling complements the usual manual XenForo 2.1, 2.2, and 2.3 compatibility testing.

No admin action required​

This update does not require a new database schema change and does not add a new admin configuration page.

Administrators using trusted crawler handling should ensure their proxy/header environment is appropriately controlled, as trusted crawler decisions depend on request headers being reliable.

Browser Signal Hardening & CAPTCHA Trust Improvements​

This update improves XF Bot Guard’s browser verification and challenge handling without changing the core protection model.

Improved browser coherence checks​

XF Bot Guard now collects and evaluates a broader set of lightweight browser signals to better identify suspicious or automated traffic patterns. These checks help distinguish normal browser activity from sessions that appear inconsistent, incomplete, automated, or artificially constructed.

New checks include:

• WebDriver and automation artefact detection
• User-Agent and Client Hints consistency checks
• Platform, screen, touch, and hardware profile consistency checks
• Language, timezone, and country plausibility checks
• Resource loading and rendering profile checks
• Cookie capability consistency checks

These signals are used as supporting risk factors only. They do not replace the existing scoring model.

Safer scoring behaviour​

Browser-coherence signals are now capped so that unusual but legitimate browsers, privacy extensions, older devices, or uncommon network setups are not over-penalised.

High-confidence automation indicators, such as explicit WebDriver or headless browser evidence, can still contribute strongly to the risk score.

Improved metadata handling​

The browser collector now stores richer but still privacy-conscious metadata. XF Bot Guard continues to avoid storing raw FingerprintJS component entropy, raw IP addresses, or unbounded client-side data.

Collected metadata is limited to compact browser and request-coherence signals used for bot-risk evaluation.

Fixed CAPTCHA trust-window behaviour​

Fixed an issue where a visitor who successfully completed CAPTCHA could immediately be challenged again if their underlying risk score remained high.

A successful CAPTCHA now properly honours the configured trust duration. During the active trust window, the visitor is allowed through without being challenged again.

Improved logging and observability​

New browser-coherence risk factors now appear in the existing XF Bot Guard event log as named reason codes with point values.

CAPTCHA trust-window allows are also logged clearly, making it easier to understand when a visitor was allowed because they had recently completed verification.

No admin action required​

This update does not add new configuration options and does not require any database schema changes.

• New default setting helps prevent high-risk traffic with no browser proof from receiving initial bootstrap grace.
• Left enabled, Bot Guard now makes a smarter risk decision before allowing bootstrap grace.

• Members Online and Online statistics now exclude visitors who are currently being challenged by XF Bot Guard and have not yet passed verification.
• Added a new “Bots” line below online statistics to show how many currently-online visitors are being held at the Bot Guard challenge.
• Added a new admin option to enable or disable Bot Guard’s online-count adjustment. This is enabled by default.
• Added automatic cleanup for temporary online-challenge tracking data to prevent unnecessary long-term table growth.
• Improved install/upgrade handling for Bot Guard cleanup cron tasks so required cleanup jobs are kept active and scheduled.
• Improved XenForo 2.1, 2.2 and 2.3 compatibility for online-count handling by aligning Bot Guard’s challenge tracking with XenForo’s own session activity records.

• Typo bug fix over 1.0.0 relase
• Fixes file hash issue