Description

When using the IP restriction feature on a site that leverages caching, particularly via a CDN or other server-side cache that sits in front of WordPress, it’s possible for restricted users to view cached content even when their IP is not allowed.

This occurs because requests from disallowed IPs may never reach WordPress, meaning the plugin cannot execute and restrict access. Instead, the user is served a cached version of the content generated by a previously allowed IP. This represents a security loophole, especially for sites relying on IP-based access control as a protective measure.

Expected Behavior

If IP restriction is enabled and caching is detected, the plugin should:

1. Warn the admin that IP-based access control may be unreliable due to active caching.
2. Optionally disable the IP restriction toggle in the settings UI unless a bypass is explicitly enabled.

Proposed Solution

✅ Step 1: Detect Caching

• Reuse or extend existing caching detection logic (e.g. for Batcache, opcache, WPEngine, Pantheon, or CDN headers).

• If caching is detected:

  • Set a flag internally (e.g. ip_protection_cache_conflict = true).

✅ Step 2: Display Admin Warning

• Display a prominent warning in the plugin settings:

  "IP-based access control may not function as expected because site-level or CDN caching is active. Requests from disallowed IPs may still be served cached content."

• If possible, indicate what caching system was detected (e.g. "CDN Detected: Cloudflare" or "Page cache plugin active: WP Super Cache").

✅ Step 3: Disable IP Protection Setting (Optional)

• Disable the IP protection toggle by default if caching is detected.

• Allow enabling via:

  • A filter:

    add_filter( 'rsa_enable_ip_restriction_with_cache', '__return_true' );

  • Or a "danger zone" UI toggle in the settings with explicit messaging:

    "I understand the risks of using IP restriction with caching and want to enable it anyway."

Relevant Background

• Prior versions of the plugin have shown warnings for Batcache or OPcache being enabled when access restriction could be affected.
• This is an extension of that logic to cover CDN and full-page caching scenarios that happen before WordPress is bootstrapped.