dabrolga

In the case where WordPress is installed in a sub folder and the WordPress Address (URL) is not the same as the Site Address (URL) the following are not blocked at all, and show all information, from a not logged in browser on a not white listed IP:
https://example.com/wp-json/wp/v2/
https://example.com/wp-json/wp/v2/users
In fact I think all REST API requests starting with wp-json are not blocked.
I have the following REST API settings on Cerber 8.9.5:
“Stop user enumeration”, “Disable REST API” and “Logged-in users” all turned on.
“Allow REST API for these roles” and “Allow these namespaces” are both empty.

I am wondering if mrboats problem URLs start with http: as shown in his screenshot rather than the normal https:

Hi mrboats
I have had the same problem for a long time on all my sites where WordPress is installed in a sub folder and the WordPress Address (URL) is not the same as the Site Address (URL). Looking at your screenshot I am guessing you have the same configuration. I ended up using another method to block the REST API on those sites. The calls appear to be correctly blocked on the one site I have where WordPress is installed in the root.

Thanks, much appreciated.

Thanks for fixing this issue in version 8.9.5

I am sure there are no problems if WordPress Address (URL) = Site Address (URL). I am fairly sure the problem only occurs if WordPress Address (URL) != Site Address (URL) which is why only a few people have the issue, although a lot of people wouldn’t even be aware that there is a problem, because it doesn’t show unless logging is enabled. In our case WordPress Address (URL) is like https://example.com/subfolder and Site Address (URL) is like https://example.com.

Whilst function cerber_wp_login_page is a straightforward load of the default WordPress login script it is affected by the filter site_url which calls function cerber_login_logout. The interesting thing is that our setting for “Custom login URL” is like https://example.com/loginpage but our login page is and posts to https://example.com/subfolder/loginpage as set by the filter, I would have thought it should post to https://example.com/loginpage. It still works OK in most situations but I think it causes some problem here, also it would be nice if the login page was what was asked for in the “Custom login URL” setting.

Switching on “Deferred rendering” did solve the problem so this should be the accepted fix, thank you. I did read your article on that when I was first testing this problem but I didn’t consider it relevant because I was testing with no other plugins other than WooCommerce.

Thanks for your help to get to a solution for those affected.

The fix for me was to remove the Cerber “Custom login URL” setting and use another solution to redirect my login page. I have had no problems since. The bug appears to be coming from the function cerber_wp_login_page and this does nothing if “Custom login URL” is empty.

For those desperate for a quick and simple patch to fix this problem do the following edit:
In WP-Cerber v8.9.3 cerber-load.php change line 2806 from:
global $cerber_act_status;
to:
global $cerber_act_status, $cerber_been_here_before;
and change line 2809 from:
wp_clear_auth_cookie();
to:

		if (!$cerber_been_here_before) {
			$cerber_been_here_before = true;
			wp_clear_auth_cookie();
		}

This still allows the cookies to be cleaned up without the loop of death happening.
Warning! Make sure you do not do a Site Integrity scan or have any scans scheduled any time after changing this file or you will have problems because the file will be quarantined!

Hi Gregory
There were no “Must-Use” or “Drop-ins” plugins installed when the test was done on the staging site, except aaa-wp-cerber.php of course.
Thanks for looking at this.

Hi imrelaszlo
Are you running WordPress from a subdirectory? The site I have the problem with has WordPress in a subdirectory but the SITE-URL is the root of the domain. I have also found that the Cerber REST API restrictions do not appear to work correctly on my sites with WordPress in a subdirectory, but are fine on sites with WordPress installed in the root directory.

Hi Gregory
Thanks, no hurry as far as I am concerned, as it only affects the wc-admin part of WooCommerce. Our WooCommerce setup is very simple with no other WooCommerce-related plugins.

Thanks, much appreciated.

Yes, because the Details link is hidden I can no longer bring up the browser User Agent string. Again not a problem to me as I have built my own report, but it seems a pity not to be able to see that useful bit of information.
Thanks for the great plugin.

Hi
Unfortunately my hosting does not support 64bit PHP and as I just paid for a years hosting a week ago I cannot justify moving. So I am stuck with 32bit PHP. My quick fix was to change the the following columns to signed integer: cerber_acl.ip_long_begin , cerber_acl.ip_long_end and cerber_log.ip_long . This allows the negative values from ip2long to be stored and the logic all seems to still work without changing any code (I am sure I have missed something, but you know the code much better than me). I removed and replaced any large whitelisted and blacklisted IPs to store the negative value in the database. One just has to make sure that any range of listed IPs does not include 128.0.0.0 or thereabouts as this may cause major problems.

I assume that blacklists as well as whitelists will not work with 32bit PHP when the IP is larger than 128.0.0.0 on the standard setup.

Hi
It looks like it is the 32bit version of PHP that is the problem, rather than specifically the Windows version. I will try and get my hosting changed to 64bit next week, but there may be implications for others.

Hi
MySQL verion on the IIS host is 5.7.10, and on the Apache host 5.6.35.
Upon further investigation it would appear the problem is with the PHP function ip2long. On the Windows version of PHP it returns a negative integer for the larger IP addresses which of course get stored as 0 in MySQL because ip_long_begin and ip_long_end are unsigned integers. ip2long( ‘200.0.0.1’ ) tested outside of WordPress returns -939524095 on the Windows host and 3355443201 on the Apache host. Hope this helps.