Question About Caches

Hi,

This plugin, or any other that needs to perform distinct checks for each request, is not compatible with WP SuperCache. It won’t work as expected. I tried some workarounds and while I never locked out a non-Tor user as a result of a block page cached, it also won’t block Tor users correctly.

If you only enable Tor blocking for comments, logins, pings/trackbacks, registrations then those features will work fine. You just cannot use the “Block Tor users from all of WordPress” and expect it to work right with a cache that doesn’t execute all WP plugins or hooks for each request.

To use the cache and also block Tor users from each request, you’d need some kind of htaccess or nginx rule to run independently of WP and block or accept requests before serving the cache.

Hope that helps!

I am looking to block all Tor users, but I’m not bothered about them viewing pages that are already cached.

What I’m finding is a lot of hack attempts and these are not for “normal” pages but things like xmlrpc or “fishing” for .php scripts e.g. …..com/wp-content/plugins/poor_plugin/upload.php (which does not exist).

So only wanting to avoid them getting “past” already cached pages.

But if they went to e.g. …..com/my-trip and it was not already cached and they got a block message I’d not want everybody else (non-Tor visitors) to get the blocked page as that had been loaded into the cache by the previous blocked Tor visitor.

Hope that makes some sense (explaining stuff is not my strong point!).

Slightly off topic, I would suggest completely deleting xmlrpc.php or permanently adding a deny rule to block it so it doesn’t get put back by future updates. Unless you are actually using ping/trackback or post using some 3rd party system, there’s no need for it and it will be endlessly attacked as long as it’s there.

I couldn’t explain the behavior, but when I tested with WP SuperCache and cleared all caches and then accessed a page as a Tor user and got the full block message, I don’t think it cached itself. A Tor user could see previously cached pages and then occasionally get blocked, but I could never get a “blocked page” cached in my limited testing. Perhaps using wp_die() to show the page or block message prevents the cache from picking it up and being able to save it.

I would confirm caching was working, clear everything, access a bunch of pages from Tor and see the block message, then access as a regular user and get the regular page. Then I’d go back as a Tor user and see the cached version of the regular page.

If you have an existing site set up with cache and you’d be willing to test this with me, I can crawl a bunch of your pages with a Tor client right after you clear cache and then we can see if those get cached, we can give it a try. This would be more effective than the test site I have set up.

I do (have a site set-up using WP SuperCache and it’s a fairly quiet site (my worry is if you get visitors coming in during a test then it can mess things-up.

But I pre-load the cache though the number of pages that get pre-loaded seems variable. i.e. every hour a con job runs that often re-generates the cache (or checks the state of the cache – I don’t understand the details of WP SuperCache preload methods).

I’m a bit tied up this evening but if we can arrange some mutually convenient time I’d be happy to help using the site for testing. As it’s a quiet site, the WordPress cron system is run from the server cron rather than on page visits – so I’ll check what time it runs (as that could mess things up (and it was a bit of a fiddle getting it working to I’d prefer to avoid that time rather than stop the cron).

Are you Mac or Windows based? (trying to think of a real-time communications method; I’m Mac which would make iMessage on option, Jabber?).

And with the issues of privacy and the risks of posting any e-mail address, I’ll make some checks and maybe we can switch to exchanging contact details initially through the Contact page on my website?