Support

Hello, Admin Tools Professional 7.9.1 on Joomla 6.1.2 shows the "Core file verification unavailable" warning after every PHP File Change Scanner run. I traced the cause: my server *can* reach `getpanopticon.com` perfectly (DNS, TLS and routing are fine, response in 0.1 s), but Cloudflare serves it an interstitial challenge page instead of the checksums file. Critically, it is returned with **HTTP 200 and `content-type: text/html`**, so Admin Tools sees a successful download and then fails to gunzip it. **Server outbound IP:** 62.193.193.15 (Belgium, shared hosting) **Test results** (plain cURL from the server, PHP 8.4.23 / cURL 8.21.0): | Test | URL | User agent | Result | |---|---|---|---| | A | /checksums/joomla/6.1.2/md5.json.gz | `CoreSumsTest/2.0` | HTTP 200, text/html, 11956 bytes, title "One moment, please...", `cf-ray: a267978bdd35985a-BRU`, `cf-cache-status: HIT` | | B | same | Chrome 139 desktop UA | identical, `cf-ray: a267978c0b245631-BRU` | | C | same | `Joomla/6.1 (Admin Tools CoreSums)` | identical, `cf-ray: a267978c3d222211-BRU` | | D | /checksums/ | Chrome 139 desktop UA | identical, `cf-ray: a267978c7a57b1ce-BRU`, `cf-cache-status: MISS` | | E | / (homepage) | Chrome 139 desktop UA | identical, `cf-ray: a267978cfcc43d1a-BRU`, `cf-cache-status: DYNAMIC` | `https://getpanopticon.com/cdn-cgi/trace` from the same server returns: ``` ip=62.193.193.15 uag=CoreSumsTest/2.0 colo=BRU http=http/2 loc=BE tls=TLSv1.3 ``` Notes: - The challenge is served regardless of user agent and on every path including the site root, so this looks like an IP-reputation or ASN-level rule rather than bot filtering on the checksums endpoint. - The same URL returns the correct gzip payload from other networks, so the service itself is healthy. - Requests reach the BRU (Brussels) Cloudflare colo. **Requests:** 1. Could you allowlist this IP (or exempt the `/checksums/*` path from the challenge, since it serves static public files to servers rather than browsers)? 2. Would you consider having Admin Tools validate the response `content-type` / gzip magic bytes and log the actual body when it is not gzip? Right now a challenge page returned with HTTP 200 produces only a generic "could not download" warning, which makes this failure mode hard to diagnose. Thank you.

Follow-up with a controlled comparison. I ran the exact same test script from a different host, on a Portuguese ISP (outbound IP 62.233.41.62, Cloudflare colo LIS), and every request succeeded: /checksums/joomla/6.1.2/md5.json.gz -> HTTP 200, content-type: application/x-gzip, 229111 bytes, valid gzip, 819011 bytes of JSON cf-ray: a267ae9a093ce3b8-LIS Same result for all three user agents (generic, Chrome, Joomla). /checksums/ and / also returned the real pages, not a challenge. From the blocked server (62.193.193.15, Belgium, colo BRU) the same URLs return the "One moment, please..." interstitial regardless of user agent. So the trigger is IP/ASN reputation on that outbound address, not the request itself. My site is migrating to the working network in a few days, so this is no longer blocking me. Two things may still be worth your attention: 1. Other customers on Belgian shared hosting are likely hitting the same wall silently. 2. The failure is invisible to Admin Tools because Cloudflare returns the challenge with HTTP 200. Checking the response content-type or the gzip magic bytes, and logging the first bytes of the body when they do not match, would turn this from a generic "could not download" warning into a one-glance diagnosis.