yorman
Forum Replies Created
-
Wow! That’s so strange… but interesting nonetheless.
I cannot think of any reason of why that specific page is returning a “404 Not Found” status code. There is probably something in your server environment that is colliding with the variables that WordPress uses to identify the plugin pages.
I will pass this to my project manager and they will decide the priority with respect to other bugs. I will continue investigating once they pass the ticket back to me and will notify you when I find a solution.
This is the first time someone reports a problem like this.
Please answer the following questions so we can pin-point the root cause:
- Are you able to access the Dashboard page?
- Are you able to access the Firewall page?
- Are you able to access the Last Logins page?
- Does the problem persists if you disable all the other plugins?
- Did you experience this problem before or after version 1.8.14?
- Do you have 404 rules in your access control file (.htaccess)?
- Can you reproduce the issue using another user account?
- Is your current user account an administrator?
Please share any information that you consider relevant.
I have gotten similar reports from other users saying that — for some reason — all the settings are being automatically reset to the default values. I am still unable to reproduce the problem in my own servers, and was hoping that one or more of the changes released with the latest update would fix this once and for all.
I will pass this ticket to my project manager, they will decide what is the priority. I will continue investigating the issue once they pass the ticket back to me and will update this ticket with a solution once everything is clear.
You are probably seeing warnings stored in a cache.
Go to the settings page, there is a panel called “Data Storage” with a list of files that the plugin uses to store the settings, security logs and cache. Locate one called “sucuri-sitecheck.php” and reset it. After this, the plugin will be forced to execute a fresh scan and — if the malicious code was properly removed — the warnings will disappear.
You can also check this website [1]. Input your domain name, wait for the execution of the malware scan. If the cache is still in place, the results will appear in less than 3 seconds, if this happens you can click the “Force a Re-scan” link to force the cache expiration. If the scan takes more than +20 seconds it means the cache was already flushed and you will get a fresh scan.
That’s an interesting bug, considering that you have verified that the file is writable and the alerts are arriving to your inbox as expected. It may be related to some special configuration on WPEngine’s system.
I will pass this to my project manager and they will decide the priority. I will investigate further once they pass the ticket back to me. I will probably need to create an account with WPEngine because I just tested on my development server and the bug is not reproducible.
I will notify you when I find the solution.
Thank you for your inquiry.
We are currently in process of meeting the GDPR requirements which become effective on May 25, 2018. Once we have completed the necessary steps in regards to GDPR compliancy, the expectation is such that our clients will be notified of our status with the systems and processes we will have in place to comply with GDPR.
As for the exact evidence that we will be providing to our clients, we have a team working on our GDPR compliancy and as further progress is made, the understanding is that more information and updates will be readily provided and available. Thank you for your patience as our team dedicated to GDPR compliance is steadfastly working towards enacting new processes and standards in preparation of the May 25, 2018 deadline for GDPR compliance.
Regards.
@joeyblack — I apologize for not being able to offer you a definite solution to the problem reported in this ticket. I don’t have a suggestion right now to prevent the recurrent resets of the plugin’ settings as I am still unable to reproduce the issue.
However, I have two theories:
- The “sucuri-settings.php” file is being deleted by another process in the server. So we are not seeing a “reset” but a “create” action, considering that the plugin has to create the settings file again when it detects that it doesn’t exists.
- It is also possible that, during the WordPress updates, the core system triggers the execution of the “deactivate” hook, which is the action that the plugin uses to reset everything (settings, hardening, security logs, etc…). People have been reporting that the settings are being reverted to the default values with high frequency, more than the frequency we push a new update, so this may not be the case.
As you can see, both cases are caused by external actions foreign to the code.
I will contact my project manager to see if we can increase the priority of this ticket so I can investigate the problem more carefully and hopefully find a definite solution. I will mark this ticket as “not resolved” once again until I can provide a fix.
Thank you for your feedback.
The file “settings-hardening.php” is available here [1] with the rest of the code. A normal WordPress plugin update would have downloaded the entire Zip archive which includes this and the other files and after the extraction WordPress would have activated the update.
I am 100% sure that the problem that you are facing with your installation of Plesk cannot be fixed with a change in the release management from our side. I don’t know how Plesk handles an update, but it is possible that it was cloning the files one by one rather than downloading the entire update at once. You will have to check your Plesk configuration to know what happened.
Unless this is a recurrent problem with other users, I will consider this ticket an isolated edge case triggered by a misconfiguration of a 3rd-party software used to replace the WordPress update mechanism. If that’s not the case, please let me know and I will investigate further.
[1] https://plugins.svn.wordpress.org/sucuri-scanner/trunk/src/
Didn’t see a setting anywhere in Sucuri to turn that off – is that possible?
There is no option.
In fact, this is not the intended behavior of the Sucuri plugin.
I haven’t implemented any feature to do reactive blocking. The blockage must be coming either from another security plugin running in the background, or from an incompatibility between Ninja Forms and the Sucuri plugin, in which case I will need to investigate further comparing both code bases.
I will pass this to my project manager and they will decide what is the priority.
Hello @deeveedee I am glad you like our plugin.
I will pass your feature request to my project manager, they will assign a priority and I will implement the changes in a future version of the plugin. I will notify you once this feature is available.
Happy Easter.
Instead of a disclaimer why not display file contents?
This is already possible, just enable that option in the settings:
- Go to the plugin’ settings,
- Click on the “Scanner” tab,
- Scroll until “WordPress Integrity Diff Utility”,
- Click on the “Enable” button,
- Go back to the “Dashboard” page,
- Click on the files that you want to inspect,
- You will see the differences found in the file.
The majority of users are not tech-savvy, so having this option enabled by default would just confuse them and add more noise to the interface, consequentially increasing the number of tickets asking what is the meaning of this and that.
If you need to see the content of the files, it’s probably because you have some experience with programming, and so you will probably find the option to enable the “WordPress Integrity Diff Utility” by yourself. Just notice that in this specific case, the files in your WordPress installation were added, so there will not be any differences because the entire file is completely out of place, you can inspect the content using a file manager (via a hosting panel tool), SSH, or (S)FTP.
Marking as resolved, let me know if you need more information.
Thank you @eceleste for sharing your thoughts.
I agree with you, I will add the button to execute a fresh malware scan.
Hopefully, this and other changes will be released in 3-4 weeks after testing.
Lets answer that question taking a look at the code…
The error message is triggered here [1] after getting a negative response from a function defined here [2]. The function checks if four special classes are available in your PHP installation, these classes were introduced with PHP 5.3 so that’s why the message says that, but it doesn’t actually check if the version is equal or above.
It seems that your PHP installation, while being clearly above 5.3, doesn’t have one or more of these classes. This prevents the execution of the file system scanner, one of the main features in the plugin, that’s why it displays the warning.
Talk with your hosting provider and ask about this.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/8072151/src/interface.lib.php#L188-L191
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/8072151/src/fileinfo.lib.php#L103-L118@jeetkumar — if you used the “recover key” button to get a copy of your API key in your inbox, you should have seen a popup with a form where you can insert the key. If you didn’t see it, please click the button again and follow the instructions in the screen.
You can also use this link [1] just change “example.com” with your domain.
[1] http://example.com/wp-admin/admin.php?page=sucuriscan_settings&recover
Disabling the “IP Address Discoverer” option from the general settings page may also help. But this is only necessary if your web server has a misconfiguration that affects the speed of the DNS queries.
If you notice a significant difference in the speed of the website after disabling this option, I suggest you to talk with your hosting provider to address the issue on their side.