Even if you encounter blocking, please feel relax. There’re some ways to resolve it.
When and why am I blocked?
Well, actually there’re several rules to validate your requests in this plugin. Each of them is very simple but combination of them is very powerful to protect your sites. But sometimes, those are too strong for some plugins and themes to pass their requests.
One thing you should know is that all activities by an administrator are not always permitted in this plugin in terms of preventing CSRF and SSRF that are usually combined with other vulnerability and attack like XSS, SQLi, LFI and so on.
When you encounter blocking…
You will see the following window by default unless you setup a human friendly error page:
The “Dashboard” is a kind of safety zone protected by WordPress authentication system. None of important jobs would be executed there but just showing something useful about your site. So when you encounter the above message, following the link is always recommended unless you have something to keep before you leave the last page.
How to resolve it?
Step 1: Check your validation rule settings
If you can go to the admin dashboard and find the following message, please confirm your “Validation rule settings” not to block yourself out.
You can file some details in Get started.
Step 2: Check JavaScript errors
A JavaScript file named authenticate.min.js
has a very important role for this plugin. For example, “Referrer Suppressor for external link” is done by this script. But once a js error occurs, you might end in seeing “Sorry, your request cannot be accepted”. So please check js errors in your browser at first.
This codex document is very helpful to examine this step.
Step 3: Try “Prevent Zero-day Exploit”
“Prevent Zero-day Exploit” which I named WP-ZEP is the most powerful feature in this plugin to protect your site against undisclosed vulnerability. It can also distinguish the origin of request by a logged in user from an attacker using a scecret key called nonce that should be known only by a logged in user.
The priority of this rule is the highest in this plugin. So please try to enable / disable this feature in order to tell this plugin “The request is not from an attacker but from me!”.
Step 4: Find a blocking reason in logs
If the Step 3 can’t resolve the issue, please find the blocked request and look at the “Result”. The following is an example of /wp-admin/admin-ajax.php
blocked by “Prevent Zero-day Exploit” that is described as “wp-zep”:
You can find the full list of “Result” at this document in codex. Then please go to the next step.
Step 5: Give a permission as exception
If you can’t resolve the blocking issue up to the step 3, please try to give a permission to the concerned request as an exception.
– Admin area / Admin ajax/post –
In the case when a request related to wp-admin
is blocked, you can give it permission via the custom filter hook ip-location-block-bypass-admins.
For example, if the request has a query action=do-my-action
or page=my-plugin-page
, then you can add a code snippet into your theme’s functions.php
or /path/to/your/ip-geo-api/drop-in.php
(typically /wp-content/ip-geo-api/drop-in.php
) as below:
functions.php
in your theme when you set "init" action hook
as Validation timing. But when you select "mu-plugins" (ip-location-block-mu.php)
, you should use drop-in.php
because it’s prior to after_setup_theme. – Plugins area / Themes area –
If the requested URL is directly pointed to the particular plugin or theme, you can resolve its blocking issue by making an exception of that plugin or theme.
It’s also performed by ip-location-block-bypass-plugins and ip-location-block-bypass-themes.
Final step: Installation information
In case you can’t resove your blocking issue up to this step, I should help you to find a solution at support forum. Before submitting your issue to the forum, I expect you to get your “Installation information” at “Plugin settings” section.
Please copy and submit them. Those are very helpful to know what happens to your site.