[XTR] IP Threat Monitor 1.0.21

• Fixed: Resolved the critical "MySQL Data too long" error caused by large IP lists exceeding database capacity.
• Fixed: Database performance issues caused by frequent updates from the Rate Limiter and IP services.
• Changed: The caching system has been completely rebuilt to use file-based storage instead of the database, ensuring zero database load for large datasets.
• Improvement: Optimized cache cleaning processes for better stability.

Critical Fixes & Improvements

This update introduces a major architectural change to the caching mechanism, migrating from database-based storage to a dedicated file-based system to permanently resolve database size limits.

• ixed "Data too long for column 'data_value'" database error occurring when caching the Cloudflare IP list.
• Migrated Cloudflare IP caching mechanism from database (SimpleCache) to file-based system (File System).
• Fixed "Accessed unknown getter 'xentr_ipt_country'" error when updating user country information.

This update resolves two critical issues frequently appearing in Server Error Logs.

1. SimpleCache Size Limit Issue: XenForo's default caching mechanism (SimpleCache) stores data in the database with a specific size limit. When combined with data from other installed add-ons, the Cloudflare IP list could exceed this limit, triggering "Data too long" errors. Cloudflare IP data is now securely stored in your server's file system (internal_data folder).
2. Entity Getter Error: In some cases, an "Accessed unknown getter" error was resolved when updating user country information.

• Fixed "Allowed memory size exhausted" error when accessing Dashboard and Analytics pages on databases with large amounts of records.
• Chart and statistics data processing has been switched to SQL-based aggregation to prevent PHP memory exhaustion.
• Performance improvements made to statistical queries.

This update includes a critical performance patch, especially for forums with high traffic and tens of thousands of IP log records stored in the database.

In previous versions, loading all data into server memory (RAM) to generate charts on the Dashboard and Analytics pages could cause memory limit exhaustion (Fatal Error) in some cases. With version 1.0.19, this process has been optimized by offloading the workload to the database engine. This ensures your Dashboard page loads fast and without errors, even with millions of log records.

Added ProxyCheck.io API "burst mode" support

• API responses with "warning" status are now accepted
• Added handling for "denied" status when burst tokens are exhausted
• Added proper handling for HTTP 401/403 error codes
• Added error message detection for "burst" and "exhausted" keywords

Technical Detail
ProxyCheck.io returns status: "warning" when the daily limit is exceeded and a burst token is consumed. Previous versions only accepted "ok" status, which caused VPN/Proxy checks to stop working during burst mode.

This release contains a critical fix for ProxyCheck.io API integration.

Fixed Issue:
Resolved an issue where VPN/Proxy checks stopped working when ProxyCheck.io "burst mode" (extra credit usage) was active.

Affected Users:
All users utilizing ProxyCheck.io API for VPN/Proxy detection with burst token feature enabled.

Symptoms:

• IPs were not being added to blacklist when burst token limit was reached
• Add-on was not processing responses even though the API was still working
• Cache clearing or reinstallation did not resolve the issue

• Fixed: Database column not created on upgrade - Fixed an issue where the xentr_ipt_country column was not being added to the user table when upgrading from older versions. This caused "Accessed unknown getter 'xentr_ipt_country'" errors.

This is a hotfix release that resolves a database upgrade issue introduced in v1.0.16.

What was fixed:
Users upgrading from older versions to v1.0.16 experienced "Accessed unknown getter 'xentr_ipt_country'" errors. The database column required for country flag display was not being created during the upgrade process.

Upgrade Instructions:
Simply download v1.0.17 and install it. The upgrade process will automatically add the missing column.

NEW FEATURE:

• Allow Cloudflare WARP Users - New option to exempt Cloudflare WARP VPN users from being blocked. WARP is a popular free privacy service used by millions of users. This option is enabled by default.

BUG FIXES:

• Fixed: VPN Cache Clearing Incomplete - The "Clear VPN Check Cache" option was only clearing API result cache but not the first-visit status cache. This caused IPs to not be re-checked after cache clearing. Both cache types are now properly cleared.
• Fixed: Error Logging Suppressed - SimpleCache errors are now silently handled instead of being logged to the server error log.
• Fixed: Reset SimpleCache Option - Added "Reset SimpleCache (Emergency Fix)" option to resolve "Data too long for column" database errors without requiring phpMyAdmin access.

IMPROVEMENTS:

• Improved cache management for better reliability
• Better handling of privacy-focused VPN services (iCloud Private Relay, Cloudflare WARP)

This release focuses on cache reliability improvements and adds support for Cloudflare WARP users.

Highlights:

• Cloudflare WARP Support - Users connecting through Cloudflare's free WARP VPN service will no longer be incorrectly blocked. A new "Allow Cloudflare WARP Users" option has been added (enabled by default), similar to the existing iCloud Private Relay exemption.
• Complete Cache Clearing - Fixed an issue where clearing the VPN cache didn't fully reset all cached data. Some IPs would retain their "already checked" status and wouldn't be re-verified. This is now fixed.
• Emergency SimpleCache Reset - Added a new "Reset SimpleCache (Emergency Fix)" option in the Prune/Clear Logs page. This allows administrators to fix "Data too long for column" database errors directly from the admin panel without needing phpMyAdmin access.
• Cleaner Error Logs - SimpleCache-related errors are now handled silently instead of cluttering your server error log.

• Critical Fix: Resolved MySQL query error [1406]: Data too long for column 'data_value'. This issue occurred on high-traffic sites because XenForo's SimpleCache stores all data in a single database row, which overflowed with thousands of IP check records. VPN/Proxy check results are now securely stored using the add-on's efficient CacheManager (Redis/APCu/File) instead.
• New Feature: Added "Clear VPN Check Cache" option to the Monitor Dashboard > Prune / Clear Logs page. Admins can now easily flush cached VPN/Proxy results to force re-validation of IPs without needing database queries.
• Bug Fix: Fixed a variable typo ($ip vs $ipAddress) in the Apple iCloud Private Relay detection service that potentially hindered correct identification.
• Technical: Optimized cache handling: Global API health status remains in SimpleCache for persistence, while high-volume per-IP validation data is moved to CacheManager for scalability.

