XF Bot Guard 1.3.2
Release type: minor
XF Bot Guard 1.3.2 focuses on lower server load, smarter forum-specific bot detection, and better stability on larger sites. It expands cache-backed reads across more protection hot-paths, adds new Link Chronology and dwell-time behavioural signals, improves dashboard reliability, and adds a new health check for Board URL origin issues.
Faster protection with cheaper hot-path reads
XF Bot Guard already used XenForo’s application cache on its primary hot-path. In 1.3.2, that cache-backed approach has been extended across every compatible hot-path, including areas such as counters, verified crawler lookups, network matching, light-response pattern parsing, contextual link canaries, and Link Chronology state. In plain terms, this means Bot Guard can avoid many repeated database read queries during busy traffic by reusing short-lived cached data where available.
There is nothing new to enable inside Bot Guard. If XenForo application cache is configured and hydrated, Bot Guard will use it automatically. If not, Bot Guard remains database-backed and continues to work normally, but busier forums should strongly consider enabling XenForo application cache. Memcached is the preferred recommendation, followed by Redis. APC/APCu can be useful for smaller single-server installs, but it is not the preferred recommendation for larger or busier communities.
Smarter forum-specific link journey checks
Link Chronology helps Bot Guard tell the difference between normal browsing and scraper-style URL traversal. When a visitor views a protected page, Bot Guard keeps a short-lived record of the protected internal links that were actually visible on that page. On the next protected request, it can tell whether the visitor is following a link they were recently shown, reloading the same page, or jumping directly to another protected URL that was not part of their recent journey.
This matters because real users usually browse through visible forum links, while bots often work from URL lists, guessed paths, scraped routes, or direct protected-page traversal. The signal is tailored to each forum because it is built from that forum’s actual pages, links, and route structure. It is enabled by default and can be tuned or disabled from the Link Chronology options. It adds bounded risk only; it does not hard-block anyone by itself.
Forum-specific dwell-time learning
Dwell-time learning gives Link Chronology a better idea of what “normal” browsing looks like on each individual community. Bot Guard samples eligible registered-user navigation to learn rough local bounds for how long people usually spend between protected page transitions. A fast-moving support forum, a long-form discussion forum, and a media-heavy community may all have different normal behaviour, so Bot Guard learns from the forum itself rather than relying on one fixed global rule.
This is designed to be privacy-preserving. Bot Guard does not need to identify individual members, store personal browsing histories, or know what someone personally read to build this model. It uses local aggregate behaviour to understand the forum’s normal rhythm, then adds bounded risk only when a protected link journey is unusually fast or unusually slow compared with that forum’s own normal pattern. If there is not enough local sample data yet, dwell-time scoring simply does not apply.
More reliable dashboard on larger sites
The dashboard now avoids loading unbounded route and timing metric rows into memory. Route reports are limited to the most relevant routes, route outcomes are fetched only for those selected routes, and timing summaries are calculated in a more memory-safe way.
This resolves dashboard memory exhaustion on larger or busier installations. There is nothing to enable; upgrade and use the dashboard as normal.
Board URL origin health check
The health check now validates XenForo’s Board URL origin against the current public request origin. This helps catch common configuration problems such as HTTP/HTTPS mismatch, wrong host, www/non-www mismatch, port mismatch, or proxy handling issues.
This matters because origin mismatches can affect same-origin browser validation, challenge URLs, and asset URLs. To use it, open the XF Bot Guard health/status page after upgrading and review the Board URL origin result. If it reports a problem, fix XenForo’s Board URL or your proxy HTTPS/host configuration, then re-run the check.
More consistent members online counts
Bot Guard’s online count adjustment now uses one consistent aggregate of XenForo session activity instead of combining separate reads that could briefly disagree under movement or load.
This fixes transient inconsistent public online totals, including member, guest, and challenged counts. It applies automatically when Bot Guard is enabled and the online count adjustment option is enabled.
