• Resolved webenefits

    (@webenefits)


    I have been using the “W3 Total Cache” plugin for performance optimization for many years and also use the “BulletProof Security Pro” plugin, as I have had the best experience with it so far in terms of security. Unfortunately, I periodically have the problem that when I call up the websites, only a white page is displayed and a 403 error code is returned. As soon as I log into the backend and clear the page cache of “W3 Total Cache”, the page is displayed correctly again in the frontend. For some websites this even happens several times a day, which is why I have already taken a closer look at the problem. I found out that an unwanted bot access was blocked by the plugin “BulletProof Security” just before the white page landed in the cache. I therefore suspect that despite the blocked access, a reload of the page cache is triggered with the blocked rendering. Unfortunately I don’t know with which workaround I can prevent this problem and hope very much that someone of you can give me a helpful tip to finally get the problem permanently under control.

    I regularly perform upcoming updates and therefore have the WordPress system and the installed plugins up to date. Neither on “W3 Total Cache” nor on “BulletProof Security Pro” I would like to do without, because these plugins provide in my opinion in the area of security and performance respectively the best solutions.

    Somehow it must be possible to prevent that the page cache is rebuilt by a blocked access anyway and thus a white page is stored in the cache. I am grateful for any hints on the solution.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @webenefits

    Thank you for your inquiry and I am happy to answer.
    The W3 Total Cache doesn’t care if it’s 403 or not. the 403 is generated by wp this time so it’s cached.
    W3 Total Cache cant know if some plugin decided to return something that should not be cached, the plugin should say that.
    e.g. define DONOTCACHEPAGE constant in this case.
    I’ve added the GitHub issue for this, however, this is something that you should also address to the BulletProof Security Pro support so they can add the constant for those pages.
    Thanks!

    BPS/BPS Pro redirects 403 errors to a custom 403 template page BEFORE whatever URI/URL/page loads using the htaccess directive: ErrorDocument. htaccess code is processed FIRST before any php code/pages/posts, etc. The BPS 403 template uses: session_cache_limiter('nocache'); to prevent the 403 template page from being cached. So if a 403 error occurs and since BPS redirects all 403 errors BEFORE any URI/URL/page/post loads then BPS is not causing this issue.

    Example: If a hacker sends an attack string/vector, etc. to URL/URI: example.com/some-page/ then the BPS security rules will block that attack and redirect that attack to the BPS 403 logging template. The URL/URI: example.com/some-page/ never loads (is not accessed/visited) because the attack will be redirected to the 403 logging template instead of being allowed to visit/load the URL/URI: example.com/some-page/.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Prevent white pages (403 Forbidden) from being cached’ is closed to new replies.