Blobfolio

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.

WordPress itself actually resets PHP’s default time zone to UTC early into setup to make it easier to construct “local” times using the stored site preference (a timezone string or offset or nothing).

Jeepers Peepers has been using UTC rather than site time for consistency, especially across multiple sites and servers, but you make a good point.

To that end, I just pushed a new release (0.5.4) with support for an extra config override, BLOBAUDIT_LOG_UTC, that can be used to toggle between the two choices.

Once you’ve updated, double-check your site’s timezone is set to the desired locale (Settings > General), then add the following to wp-config.php:

// Use site time instead of UTC for Jeepers Peepers logs.
define('BLOBAUDIT_LOG_UTC', false);

Log times should reflect the current site time rather than UTC thereafter.

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.

Hi @pixelcrash ,

The data array can contain any JSON-able content, including HTML.

On the template side, use triple curly brackets instead of pairs to render the HTML within.

For some reason Gutenberg is removing all the braces when I try to give you an example with three, so just imagine{{htmlcontent}} with an extra { and } on either end. Haha.

Note that I accidentally introduced entity encoding issues in the last release while trying to replace a deprecated PHP method. That should be fixed in 2.4.4.

• This reply was modified 4 months ago by Blobfolio.
• This reply was modified 4 months ago by Blobfolio. Reason: Gutenberg is breaking the formatting. Haha
• This reply was modified 4 months ago by Blobfolio. Reason: Gutenberg fail. Haha

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 confirming, @frenchomatic !

The multi-MIME problem is the main reason this plugin exists. I spent a couple years trying to address this in WP core itself, but there was zero upstream interest.

C’est la vie…

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. ??

Hi @4p0hk,

Unless you accidentally placed two define('BLOBAUDIT_LOG_PATH') lines within your wp-config.php file, it sounds like the WP bootstrap is running before your custom definition is getting read.

Generally speaking, any custom constants or settings added to wp-config.php should appear before any require or include statements, because those are where WordPress sneaks off to load all the plugins and themes and whatnot.

In the stock version of the config file — some hosting environments use a modified format, so yours may look different — that just means adding your custom bits before the line reading require_once ABSPATH . 'wp-settings.php';

As for the path itself, it should be absolute, e.g. /home/$user/$website/wp-log/jeepers-peepers-wp-syslog.log, and you should create the wp-log directory manually if it doesn’t already exist.

Did any of that help?

• This reply was modified 1 year, 10 months ago by Blobfolio.

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. ??

Hi @website-rob,

It’s a sort of double-negative situation. ??

Because the constants correspond directly to the GUI settings, true is equivalent to checked. If you set MEOW_CORE_BROWSE_HAPPY to true, for example, the corresponding “Disable Browse Happy” checkbox on the settings page will be checked, and browse happy will be disabled.

Hi @website-rob,

The wp-config constants correspond directly to settings in the GUI, which is why all three enumeration options are listed separately.

That tab is merely provided as a reference for you. Those constants won’t be in your wp-config.php file unless you add them yourself. (Anything defined in wp-config.php will no longer be changeable via the settings page.)

If, for example, you found that forced errors didn’t work correctly on your server, you could define only the DIE constant as a way to prevent yourself from accidentally turning it on in the future.

If you’re already handling enumeration-type logic via .htaccess, you can leave Meow’s functions disabled. Server-side controls are more efficient than PHP ones. ??

Interesting.

ActivityPub is probably looking for content with user IDs rather than following the site’s permalink structure, getting it into trouble with those other two settings.

I guess the answer for now is to just leave those last two options unchecked. Meow will still be able catch any bad actors once they move onto the login page.

Thank you for all the back-and-forth! Your feedback is much appreciated.

Thanks for confirming, @alexisj!

I just released a new version of Meow (21.7.5) that should fix the issue.

When you have a moment, would you please try updating Meow, turn “Prevent User Enumeration” back on, and see if ActivityPub is still happy?

I’ll leave this ticket open for the time being.

Thanks again!

Hi @alexisj,

I have a suspicion: Would you try re-enabling Meow and turn off (uncheck) the “Prevent User Enumeration” setting?

If that removes the conflict for you, I should be able to cook up a workaround that will allow you to turn those protections back on.

Hi @o815,

Thanks for the feedback!

If you update to the just-released 1.3.7 version of this plugin, you can now disable all LotF-related admin pages by adding the following to wp-config.php:

const LOTF_HIDE_MENUS = true;

If you happen to run into any upload-related issues down the road, you can just comment out that constant to regain access to the Tools > Debug File Validation helper page. ??

Regarding your comment on ticket #39963, it is unlikely these fixes will ever land in WordPress Core. Gutenberg is more or less WP’s only development priority for the foreseeable future. ??