This is a critical maintenance update highly recommended for all users, especially those with busy forums.

Highlights:

• Database Scalability Fix: We identified a limitation in XenForo's native SimpleCache system where storing thousands of VPN check results caused a "Data too long" database error on high-traffic sites. We have refactored the caching logic to separate these high-volume records into our own CacheManager system. This ensures your site runs smoothly regardless of how many IPs are being monitored.
• New Maintenance Tool: A new tool in the Admin Panel allows you to specifically clear the VPN check cache. This is useful if you want to re-check previously scanned IPs against the API without clearing your entire log history.
• Reliability Improvements: Fixed a typo in the iCloud Private Relay logic to ensure Apple users are correctly identified and not blocked when exemptions are enabled.

• New Feature: Added Apple iCloud Private Relay IP detection using Apple's official IP list (egress-ip-ranges.csv). The add-on now downloads and caches Apple's official CIDR ranges (refreshed every 24 hours) and checks VPN-flagged IPs against this list. This ensures iCloud Private Relay users are never blocked, regardless of what ProxyCheck.io reports.
• Critical Fix: Resolved an issue where iCloud Private Relay IPs were incorrectly blocked even when "Allow iCloud Private Relay" was enabled. The root cause was that Apple routes Private Relay traffic through Cloudflare/Akamai infrastructure, so ProxyCheck.io returned "Cloudflare" as the provider instead of "Apple."
• New Service: Added ApplePrivateRelayIPs.php service for fetching, caching, and validating Apple's official IP ranges.
• Improvement: "Clear API Cache" now also clears the Apple Private Relay IP cache, forcing a fresh download of Apple's IP list.
• Improvement: Enhanced keyword matching for Apple-related providers (added "iCloud", "Apple Computer", AS714, AS6185 as fallback checks).

This is a critical update that resolves an issue where Apple iCloud Private Relay users were incorrectly blocked as VPNs.

The Problem:
Apple iCloud Private Relay routes traffic through Cloudflare and Akamai infrastructure. When ProxyCheck.io scanned these IPs, it returned provider: Cloudflare instead of provider: Apple. Our previous detection logic searched for "Apple" or "iCloud" in the provider name, which failed to match.

The Solution:
We now use Apple's official IP list directly from mask-api.icloud.com. The add-on:

1. Downloads Apple's official egress IP ranges
2. Caches them locally (refreshed every 24 hours)
3. Checks every VPN-flagged IP against Apple's CIDR ranges
4. If the IP matches and "Allow iCloud Private Relay" is enabled → never blocked

Recommended Action:
For best results, also enable ProxyCheck.io's built-in whitelist:

1. Go to ProxyCheck.io Dashboard → Custom Rules
2. Click "BIG BUSINESS" category
3. Add the "Allow iCloud Private Relay" rule

This provides two layers of protection — at the API level and at the add-on level.

No database changes. Safe to upgrade on production environments.

• Critical Fix: Implemented a self-healing mechanism for the API Health Check. The system no longer relies on XenForo's internal cache TTL (which could fail in some environments) but uses explicit timestamp validation to auto-recover from API outages.
• New Feature: Added "Clear API Cache" option to the Logs > Prune Logs page. This allows admins to manually reset the API status via AJAX without reloading the page.
• Bug Fix: Fixed ArithmeticError: Bit shift by negative number that occurred when matching IPv4 addresses against IPv6 CIDR ranges (mixed IP version context).
• Bug Fix: Fixed TypeError: stripos(): Argument #1 ($haystack) must be of type string when handling array responses from ProxyCheck.io (Fixed provider/operator array handling).
• Improvement: Enhanced iCloud Private Relay detection logic to be stricter, preventing false positives for VPNs containing "Apple" in their name (e.g., "GreenAppleVPN").
• Improvement: The uninstallation process now performs a deeper cleanup, removing all internal API health and error cache keys to ensure a clean slate upon reinstallation.

This is a critical maintenance and stability update that resolves a persistent issue where VPN/Proxy detection would stop working after a period of time.

Highlights:

• Self-Healing API Mechanism: We identified that XenForo's database-based SimpleCache could cause API error flags to get "stuck," indefinitely disabling VPN checks. We have implemented a new timestamp-based self-healing system. If an API error occurs (timeout, quota limit), the system now automatically recovers and resumes checks after 10-15 minutes without any admin intervention.
• New Maintenance Tool: Added a "Clear API Cache" option under the Prune Logs page. If you ever suspect the API is stuck, you can clear the health cache manually with one click without uninstalling the add-on.
• Stability Fixes: Fixed arithmetic errors when comparing IPv4/IPv6 addresses and handled array responses from the API correctly.

• Improvement: Enhanced the logic for "iCloud Private Relay" detection. The system now uses stricter validation (checking for specific identifiers like "Apple Inc." or "iCloud Private Relay") to prevent false positives where unrelated VPNs with similar names were being whitelisted incorrectly.
• Fix: Fully resolved the data type mismatch (Array vs String) error when processing API responses, ensuring stability for all network types.

This update brings critical improvements to the VPN detection engine.

• Smarter Whitelisting: We've refined how the whitelist works for Apple/iCloud users. Previously, a loose check could allow unrelated VPNs to bypass the block if their name contained "Apple". The new logic is much stricter and safer.
• Stability: Fixed edge cases where API data formats could cause errors on certain server configurations.