bruandet
Forum Replies Created
-
The changes are in the JS code. Can you make sure to reload the profiler’s page or even to empty your browser’s cache before trying again? Maybe the old JS script is still cached?
I tried with FF versions 140.11.0esr to 151.0.4 and it worked.Here’s a new version 1.9.5: https://limewire.com/d/v6fWH#XL7DGXVATJ
Try it and let me know if it works.I’m currently testing FF 151.0.4 and I have the same problem. I was able to fix it, but that broke older versions of FF and other browsers as well (Chromium, Brave).
I’ll check tomorrow what can be done to fix it.Check in the Firefox console, if there’s anything that blocked the canvas or some sort of Javascript conflict with another plugin, it will likely be displayed in the console. Use
CTRL + Shift + Kto open the console.That looks like you are using a canvas blocker.
Inabout:config, searchprivacy.resistFingerprintingand make sure it’s set tofalse.
If it is already, do you have a privacy/anti-tracking extension installed on that browser ?By default, Firefox doesn’t block canvas because that would break a lot of websites.
Apparently, the wpmastertoolkit plugin can write to the .htaccess and wp-config.php files. Check their content, just in case.
All other file are CSS and look fine.Thanks for the detailed explanations, that can help other users.
The steps look similar to this thread: https://ww.wp.xz.cn/support/topic/can-not-active-full-waf-mode-in-openlitespeed-cyberpanel/It was fixed in version 6.7.54 ( https://www.sliderrevolution.com/changelog/ ), so you’re good if you’re using 6.7.55.
If you deleted the
bf_conf.phpand the captcha was still there, it would mean there’s likely another instance of NinjaFirewall installed in a parent directory and it is that instance that displays the captcha.
Do you have other sites protected by NF on that account?Can you run the troubleshooter script?
1. Download the script: https://nintechnet.com/share/wp-check.txt
2. Rename it to “wp-check.php”.
3. Over FTP, upload it into your WordPress root folder.
4. Go to https://YOUR WEBSITE/wp-check.php
5. Delete the script afterwards.
Please paste the results of the troubleshooter script here.Thanks for the suggestion, we’ll change that in the next release.
In the meantime, you can customise all email notifications sent to you by NinjaFirewall: https://blog.nintechnet.com/how-to-customize-ninjafirewall-wp-wp-edition-email-notifications/They are two different issues, the second one is a low-severity vulnerability.
- This reply was modified 2 weeks, 3 days ago by bruandet.
it gave 7.0.0 > 7.0.10 as the affected range, and 7.0.11 as the patched version
That’s correct.
The vulnerable function (_get_media_url) doesn’t even exist in versions 6.x.Try to copy the file to the subdomain, maybe that will work. That depends on your server configuration (DOCUMENT_ROOT environment variable)
If it doesn’t work, I suggest to disable the rule.The code looks fine.
You can also disable the rule that blocked the request: NinjaFirewall > Security Rules > Rules Editor > Disable rule #310.It looks like the .htninja file in the root directory had no impact on the sendy subdomain.
Maybe because of this line of code, i.e., the relative path wasn’t matching :
$script === '/settings.php'You can whitelist ‘GTranslate-Translation-Proxy’ using the .htninja configuration file.
This code will do:<?php
/*
+===========================================================================================+
| NinjaFirewall optional configuration file |
| |
| See: https://blog.nintechnet.com/ninjafirewall-wp-edition-the-htninja-configuration-file/ |
+===========================================================================================+
*/
if ( isset( $_SERVER['HTTP_USER_AGENT'] ) &&
( $_SERVER['HTTP_USER_AGENT'] == 'GTranslate-Translation-Proxy') ) {
define('NFW_UWL', true );
return 'ALLOW';
}