Call for testing beta

Posted on May 11, 2021

I’ve developed my plugin IP Location Block as a security purpose plugin which protect the back-end of WordPress since version 2.0.0 on 2015. But since then, I’ve received many requests and suggestion that it would be better to have blocking ability on the front-end.

At the time when I released version 2.0.0, I though that the most robust and secured state for WordPress is a state just after clean installation which has a default theme and no plugin (of course, with strong password). Actually, more themes and plugins we have, more chances to be compromised we have.

But in reality like other plugins, I can’t provide a perfect solution to my users. The only approach I should aim is to reduce chances to be attacked and compromised. So I decided to equip this plugin with the ability of “Blocking on front-end”.

New feature: Blocking on front-end

You can find the “Front-end target settings” section on the Settings tab.

Front-end target settings

Matching rule

You can follow the rule at “Validation rule settings” or set a rule that is different from the rule for back-end.

Permitted user agent string and qualification

You must be sure to grant permission to search engine bots or crawlers such as google, yahoo and being. This feature is possible to fulfill your wishes by giving a particle pair of “user agent string” and “qualification” separated by a colon “:”. These are described as follows:

Particle Description
user agent string A part of user agent string. Uppercase and lowercase letters are distinguished. An asterisk “*” matches all strings.
FEED True if the request is the feed url.
HOST True if the result of reverse DNS lookup is available.
HOST=string True if the host name by reverse DNS lookup includes string.
Country code True if the request comes from the specified country.
IP address (CIDR) True if the IP address is within the specific range.

Previously, this plugin would keep the IP address and country code in the option table using transients API as a cache mechanism to reduce the load of fetching IP address databases. Now in this release, those will be kept in the independent table named ip_geo_block_cache and also in the cookie of user agents. A nonce will be embedded in the cookie so that the attackers can’t sent out a forged country code.

Using cookie cache can be enabled at “Cache settings” (default is “Enable”).

Cache by cookie

Setup for testing

An important notice: If you are a user of caching plugin such as WP Super Cache or W3 Total Cache, you should configure these plugins to use “PHP mode” (in case of W3TC, “Disk: Basic“) and turn on “late initialization” option. If your caching plugin doesn’t support similar options, i.e. in case of redirecting by mod_rewrite in .htaccess (WP Fastest Cache) or advanced-cache.php drop-in (Comet Cache) , “Blocking on front-end” feature might lead to generate inconsistent pages.

Before installing the beta version, you may backup your settings by “Export settings” at “Plugin settings”. Then please download zip archive, unzip it and follow the next steps:

  1. Deactivate your IP Location Block.
  2. Upload whole of ip-location-block in the unzipped archive into your plugin’s directory on your server. The previous version can be overwritten.
  3. Activate IP Location Block again.

How to test

You can find “Public facing pages” on “Logs” tab. The option “Record validation logs” at “Record settings” is better to be set as “Unauthenticated user” to check the functionality.

Logs on front-end

You can also get the result of reversed DNS lookup on “Search” tab.

Reverse DNS lookup

May have something to feedback

Although I’ve made sure that it would not break anything in an obvious way, please keep in mind that this is a developing version. It might still contain undiscovered issues. When you find or notice something, please let me know about them in the comment of this post or at the forum.

So I would deeply appreciate for your kind cooperation emoji .