=== Predax Security – VPN, Proxy, Tor, Bot Blocker & Firewall ===
Contributors: ipsentry
Tags: vpn blocker, proxy blocker, tor blocker, bot blocker, country blocking
Requires at least: 5.8
Tested up to: 7.1
Stable tag: 1.17.2
Requires PHP: 7.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Blocks VPNs, proxies, Tor, datacenter IPs and bad bots. Plus firewall, login protection and country blocking. Free plan, no card needed.

== Description ==

Predax Security is a VPN, proxy, Tor and bot blocker for WordPress that doesn't stop there: a built-in firewall, login-lockout protection, country blocking and spam and disposable-email rejection are all included, switch by switch. It checks every visitor's IP address as they arrive and turns away the ones you don't want — before they can log in, register, comment or load a page.

Most attacks on WordPress sites — brute-force logins, fake registrations, comment spam, vulnerability scans — arrive over VPNs, open proxies, Tor or rented servers. Predax spots those connections in real time, gives each IP a 0–100 risk score, and blocks by the rules you choose.

[See what Predax knows about your own IP](https://predax.io/tools/what-is-my-ip) — free, no signup.

**Off by default.** A fresh install sends nothing anywhere. Pick a protection level in the setup wizard and the plugin starts working; until then it does nothing.

= What it blocks =

* **VPNs, proxies and Tor** — anonymised visitors, if you choose to block them
* **Datacenter IPs** — servers pretending to be people
* **Known bad IPs** — addresses flagged in a continuously updated threat database
* **Countries and regions** you don't serve
* **Attack requests** — a built-in firewall stops injection, scanner and file-probe attempts
* **Brute-force logins** — repeated failures are locked out, faster for risky addresses
* **Fake signups and spam** — disposable email addresses and bot comments are rejected

Every one of these is a switch. Turn on what you need.

= Control AI and SEO crawlers =

Decide whether GPTBot, ClaudeBot, PerplexityBot or AhrefsBot can access your site. Predax checks each crawler's real network, not a user-agent header anyone can fake — so a crawler that ignores robots.txt is still turned away. Search engines such as Google and Bing are allowed by default.

= Safe for your rankings and your readers =

* **Verified search engines are never blocked** by your VPN, datacenter, country or risk rules, so screening can't cost you search traffic.
* **Wrongly-blocked visitors can tell you.** Their report lands in the Threat Log with the full risk detail beside it. Nothing is unblocked until you decide.
* **One-click allow-listing** from the Threat Log puts a genuine reader back in as fast as they were turned away.

= Also included =

Security dashboard with live activity and top targeted paths · Threat Log with CSV export · Custom branded block page · IP and CIDR allow/deny lists · XML-RPC and REST API protection · Settings import/export · WP-CLI commands for automation

= Free plan =

Click **Connect with Predax** in the setup wizard and your free account and API key are created for you — nothing to copy or paste. The free plan includes **5,000 IP checks a month** (1,000 a day) with full VPN, proxy, Tor and datacenter detection. No credit card.

Busier sites can move to a [paid plan](https://predax.io/pricing) for a bigger monthly allowance — same plugin, same settings, same key.

== Installation ==

= From your WordPress dashboard (recommended) =

1. Go to **Plugins &rarr; Add New Plugin** in your WordPress admin
2. Search for **"Predax Security"**
3. Click **Install Now**, then **Activate**
4. The setup wizard launches automatically — click "Connect with Predax" to create your free account and link your API key in one click (or paste in an existing key manually), then choose a protection level
5. Go to **Predax Security** in the admin sidebar to view the security dashboard, and **Settings** to fine-tune protection types, risk thresholds, and advanced features

= Manual installation =

1. Download the plugin ZIP from this page and upload it via **Plugins &rarr; Add New Plugin &rarr; Upload Plugin** (or extract the `ipsentry-security` folder to `/wp-content/plugins/`)
2. Activate the plugin through the **Plugins** menu and follow the setup wizard

== Frequently Asked Questions ==

= How do I block AI bots like GPTBot or ClaudeBot from my content? =

Switch off "Allow AI crawlers" in Settings → Protection → Crawler Policy. Requests coming
from the IP ranges published by OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic
(ClaudeBot) and Perplexity (PerplexityBot) then receive a 403 instead of your content.
Search engines and SEO crawlers have their own separate switches, so this changes nothing
about how Google or Bing see your site.

= Isn't robots.txt enough to stop AI crawlers? =

robots.txt is a request that a crawler chooses to honour, and nothing enforces it. Blocking
by user-agent is no better, because the user-agent is just a header any script can set to
anything. Predax checks whether the request genuinely comes from an IP range the crawler's
operator publishes, and blocks on that verified identity instead. Crawlers that publish no
ranges at all are judged by the normal bot and risk rules.

= Will blocking AI or SEO crawlers hurt my Google rankings? =

No. The three switches are independent: blocking AI or SEO crawlers has no effect on search
engines, which stay allowed — and exempt from your other category rules — unless you
deliberately turn the search-engine switch off. The settings page warns you clearly if you do.


= How is this different from Wordfence or other security plugins? =

It solves a different problem — and runs happily alongside them. Scanner-based plugins like Wordfence or Solid Security focus on malware scanning and firewall rules: they look at *what a request does* once it reaches your site. Predax Security looks at *who is connecting*: it identifies anonymised and high-risk IPs (VPNs, proxies, Tor, datacenter ranges) in real time using a commercial IP intelligence database, and blocks them before they attempt anything. Many sites run Predax Security alongside a scanner-based plugin — Predax filters out the anonymous, high-risk traffic; the scanner watches what gets through.

= Will this slow down my site? =

No. API results are cached in the WordPress database for between 5 minutes and 1 hour per IP, following the lifetime the API recommends for that address. After the first check, returning visitors are served from cache with no API call.

= Does this block all VPN users? =

Only if you enable VPN blocking. By default the plugin is set to *monitor* VPN traffic (log it but not block it). You control exactly which threat types trigger a block.

= What happens to blocked visitors? =

By default they see a standard WordPress error page with a 403 status code. You can enable the **Custom Block Page** option to show a branded page with your own message and a support link.

= Does it work with Cloudflare? =

Yes. The plugin reads the `CF-Connecting-IP` header automatically when Cloudflare is detected, so the real visitor IP is used rather than the Cloudflare proxy IP.

= Is the free plan enough for a small site? =

For most small sites, yes. The free plan provides 1,000 checks per day. With 1-hour caching, this covers approximately 1,000 unique visitors per day. Returning visitors within the hour use cached results and don't count against your quota.

= Can I whitelist my own IP? =

Yes. Go to **Settings → Predax Security → Whitelist / Blacklist** and add your IP or CIDR range. Whitelisted IPs bypass all checks.

= Does it protect the WooCommerce checkout? =

The base security plugin protects logins and registrations. For WooCommerce checkout protection (fraud scoring, country mismatch, order velocity, auto hold), use the companion **Predax Fraud Guard for WooCommerce** plugin (also on WordPress.org).

= What data is sent to the API? =

The visitor's IP address, and optionally their timezone when timezone mismatch detection is enabled. A temporary cookie is used to pass the timezone from the browser to the server. If you enable disposable-email screening, the domain part of the email address entered at registration (for example "gmail.com") is also checked — never the address itself, and never the part before the @. No page content or other personal user data is transmitted. See the Third Party Services section below for full details.

= Will this block my real visitors or hurt my SEO? =

No. Verified search engine crawlers — Googlebot, Bingbot and others confirmed by
reverse DNS — are never blocked by category rules, so your search rankings are not
affected.

For human visitors, the plugin errs toward telling you rather than guessing. The
dashboard separates attacks stopped from visitors turned away by your own category
rules, so you can see at a glance whether your settings are too strict. Anyone
blocked by a category rule can tell you they are genuine, and you can allow their
IP in one click.

If you run a blog, news or download site, we suggest the Recommended preset rather
than Strict: a meaningful share of ordinary readers browse via a VPN.

== Third Party Services ==

This plugin connects to external services. By installing and activating this plugin you agree to the terms of each service you enable.

= Predax API =

This plugin transmits visitor IP addresses to the **Predax API** (https://predax.io) for real-time threat detection and risk scoring.

**What is sent:** The visitor's IP address; optionally their timezone (when timezone mismatch detection is enabled and visitor protection is active); and, when disposable-email screening is enabled, the domain part of the email address entered at registration (for example "gmail.com") — never the email address itself, and never the part before the @. The mailbox-level checks (role account, random-looking name) run locally on your own server.
**When it is sent:** On each page load, login attempt, registration, or comment submission, subject to your configured protection settings. IP results are cached for up to 1 hour and email-domain results for up to 6 hours, so repeat visits do not generate additional API calls.
**Who operates the service:** Predax (predax.io)
**Terms of Service:** https://predax.io/terms
**Privacy Policy:** https://predax.io/privacy

= Email Domain Screening (only when disposable-email screening is enabled) =

Used to check whether the email provider entered at registration is a disposable/throwaway service, against a server-side list of thousands of domains (the plugin's built-in list covers only ~50).

**What is sent:** the domain part of the registration email address only — for example `gmail.com`. The email address itself is NEVER sent: the part before the @ does not leave your site, and the mailbox-level checks (role account, random-looking name) run locally in PHP on your own server.
**When it is sent:** during user registration, and only while the Disposable Email Addresses setting is set to Flag or Block. If the API is unreachable, the plugin falls back to its built-in local list and the registration proceeds normally. Email-domain results are cached for up to 6 hours per domain.
**Endpoint:** `POST https://predax.io/api/v1/validate/email`
**Plan usage:** email-domain lookups count against your Predax plan allowance, the same as IP checks. Results are cached per domain for 6 hours and the built-in list is checked first, so in practice this is roughly one lookup per new email provider your visitors use.
**Who operates the service:** Predax (predax.io)
**Terms of Service:** https://predax.io/terms
**Privacy Policy:** https://predax.io/privacy

= Account Usage Lookup (admin pages only) =

Used to show the "API Usage" meter on the plugin dashboard, and only when an API key is saved.

**What is sent:** your Predax API key (as the authentication header). No visitor data is sent.
**When it is sent:** when an administrator views the Predax Security dashboard. The result is cached for 1 hour, so at most one lookup per hour regardless of admin page views.
**Endpoint:** `GET https://predax.io/api/v1/auth/usage`
**Privacy Policy:** https://predax.io/privacy

= Deactivation Feedback (optional, admin-initiated) =

Shown only when an administrator deactivates the plugin from the Plugins screen and chooses to answer the "why are you deactivating?" prompt.

**What is sent:** the plugin slug, the plugin version, and a single pre-defined reason code you select (e.g. "it blocked real visitors"). No site URL, no email address, no visitor data, and no IP address are sent.
**When it is sent:** only when you select a reason and click "Send & deactivate". Clicking "Skip & deactivate" sends nothing at all.
**Endpoint:** `POST https://predax.io/api/v1/feedback/deactivation`
**Privacy Policy:** https://predax.io/privacy

= Community Threat Network (opt-in, disabled by default) =

The Community Threat Network is **opt-in and disabled by default**. No block or monitor events are sent to the community network unless you enable it yourself in **Settings → Predax Security → Advanced**.

When — and only when — you explicitly enable it, anonymised block and monitor events (containing: IP address, action taken, block reason, country code, and risk score) are sent to the Predax API at predax.io. This data is used to build a shared threat database that improves detection accuracy for all sites in the network. You can turn community reporting back off at any time in the same settings screen.

= Google reCAPTCHA =

When reCAPTCHA v3 is enabled (Settings → Protection → reCAPTCHA), this plugin loads the reCAPTCHA script from **google.com** and sends form submission tokens to **google.com/recaptcha** for verification. Google may collect data according to their privacy policy. You must provide your own reCAPTCHA site key and secret key.

**Google Privacy Policy:** https://policies.google.com/privacy
**reCAPTCHA Terms:** https://policies.google.com/terms

= Browser Fingerprinting =

When browser fingerprint scoring is enabled (Settings → Protection → Fingerprint Scoring), this plugin collects screen resolution, timezone, platform string, WebGL renderer, and plugin count from the visitor's browser on the login page. Fingerprint data is used locally to score bot likelihood and is stored in WordPress only while the login form is being submitted, then discarded. The visitor's timezone may be included in the API request to detect timezone mismatch when that feature is enabled.

= Cookies set by this plugin =

All cookies set by this plugin are functional service cookies, not tracking cookies, and are only written when the relevant feature is explicitly enabled by the site administrator:

* `ipsentry_tz` — carries the visitor's browser timezone to the Predax API when timezone-mismatch detection is active. Written from `ipsentry-tz.js` on the front-end. Expires after 24 hours. `SameSite=Lax`. Only set when an API key is configured AND visitor or login protection is enabled.
* `ips_jsc` — JavaScript challenge solve token. Written from `js-challenge.js` when a visitor passes the challenge. Expires after 24 hours. `SameSite=Lax`. Only set when the JavaScript Challenge feature is enabled.

No tracking or advertising cookies are written by this plugin.

By activating this plugin and entering an API key, you agree to the Predax Terms of Service and Privacy Policy. You are responsible for ensuring your use of visitor IP data complies with applicable privacy laws (GDPR, CCPA, etc.) and your own site's privacy policy.

== Screenshots ==

1. A Tor visitor blocked before reaching the site: the branded block page every high-risk visitor sees, with the block reason.
2. Settings page — configure API key, risk threshold, and protection types
3. Threat log — view all blocked events with IP, reason, risk score, and timestamp
4. Dashboard widget — at-a-glance threat stats on the WordPress dashboard
5. Country blocking — select countries and regions to allow or deny
6. Setup Wizard — pick a protection level (Monitor Only, Recommended, or Strict) in one step
7. "Predax Protection This Week" — a native WordPress dashboard widget summarizing blocked threats by category
8. Detection Modes — VPN, proxy, Tor, malicious-IP, and datacenter blocking, each independently switchable
9. Threat Log with reported access problems — visitors blocked by a category rule can tell you they are genuine; each report shows the risk detail so you can allow the IP in one click, or dismiss it
10. Crawler Policy — allow verified search engines while deciding separately on AI crawlers (GPTBot, ClaudeBot, PerplexityBot) and SEO crawlers. Enforced by each operator's published IP ranges, not the spoofable user-agent header.

== Changelog ==

= 1.17.2 =
* Fix: the firewall treated every request to xmlrpc.php as an attempted file probe, so Jetpack, the WordPress mobile apps and backup services were blocked on any site with the firewall on -- no matter how XML-RPC protection was configured, including when it was switched off. Requests for leaked copies (xmlrpc.php.bak and similar) are still blocked.
* Fix: the IP allow-list is now honoured for XML-RPC. Previously "Disable all XML-RPC" and "Block amplification" ignored it, so an allow-listed client was still refused.
* New: Jetpack is recognised automatically from Automattic's published IP ranges when Jetpack is installed, so it keeps working without adding anything to the allow-list. Recognised services are exempt from category rules (VPN, datacenter, country, risk score) only -- they are still blocked by the firewall, the malicious-IP feed and your own blocklist.

= 1.17.1 =
* Fixed: the allow-list was ignored by the user-enumeration protection. If "Block user enumeration" was switched on, author pages and the REST users endpoint were refused for logged-out visitors even when their address was on the allow-list. This was separate from the allow-list problems fixed in 1.17.0, which is why it could still bite after updating. The allow-list is meant to be absolute, and now is.
* Fixed: the comment honeypot could also refuse an allow-listed address. No effect on normal visitors, but it was the last place where "never blocked" was not quite true.

= 1.17.0 =
* Fixed: adding your own IP address to the allow-list did not always take effect. A saved decision about a visitor was kept for up to an hour, and allow-listing someone failed to clear it, so page views kept being refused even though the allow-list was correct. Allow-listing an address now takes effect immediately, whether you save it in Settings or use the Allow button in the Threat Log.
* Fixed: an allow-list or block-list entry could be ignored when your site is reachable over both IPv4 and IPv6. The same visitor can arrive in two different notations, and only one of them was being matched. Single addresses and ranges now match either notation.
* New: the IP Allow-list setting now shows the address your site currently sees you as, with a button to add it. Copying your address from an external "what is my IP" service can give you the wrong one, which is what made allow-listing yourself unreliable.
* New: a clear warning on your plugin screens when Predax is refusing your API key - most often because the account's email address has not been verified yet. Previously screening simply stopped and nothing said so, leaving visitors unchecked with no indication anything was wrong.
* Fixed: the text in the Community Threat Network consent box, and in the privacy notices either side of it, was too faint to read during setup. All of it now meets the standard contrast level.
* Improved: the plugin's name now describes what it does - VPN, proxy, Tor and bot blocking, plus the firewall. No settings or behaviour change.

= 1.16.0 =
* New: a Help page, in the Predax Security menu. Plain-English explanation of every setting, what to choose, and what to do when something is blocked that should not be. It is stored in the plugin, so it works even if your site cannot reach the internet.
* New: optional log retention. The Threat Log and Event Log can now be tidied up automatically. This is OFF by default - nothing is deleted until you choose a number of days under Settings -> Notifications. Once set, the plugin tells you exactly how many entries are affected and waits seven days before deleting anything.
* New: a reminder on your plugin screens when an API key is saved but visitor screening is still switched off, so a half-finished setup no longer sits unnoticed.
* Security: the Threat Log CSV export now neutralises spreadsheet formulas. Attacker-supplied text in a log entry could previously be interpreted as a formula when the file was opened in Excel or Sheets.
* Security: the firewall could be skipped by a request whose address merely contained "/wp-admin". Exemption is now based on being a logged-in user with editing rights, not on the address.
* Fixed: uninstalling Predax Security removed the settings of Predax Fraud Guard for WooCommerce if both were installed. It now leaves the other plugin alone.
* Fixed: Apple Private Relay and Cloudflare WARP are no longer caught by the datacenter rule, so iPhone visitors are not refused.
* Fixed: AJAX requests from visitors who are not logged in were exempt from IP screening.
* Fixed: the failed-login counter could undercount when many attempts arrived at once, letting an attacker exceed the configured limit before the lockout applied.
* Fixed: the automatic block list is now capped at 5,000 addresses. Addresses you added yourself are never removed.
* Fixed: the dashboard and the WP-CLI status command showed the firewall, Tor and VPN settings as off when they were on.
* Improved: the plugin is now fully translatable. The bundled translation template was previously almost empty, so translations had nothing to work from.

= 1.15.0 =
* New: disposable-email screening now checks a continuously updated list of thousands of throwaway providers instead of the short built-in list. Enable it under Settings -> Registration. Only the DOMAIN part of the address is checked (for example "gmail.com") - the address itself, and everything before the @, never leaves your site. The built-in list is still consulted first and still applies if the API is unreachable, so no site loses a block it had before.
* New: registrations from a domain that cannot receive mail, or with a machine-generated mailbox name, are recorded in the Threat Log. Both are flag-only signals and never block anyone on their own.
* Improved: a visitor already blocked by their IP address no longer triggers an email lookup as well - faster registrations and less of your plan allowance spent.
* Fixed: a malformed email domain could previously cause repeated API errors that temporarily paused IP screening. Malformed domains are now rejected on your own server and never sent.
* Note: email-domain lookups count towards your Predax plan allowance. Results are cached for six hours per domain.

= 1.14.0 =

**Crawler Policy — decide which crawlers may access your site**
* New: independent allow/block switches for search engines (Googlebot, Bingbot, DuckDuckBot, Applebot), AI crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) and SEO crawlers (AhrefsBot), in Settings → Protection → Crawler Policy.
* Enforcement uses the IP ranges each operator publishes — verified identity, not the user-agent header — so unlike robots.txt (a request) or user-agent blocking (trivially faked), a blocked crawler is actually turned away. A visitor merely claiming a crawler's user-agent is neither blocked nor allowed by this policy; your normal rules apply to them in full.
* All three switches default to Allow, so nothing changes on your site until you switch one off. Blocks appear in the Threat Log with their own reasons.

**Search-engine safety**
* Fix: verified search engine crawlers are no longer served the JavaScript Challenge page. That page returns HTTP 200 with no real content, so a challenged crawler could index "Verifying your browser…" in place of your pages. The exemption requires DNS-verified identity — a faked crawler user-agent still gets the challenge.
* Fix: crawler verification now accepts reverse-DNS names in any capitalisation, and with or without the trailing dot. Previously a legitimate crawler whose DNS answered in mixed case could be treated as fake.

**Privacy and control**
* The Community Threat Network opt-in is now offered as an explicit, unticked checkbox in the setup wizard, with a plain-English description of exactly what is shared. It stays off by default and can be changed any time in Settings → Advanced.
* New: "Behind a proxy or CDN" setting. Leave it on (the default) if your site is behind Cloudflare, a CDN or any reverse proxy. Turn it off if visitors reach your server directly, so forwarded IP headers — which a visitor can fake — are ignored in favour of the real connecting address.

**Housekeeping**
* The plugin now identifies itself and its version in its API requests.
* reCAPTCHA verification failures caused by a network error reaching Google are now recorded in the Threat Log instead of passing silently, and the fail-open behaviour can be changed with the `ipsentry_recaptcha_fail_open` filter.
* Removed two settings that were registered but no longer had any effect.
* Corrected the documented cache lifetime: results are cached between 5 minutes and 1 hour per IP, following the lifetime the API recommends.

= 1.13.0 =

**Firewall**
* The firewall now inspects large form submissions. Previously, if a request's form fields totalled more than 8KB, **every** firewall rule except the user-agent check was skipped - so an attack in the URL or a form field went uninspected and unlogged if any other field on the page was large. Attacks hidden inside an oversized single field are now inspected too.
* Note: because these requests were never inspected before, a very long submission (a lengthy comment or contact-form message) that contains code-like text - backticks, `$(...)`, or `<script` written in prose - may now be blocked where it previously slipped through. This is the same behaviour shorter submissions have always had.

**Allow-listing now takes effect immediately**
* Clicking **Allow** on a blocked visitor now unblocks them straight away. Previously only ordinary page views recovered; the visitor's REST (`wp-json`) and XML-RPC requests kept being refused for up to an hour, which broke comment forms, block themes and app access for someone you had just allowed.
* Adding an IP to the allow-list on the Settings page now does the same. Previously it had no immediate effect at all, making the allow-list look broken.

**Brute-force protection**
* Fixed the risky-IP login limits not applying. Login protection was reading a cached verdict that nothing wrote any more, so an attacker on a VPN, proxy or Tor exit was given the relaxed limit for clean addresses instead of the stricter one, and no auto-blacklist followed.

**Reporting**
* The dashboard no longer counts monitored or flagged visitors as blocks (measured on real data, this removed a 13.6% over-count), and now correctly counts auto-blacklist and temporary lockouts, which were being missed.
* The hardening score now reflects the XML-RPC setting. It was reading an option the settings screen has not written since 1.10.0, so hardening XML-RPC never moved the score.
* Risk levels now match the bands the Predax API actually issues.
* Fingerprint events now respect the "event tracking" setting instead of being recorded regardless.
* Fixed a custom block-page title showing escaped characters (an apostrophe appearing as `&#039;`).

**Efficiency**
* Predax Security and Predax Fraud Guard now share one cached verdict per visitor, so a site running both no longer spends two checks on the same person.
* Cached verdicts now follow the lifetime the API recommends (up to an hour) instead of a fixed five minutes, which significantly reduces how much of your allowance a busy site uses.
* The cache key now covers the whole request rather than the IP alone, so one visitor's result can no longer be served to a different visitor behind the same network.

**Housekeeping**
* Uninstall now cleans up correctly on multisite networks (per-site tables and options were previously left behind) and removes leftover lookup locks.
* Added optional automation-detection scoring based on browser header consistency. It only scores and never blocks; enforcement is not enabled.
* New one-time notice confirming your first blocked threat, so a fresh install shows evidence it is working.
* Tested up to WordPress 7.1.

= 1.12.5 =
* Fix: hitting your plan's DAILY check limit no longer reports it as the monthly limit. The notice used to say screening was paused "until your quota resets on the 1st" when it actually resumes at midnight UTC the same day - up to a month of wrong information at the moment it matters most. It now names the right limit and tells you the exact time screening resumes.
* Improved: fewer API checks are used for the same visitors. When several requests for one visitor arrive at the same time (a page load often makes several), the plugin now performs a single lookup and shares the result instead of one lookup per request. Busy sites will notice their daily allowance lasting longer.

= 1.12.4 =
* Fix: region blocking now saves "All of Africa", "All of Asia" and "All of the Americas" selections. Previously they were silently discarded on save - the checkbox reverted and no visitors from those regions were ever blocked, with no error shown.
* Fix: re-running the Setup Wizard and choosing "Monitor Only" now also switches off known-malicious IP blocking. Previously that one rule stayed on if a stricter preset had enabled it, so a preset promising to block nothing kept blocking.
* Fix: the "Blocked Today" / "This Week" dashboard widget no longer counts monitored or flagged visitors as blocks - it now reports only visitors who were actually blocked.
* Fix: the weekly protection widget now counts auto-blacklisted attackers and brute-force lockouts, which it previously listed as categories but could never actually count.

= 1.12.3 =
* New: an invitation to join the Community Threat Network now appears on your dashboard, with a one-click opt-in. Sites in the network warn each other, so an attacker stopped on another Predax site is already known to yours. It remains entirely opt-in and was previously easy to miss - it lived only as a toggle in Settings.
* Improved: clearer wording about exactly what is shared - the attacking IP address and the reason it was blocked, never visitor personal data and nothing about your site.

= 1.12.2 =
* Security: the firewall now runs on every request. It previously ran last, so any visitor the other rules had already judged skipped it entirely - including VPN visitors on the Recommended preset, where VPN is set to monitor. Attacks from those visitors were not inspected or logged.
* Security: the firewall is no longer skipped for an hour after a visitor's first clean request. Visitor results are cached to keep your site fast; that cache described the visitor, not the request, so it was letting later attacks through uninspected.
* Security: the firewall now keeps working when the Predax API is unreachable. An outage previously disabled it, even though it runs entirely on your own site.

= 1.12.1 =
* Fix: VPN visitors were being blocked as "datacenter". Because VPN servers live in datacenters, the datacenter rule ran first and caught them — so turning "Block VPN" off did nothing, and the Threat Log showed "datacenter" instead of "VPN". VPN and proxy are now checked first, so your toggles work and the log names the real reason.
* Fix: visitors set to "monitor only" for VPN are no longer blocked when datacenter blocking is on.
* Fix: the dashboard's Recent Blocks list showed "Monitored" for visitors who were actually blocked. Only locally-triggered blocks were recognised; blocks based on IP intelligence were mislabelled.
* Fix: sites in the Community Threat Network were reporting every visitor as having no VPN/proxy/Tor/datacenter signal, so shared intelligence was based on incomplete data.
* Fix: honeypot-triggered blocks were shown as "Monitored" on the dashboard.
* Fix: the [ipsentry_badge] shortcode counted only locally-triggered blocks, so most sites displayed zero.
* Improved: block page reference codes are now readable — "DATACENTER_BLOCK" instead of "DC_BLOCK", "FIREWALL_SQL_INJECTION" instead of "WAF_SQLI", and so on.

= 1.12.0 =
* Fix: verified search engines (Googlebot, Bingbot) are no longer blocked. On the Strict preset the datacenter rule was blocking them, which over time removes a site from search results.
* New: visitors blocked by a category rule can tell you they're genuine. Reports appear on the Threat Log with full risk detail, and you can allow the IP in one click.
* New: allow any IP directly from the Threat Log.
* New: tell us why you're deactivating, so we can fix it.

= Older versions =

The full history back to 1.0.0 is in changelog.txt in the plugin folder.

== Upgrade Notice ==

= 1.17.2 =
Fixes Jetpack, the WordPress mobile apps and backup services being blocked by the firewall. Recommended for everyone, and required if you use Jetpack.

= 1.15.0 =
Disposable-email screening now uses a continuously updated list instead of the small built-in one. Only the domain is checked - never the address itself. Also fixes a case where a malformed email domain could briefly pause IP screening.

= 1.14.0 =
New Crawler Policy: allow or block AI crawlers (GPTBot, ClaudeBot, PerplexityBot), SEO crawlers and search engines — enforced by verified IP ranges, not the spoofable user-agent. All switches default to Allow. Also stops verified search crawlers being served the JS challenge page.




= 1.13.0 =
Fixes the firewall skipping every rule on pages with large form fields, and "Allow this IP" not actually unblocking REST/XML-RPC requests for up to an hour. Also restores the stricter login limits for VPN/proxy/Tor addresses, and reduces how much of your allowance a busy site uses.
= 1.12.5 =
Fixes a daily check limit being reported as the monthly one - the notice claimed screening was paused until the 1st when it actually resumes the same day. Also reduces how much of your allowance busy pages consume.
= 1.12.4 =
Fixes region blocking silently ignoring "All of Africa/Asia/Americas" selections, the Monitor Only preset leaving malicious-IP blocking on, and two dashboard widgets miscounting blocks. Recommended for everyone using region blocking or the wizard presets.
= 1.12.3 =
Adds a one-click option to join the Community Threat Network, so attackers blocked on other sites are already known to yours. Entirely optional.
= 1.12.2 =
Security fix: the firewall was being skipped for VPN visitors on the Recommended preset, for an hour after any visitor's first clean request, and during Predax API outages. Update recommended.
= 1.12.1 =
Fixes VPN visitors being blocked as "datacenter", which made the Block VPN setting appear to do nothing. Also corrects blocked visitors being shown as "Monitored", and makes block page reference codes readable.
= 1.12.0 =
Fixes a bug that could block Google and Bing from crawling your site — recommended for everyone, and important if you use the Strict preset.

= 1.11.2 =
Fixes VPN/proxy blocks that happened even with both toggles off (and were logged under the wrong reason), fixes an undercounting dashboard widget, and makes the widget distinguish attacks from visitors blocked by your own rules. Recommended for anyone whose traffic dropped unexpectedly. Safe to upgrade.

= 1.11.1 =
Fixes malicious-IP blocking so it actually works (a normalization bug in 1.11.0 silently prevented it from ever triggering), adds specific block-page messaging, and masks the API key field. Safe to upgrade.

= 1.11.0 =
Adds known-malicious IP blocking as its own off-by-default category, a new "Predax Protection This Week" dashboard widget, and a reason filter for the Threat Log. No settings are changed automatically. Safe to upgrade.

= 1.10.0 =
Adds user/author enumeration blocking, XML-RPC amplification hardening (pingback + system.multicall), firewall repeat-offender auto-ban, and an API circuit-breaker that keeps your site fast if the Predax API is ever slow — plus an autoload performance migration. Your existing "Disable XML-RPC" setting is migrated automatically. Safe to upgrade.

= 1.9.4 =
WordPress 7.0 + PHP 8.2 compatibility tested. Setup wizard branding refreshed and a fix for an OAuth-redirect edge case that could show a blank "0" page. No settings changes. Safe to upgrade.

= 1.9.1 =
Privacy + security polish. Fresh installs: visitor and login protection now default OFF (enabled by picking a Setup Wizard preset). Community Threat Network opt-in toggle. IP/CIDR validation on blacklists. uninstall.php cleanup. Existing sites keep their settings. Safe to upgrade.

= 1.9.0 =
Adds a full security dashboard as the plugin's landing page. Settings and setup wizard redesigned. No configuration changes required. Safe to upgrade.

= 1.8.0 =
Major feature release — HTTP Security Headers, Google reCAPTCHA v3, Honeypot URL Traps, User-Agent Blocking, 404 Threshold Blocking, JavaScript Challenge, Browser Fingerprint Scoring, and more. All new features are off by default. Safe to upgrade.

= 1.7.0 =
Adds one-click OAuth connect via the setup wizard — link your site to Predax without copying an API key. Manual key entry remains available as a fallback.

= 1.6.0 =
Adds a 3-step setup wizard that runs on first activation. No configuration changes to existing installs. Safe to upgrade.

= 1.5.5 =
Recommended update — VPN detection improved (NordVPN and other major providers now reliably detected). Block messages updated to always mention Predax.

= 1.5.3 =
Recommended update — smarter login protection (hackers get permanently blocked, legitimate users get a temporary lockout). Test Connection button fixed.

= 1.5.2 =
Bug fix: VPN/proxy users in Monitor mode no longer get blocked by the risk threshold. Recommended update for anyone using VPN detection.

= 1.5.1 =
Settings page UX improvements — tabbed layout, inline save/test buttons, help tooltips. No configuration changes required.

= 1.5.0 =
Adds the Web Application Firewall (WAF, on by default) and the opt-in Community Threat Network (off by default; enable in Settings → Predax Security → Advanced to contribute block events to the shared feed). Safe to upgrade — no configuration changes required.

= 1.4.0 =
Adds custom block page, XML-RPC/REST API protection, disposable email blocking, WP-CLI commands, and settings import/export. All new features default to off — no behaviour changes on upgrade.
