Česlav Przywara

Hi @livingflame,

Thanks for pointing that one out. This file is missing the standard defined('ABSPATH') or die("Cheatin', huh?!"); check, I’ll add it.

Cheers,
Česlav

Hi,

Sorry, X-Mas are coming…

This issue is complex. The assumption here is that most of plugin users don’t know what server they have (not to mention version), so asking them for it makes no sense. Unfortunately, there is no reliable way how to determine this type of information via PHP, so we took <IfModule mod_authz_core.c> approach to support both older and newer Apache servers. This is de-facto standard approach, I think Wordfence and other security plugins (or rulesets like 6G) do exactly the same.

I don’t know if any of them can deal with active mod_access_compat. I can dig this issue further, but – to be honest – it has low priority to me, cause it is of no interest to my employer. I don’t know if any of the other plugin authors wants to pick up this issue (ping to @wpsolutions here).

You can always manually clean up .htaccess file from old directives and disable firewall rules in the plugin (and only use “Custom Rules” tab for black listing). I can’t really offer a better solution for the time being.

• This reply was modified 9 years, 4 months ago by Česlav Przywara. Reason: grammar

@vasseurb Please, start your own thread.

Hi,

The way plugin inserts the unlock request form changed, so this function has been renamed to AIOWPSecurity_User_Login::get_unlock_request_form(). As the name suggests, it now doesn’t echo the form, but returns HTML string with the form instead, so you have to echo the result yourself.

Also, the form is now a true form: <form> and </form> tags are included in returned string (it wasn’t the case before).

Sorry for breaking your implementation!

Cheers,
Česlav

Ok, I run some tests and I believe mod_access_compat is most likely the culprit. It allows you to use old syntax in .htaccess for Apache 2.3+, but reportedly can cause troubles when .htaccess mixes old and new syntax.

As I said, I run some tests on my development machine with mod_access_compat on and I can reproduce your problem only when I enable some other firewall features in addition to blacklist manager. I’m not an expert in this field, so it’s hard for me to say what exact rules are causing this issue.

I’m not sure if adding additional <IfModule mod_access_compat.c> checks makes sense here. For the time being, if you cannot disable mod_access_compat on your webserver, you can use the “Custom Rules” tab and insert the IPs using old syntax. I know it’s not that convenient, but it’s designed for such edge cases.

Cheers,
Česlav

Hi,

– The ability to immediate – at the first try – lock out ips that try to login with certain – configurable – login names (like admin when the admin name has been changed), preferrably with a longer – or infinite – lockdown time.

This option is already present in the plugin (User Login > Login Lockdown > Instantly Lockout Specific Usernames). The lockout time is however shared with other lockout options.

Hi Mike,

Is there a posibility to “test” if the blacklisting is even working at all?

Maybe there’s a service for this somewhere out there, but I always just block my own IP address/range when I want to test .htaccess this way. Of course, it’s better to edit .htaccess file via FTP instead of from within admin interface when performing such test 🙂

Rules created by AIOWPSF shouldn’t collide with each other.

Do you know what Apache version do you have on server? If it’s 2.3 or newer, maybe check if mod_authz_core module is enabled (you can find this in output of phpinfo for example).

I’m sorry, but I haven’t found any info about this “test cookie” (neither online nor in WordPress source code). I can only recommend to turn off the “Instantly Lockout Invalid Usernames” feature.