Which version of BBQ? I just tested the latest (20201209) on default WordPress and the Site Health report working normally.
Thread Starter
David
(@dkomando)
@specialk
Thanks for taking the time to look into the issue. I’m running the latest BBQ plugin as well. It’s happening on three of 20 or so of my sites, all running very similar plugins. Two of those sites do run Avada but one is Twenty Nineteen. At this point I am going to dig into the nginx configs since the “Site Health” > “Site Health Info” pages look nearly identical between a working and non-working site when all plugins have been disabled but BBQ. I’ll update my findings on what the conflict is if and when I find the issue.
Thanks again for looking into this and love the plugin!
Thread Starter
David
(@dkomando)
@specialk
So I ended up going through all my nginx configs and made them identical and still had the issue. Checked my WordFence settings and disabled all the plugins once again.
At this point I ended up slowly commenting out piece by piece in BBQ. When I commented out the conditional isset $_SERVER[‘HTTP_USER_AGENT’] the error went away. I then started working through deleting the $user_agent_array entries. When I got to ‘ninja’ the problem disappeared. I have the word ‘ninja’ in the domain of all three sites that were having issues. So somehow it seems that ‘HTTP_USER_AGENT’ is somehow seeing the domain name along with the User-Agent.
Also, to be clear when I print out the User-Agent from the plugin itself using:
print $_SERVER[‘HTTP_USER_AGENT’];
I get:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
I haven’t dissected the compare enough to yet understand what is happening here. I can dig deeper but guessing you may know off the top of your head whats happening to where User-Agent is interfering with the domain name itself. Also, guessing this would be easy to replicate by adding a word from the domain your testing from into the $user_agent_array, array.
Hopefully enough info to work with, if not let me know and more than happy to dig deeper.
Thanks for the great detailed report. It sounds like the ninja referrer pattern is the culprit in this case. I will remove that pattern from the firewall rules for the next plugin update. In the meantime, you can remove it easily using the whitelist plugin. Basically just follow the steps to add the following line:
$bbq_whitelist_referrer_items = array('ninja');
Again this is a workaround until the next version of the plugin is released.
-
This reply was modified 5 years, 3 months ago by
Jeff Starr. Reason: typo
Thread Starter
David
(@dkomando)
Jeff,
Just to be clear, this isn’t part of the referrer_items. This is coming from the user_agent_array. Not sure how the domain is being compared specifically with the User-Agent but it appears to be coming from that piece. Seems that the preg_match() for $user_agent_array is somehow seeing the site domain itself.
Using your code above with referrer_items did not fix the issue for me.
However, I set:
$bbq_whitelist_user_agent_items = array(‘ninja’);
which fixed the issue, thanks.
Thread Starter
David
(@dkomando)
I put some print statements into the plugin itself to see what was happening. From there I visited the “Site Health” page. Expanded the REST error and it looks like WordPress sets it’s User-Agent to the WordPress/version with the current site domain.
e.g.
The REST API call gave the following unexpected result: (403)
HTTP User-Agent: WordPress/5.6; https://domainnamewiththewordninja.com
Which seems to be where all of my problems are coming from regarding User-Agent.
-
This reply was modified 5 years, 3 months ago by
David.
-
This reply was modified 5 years, 3 months ago by David.
Right, sorry you are correct it’s the user agent array not the referrer array. Either way will get it fixed up for the next plugin update. Thanks again for your research and infos, much appreciated.
Thread Starter
David
(@dkomando)
Thanks, sorry to be a pain, I know it’s an edge case.
Not really, I was being overzealous when added the “ninja” pattern tbh. It’s just too common (too many false positives), and so will be removed.
Thread Starter
David
(@dkomando)
While I know the power of BBQ is it’s simplicity/speed, in which removing the word is probably smarter and easier. Granted, I adapted/wrote this code, which works (with very little testing done, could have errors!) to clear out words from the current domain.
if ( preg_match( '/' . implode('|', $user_agent_array) . '/i', get_bloginfo( 'url' ), $url_matches ) ) {
$user_agent_array = array_diff($user_agent_array, $url_matches);
}
Would go just before the existing plugin check:
if ($request_uri_string || $query_string_string || $user_agent_string || $referrer_string) {
Again, the simpler solution of removing the word is probably better but just another option if you wanted to keep words in the User-Agent check while clearing out false positives automatically.
Ah good idea. Definitely will consider this. The only catch I can think of would be when bots/scripts spoof the domain name as the user agent, which is fairly common.
Thread Starter
David
(@dkomando)
Gotcha. Yeah, that makes this pretty useless then. At that point it would need some kind of check to see if the site itself was running a cron or site health.
That may do the trick actually. I know there is an easy way to check if the request is cron, using wp_doing_cron(). Not sure yet how to check if the request is for site health. I think the infos in this post may provide some way of doing it.
