In the last release 0.2.1.4, I announced the new feature to prevent self blocking. But this was not enough at the first installation. Every user hates a product which suddenly shuts him/herself out right after the first installation. This was the reason why I got one 
at the Reviews.
Preventing self blocking at the first installation
The solution is simple. You’re never blocked out while you’re logged in but just get an admin notice.
Actually, the issue was not a bug but the matter of design. For the user’s convenience, this plugin will automatically set the proper country code into the white list when the user install it for the fist time.
In the previous release, when this plugin could not get the proper country code for some reasons from MaxMind database which was automatically installed on your server, it would try to use other Free Geolocation APIs until it got the proper one at the first installation. But sometimes this mechanism will cause an issue when those APIs tell the different country codes on the same IP address.
Nils gave me a nice suggestion:
maybe a button to scan all selected APIs for the current IP would be helpful too?
Yeah, that’s a splendid idea !!
Yet even with this new feature, I can’t decide if this plugin should put all the country codes into the list automatically, because there’s a possibility that those codes would be undesired.
And futher more, if the ISP provides us a dynamic IP address, another possibility will come to block out ourselves with this initial setting.
So I decided to leave it to the user’s selection, but just prompt the notice at the first installation to confirm settings. I believe this design is the most balanced between convenient and inconvenient.
Pie chart for “Blocked by countries”
This is a substitution of a dull list for “Blocked by countries” using Google Chart library. Although it’s so not useful, I think it’s better than to display poor list.
Strengthen WP-ZEP against CSRF
WP-ZEP has an ability to prevent CSRF by verifying a special embeded token (called “nonce” which is one of the CSRF prevention methods) in the requests to the admin area, plugin area and theme area.
Suppose that you have a plugin or a theme which has vulnerability against the CSRF. If an attacker submitted a malicious link (which action is targetted to that vulnerability) into your site, and you accidentally click it, then you would excute undesired action. I call it “OSRF” – Own Site Request Forgeries. (Usually the attakers may use shortened URL. This is exactly CSRF !!)
Fortunately, WordPress comment system adds rel="nofollow" to the links which are submitted into the comments. Now in this release, WP-ZEP will stop to embed a nonce into the links which have rel="nofollow" in order to prevent OSRF.
Note:
If you submit a following sensitive link into your WordPress comment and click it, you’ll get “0” with status 200 OK. (Replace “example.com” to your home.)
http://example.com/wp-admin/admin-ajax.php?action=delete-post&id=1
Of course it won’t work. But basically the request reaches the WordPress core. Suppose that the above request was only for the admin and reached vulnerable plugin, the post id 1 would be deleted while you’re logged in as an admin.
Even though in this case, WP-ZEP for Admin ajax/post will refuse that request with the status 403 Forbidden. (It depends on your settings.)
Bug fix: Illegal handling of fragment in URL
If you enables “Prevent zero-day exploit” for “Admin area”, you would encounter the “Forbidden” message with a click at a certain link. It was caused by inappropriate handling for the Fragment identifier in URL.
Now this issue has been fixed. 