Pascal

Yeah IPTables will do the job. Unfortunately iptables is not available for the majority of websites as they run on shared environments.

But I am glad you found other ways to solve your problems ??

The plugin is already as compatible with caching as it can be. If caching software chooses to ignore or is configured to override the do not cache headers the plugin sends there is nothing I could do more.

Caching software should either respect the do not cache headers (as pages can also contain personal information that should not be cached) or have an administrator that knows what it is doing when it chooses to overrule (some) do not cache headers and cache anyway.

I’ll assume this problem was caused in combination with a caching solution?

That is one way to do it yes.

However be careful as a very long .htaccess file may cause other (performance) problems as the webserver will need to parse the .htaccess file on every request for a match.

If your client uses caching that could as well be the problem yes.

The plugin tries it best to stop caching software from caching the denied message however if the caching software is configured to ignore or overwrite the caching headers the plugin sends a legitimate user may receive the cached result from a previous user that received the denied message.

I would recommend against using the plugin for blocking users from the frontend in combination with caching unless you fully understand the caching software. Using the plugin in combination with blocking the backend should not be a problem as caching should not be used for the backend.

If you use the IP check from within the plugin it should also indicate if the user is blocked from either frontend or backend as well. For instance:

IP Adress 70.28.11.95 belongs to Canada.
This country is not permitted to visit the backend of this website.

70.28.11.95 CA Toronto,
Ontario,
Canada,
North America 43.6667,
-79.4167 Bell Canada Bell Canada bell.ca

It is indeed registered to Canada. So I assume Canada was blocked from either the backend or the frontend or both.

Or perhaps an old database was used where this IP address was assigned to a different country.

Hi,

You can download the GeoIP Database from: https://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz

The file should be uploaded to the plugin directory.

If you need further assistance just reply ??

Hi,

Strange as this should be taken care of by checking of the GeoIP class exists.

What hosting company did you move to? And did you perhaps also install new plugins?

If you block the USA from your frontend this will affect the google bot from indexing your site.

I think in most countries google search is the most used in some countries however local search engines have a larger audience. But I assume that you will know which search engines those are if they apply to your country ??

If you know from which IP addresses the spam registrations are from you can lookup those addresses in the plugin and block that country.

Hi,

iQ block country has been tested on a multi site setup. So unless you have blocked your own country ?? it should work.

Hi,

The latest version is not tested on that version. The plugin was first developed on v2.9.x so the basic functionality should work.

The only uncertainty would be the admin page.

Anyway you should be able to install it, check the admin functionality and if it doesn’t work remove this plugin (please do tell if it does not work !). The plugin is non-destructive.

Users from a country will be blocked from visiting your site so this is both registering as well as filling in a contact form. You can also choose to block people visiting the admin side of your website.

Hope this helps. If you would like with a little work I will also be able to test it on your specific version.

Hi Pevista,

You can already do that by just selecting all countries except your own. Perhaps not the way you would like though.

Perhaps it is an idea that if you install the plugin all countries are default selected except the country from your originating ip address. That would not help existing users though.

Your situation seems quite unusual. As you have no access to the logfiles I am afraid I cannot see what goes wrong in your situation nor can I reproduce it in my own environment.

So I am not able to check what is wrong and have either an answer or solution for you. This does not mean this happens a lot. For most users the plugin works just fine but in some rare conditions it won’t and I’d be happy to help out but there is only so much I can do without the tools that I need.

As far as I know there is no plugin that gives the same information I require as I would receive from the actual webserver logfiles.

Thank you very much!

When I try to login at your backend I receive the forbidden message. So so far so good.

Do you have access to your webserver logfiles? These hack attempts may bypass the plugin by using a different login url. But I need to match an ip address with an login attempt and the real url it uses. Best way to track these requests is from the webservers logfile.