Blobfolio

Thanks for the details, @nosilver4u !

Subnet search should be working again in 23.0.0. Please let me know if you’re still getting an error after updating.

Thanks @nosilver4u !

I don’t have any WPE-hosted sites to test, but from what I can tell, that feature isn’t causing host-wide issues anywhere else, and thankfully it doesn’t look like there are any conflicts with the FAIR plugin either. Every site I’ve looked at is displaying/fetching updates as usual, so that’s good.

If the WPE devs need more details, all Meow is doing is using the http_request_args hook — at priority 500 — to make three changes to the “parsed args”:

if (isset($parsed_args['user-agent'])) {
    $parsed_args['user-agent'] = 'WordPress/0';
}

if (isset($parsed_args['headers']['wp_install'])) {
    unset($parsed_args['headers']['wp_install']);
}

if (isset($parsed_args['headers']['wp_blog'])) {
    unset($parsed_args['headers']['wp_blog']);
}

I don’t mind boring details. Haha.

Thanks for the heads up. I didn’t realize the “trunk” trick had been deprecated.

I updated the stable tag for Meow to point to the latest release. Please let me know if that does the trick for you and I’ll go through and make the same change to my other plugins too.

Hi @the8055

The Community Pool is a self-contained co-op!

The raw data is supplied by the participating sites themselves, not independent “bad bot” lists or anything like that.

The Pool then boils down the aggregate into a digestible list of the widest and worst offenders, and returns it to the same participating sites so they can preemptively block those networks.

Hi @the8055

There doesn’t seem to be much overlap between Apocalypse Meow and those other plugins, beyond the three options in the Request Headers section. Just disable anything in there that the Headers plugin is handling separately, or vice-versa.

Neither 2FA nor CAPTCHAs are planned features for Apocalypse Meow.

The current WordPress flow isn’t well-suited to secondary challenges (like 2FA). It is possible to bolt extra steps onto the process anyway, but the resulting code complexity is high enough to risk introducing all sorts of new and terrible security vulnerabilities by mistake. Haha.

CAPTCHAs, on the other hand, are easy to add, but don’t provide any particular benefit in this context. The “login nonce” feature already blocks submissions bypassing the wp-login.php landing, and the fail-counting limit quickly puts a stop to any brute-force nonsense.

There are two different ways you can fix this (without manually patching the plugin):

OPTION ONE:

If .slave files are always zips, the simplest solution is to update your upload_mimes filter hook to use the appropriate ext/type pairing, i.e. $existing_mimes['slave'] = 'application/zip'; (rather than application/octet-stream).

OPTION TWO:

If you want/need to keep the files associated with application/octet-stream in the backend, you can hook into lotf_get_mime_aliases to programmatically expand the alias list used by Lord of the Files.

(This is equivalent to manually patching aliases.php, but saves you the trouble of having to repatch that file every time a new version of the plugin is released.)

function my_custom_mime_aliases ( $mimes, $ext ) {
    if ('slave' === $ext) {
        // $mimes should already have 'application/octet-stream' since
        // it inherits types known to WP (including custom upload_mimes
        // types), so you just need to add the ZIP type:
        $mimes[] = 'application/zip';
    }

    return $mimes;
}
add_filter( 'lotf_get_mime_aliases', 'my_custom_mime_aliases', 10, 2 );

Please let me know if either work out for you! I’ll leave the ticket open in the meantime just in case.

Thanks for reporting, @frenchomatic !

application/x-dosexec has been added to the type alias list for bin files in the latest version of the plugin (1.3.20).

Please do me a favor and retest that file upload once you’ve updated Lord of the Files just to be sure, but those files shouldn’t give you any more trouble. 😉

Sorry @website-rob, I just noticed part of my reply got cut off:

The wp-config tab shows you the potential constants you can define based on your current settings. Constants are an alternative way to configure the plugin, allowing you to programmatically autoset/force particular values.

When such locking is desired, the easiest way to figure out the appropriate constants/values is to configure the plugin using the GUI settings page first. Then once you’ve landed on a combination of settings you’re happy with, you can click the wp-config tab to see the equivalent constants, and add the ones you want to lock-in to your wp-config.php file. 😉