yorman
Forum Replies Created
-
I see, so this is unrelated to the Sucuri plugin.
I would contact WordPress itself, and ask them if they have some sort of ban against these security plugins. I just installed a new WordPress website in a fresh server this morning and can install the plugins that you mentioned without problems. You should also contact your hosting provider, maybe they have blocked these plugins at server level for some reason.
Maybe for the next version of the plugin; thank you for the suggestion.
I cannot reproduce this issue.
I have never written code to explicitly create a post from the plugin, in fact, searching for any instance of
_postin the code [1] returns nothing related to the “create” or “insert” functions which are the ones used to insert data into the posts table. Even more, the plugin doesn’t stores any data in the database, instead it uses flat files to prevent it from messing around with the database.I believe you have another plugin installed that is intercepting emails through the
wp_mailaction and creating temporary posts for any reason, I know many plugins/themes do this as it is the only good available option to store data in WordPress. However, due to a bug the posts are not being deleted by the plugin/theme that is inserting them into the database. Then, in addition to another bug in the theme that you are currently using, the temporary posts are being treated as a normal post/page and displayed to the visitors rather than ignoring them via the post-type.However, this is just me speculating, I don’t know how your website works.
Please share more information about your website, list the additional plugins that you have installed, which theme is activated, and any other information that you consider relevant. Once I can reproduce the problem I will promptly fix it.
[1]
grep -rn "_post" -- src/*.phpThank you for the bug report.
I just submitted a patch to fix this error [1] it will be merged with the rest of the code when my co-workers review my changes, and we will release it along other bug fixes, with the next version of the plugin.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/43/commits/712723e
Yes, you did it correctly; please delete the file now.
I have checked the results and it is indeed clean, so we can be sure now that your server is hitting a clean node in the network, not a cached version of the scan. I will investigate the rest on my side, and will update this ticket when I have more information to share with you, I will try to find a solution by the end of the day.
I’m not sure how to send a request from my server. Any help here?
Definitely! There are two ways you can test this, one is to execute the following command in the Xterm emulator of your choice while connected to your server, this is if you have access to it via SSH.
curl -s "https://sitecheck.sucuri.net/?scan=www.whodunnknit.com&json=1&clear=1" | python -m json.tool
Another option is to create a PHP script, host it in your website and execute it via your favorite web browser. I wrote this script [1] for you so you can just copy and paste into a new file in your server using either (S)FTP or the file manager offered by your hosting provider in your cPanel account.
Notice that both options are just to check if the connection between your server and the Sucuri API is hitting a node in our network with an expired cache, which means, returning the old malware scan results with the warnings.
Let me know how it goes.
Thank you for reporting this bug, I will fix it as soon as possible.
There are two caches that must be flushed in order to get fresh results from this scanner, one is in your local server, in this file [1] which is automatically flushed every twenty minutes, the second cache is in SiteCheck’s API server which lasts for 48 hours.
The intermediate cache (the one that uses the file mentioned above) is necessary because a single scans takes around 20 seconds to load, if the scan was executed in real-time it would make your website very slow, so the plugin caches the response of this API [2] for 20 minutes. Once the local cache expires, the same process is executed again.
According to your post, the cache in SiteCheck’s server was already flushed, since it only lasts for 48 hours and you said that the problem has been occurring for over a week. It is possible that this file [1] is not being deleted after the local cache expires, and so the plugin keeps showing old data.
Try to delete this file manually and refresh the plugin’s dashboard. If this doesn’t works, send a request to this API [2] from the server where your website is being hosted, do not send the request from your computer, do it from your server as you need to verify that the cache in our CDN are actually flushing the content in the nodes closer to your server.
Let me know how it goes.
[1]
/wp-content/uploads/sucuri/sucuri-sitecheck.php
[2] https://sitecheck.sucuri.net/?scan=www.whodunnknit.com&json=1&clear=1No, it will not break anything.
The decision to use either PHPMailer or mail() happens in this piece of code only [1] and this piece of code is only executed when the Sucuri plugin is sending a security alert. It doesn’t affects other parts of your website, only the Sucuri alerts, so no hooks nor filters will be affected by this change.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/mail.lib.php#L76-L92
Sucuri is not molesting your mails no matter what option you choose.
By default, WordPress uses a library called PHPMailer [1] to send mails, and many people have reported that it causes issues when the website is served by some hosting providers, that’s why I decided to include that option, so people who are experiencing these problems can disable the usage of PHPMailer and instead use the built-in functionality offered by the server, which is to use the “mail” [2] function available by the PHP language.
[1] https://github.com/PHPMailer/PHPMailer
[2] http://php.net/manual/en/function.mail.phpThe deletion of the API key is caused by a response from the API service that reports the non-existence of a file that is used to store the security logs. Because this file is created during the generation of the key, the API assumes that if the file doesn’t exists is because the key was never generated. The plugin proceeds to delete the key as it “appears” to be invalid.
This is not a bug in the plugin, the plugin is simply reacting to the information that the API service is returning. The problem is in the server that is hosting the API, and I have no control over that machine for security reasons. I will send this to my project manager so the maintainer of the API can fix the bug.
Meanwhile, you can do this:
- Use (S)FTP or the file manager to access your server,
- Find and open this file [1] using a code editor,
- Jump to line 292 and locate this piece of code [2],
- Delete that line and save the changes
This should stop the plugin from deleting the API key on HTTP failures.
[1]
/wp-content/plugins/sucuri-scanner/src/api.lib.php
[2]SucuriScanOption::deleteOption(':api_key');Thank you for the ideas, I will pass them to my project manager, they will decide wether this will be implemented or not.
Yes, you have the correct configuration.
Please ignore the recommendation for now, Nginx usually adds these HTTP headers in lowercase, and SiteCheck is expecting to see some uppercase characters in the string, it’s a bug on our side that I already reported to my co-workers a few days ago; they are working on a fix. Once they push their changes live, the warnings will automatically disappear.
Thank you for the report.
I see, thank you for the list.
They are in fact the same files mentioned in the other ticket. I have now realized that WordPress changed the information returned by their API service (the same service that the Sucuri plugin uses) to include a list of possible language files that could exist in every valid installation of the CMS. Unfortunately, we have no way to know when WordPress makes those changes, breaking the functionality of the plugin.
I will fix this tomorrow and merge the patch with the rest of the code that will be released in the next version of the plugin. I will leave this ticket unresolved until the fix is publicly released. Thank you for your patience.
What is “securi”? Do you mean “sucuri”?
The “uploads” folders is the only directory in WordPress that is guaranteed to have write permissions, or at least is a requirement in order to use the media uploader. If we were to choose another location to store the plugin’s data (settings, logs, cache, etc) I would need to worry about the permissions of the custom directory which would create more friction during the installation time for non-technical people.
So the reason is: “convenience”.