yorman
Forum Replies Created
-
There must be something else in your website that is constantly checking for the existence of that constant and re-adding it to the configuration file once it doesn’t finds it. This explains why you cannot revert the hardening using the Sucuri plugin, because it was never applied using the Sucuri’s code. You probably have another security plugin running in place.
If you have SSH access to your web server, you could scan the entire website using this command [1] and find the code responsible for the addition of this constant. If you have no idea what SSH is, then simply disable all the plugins that you currently have installed, and activate one by one, eventually you will find the culprit if you check the configuration file every time you activate a plugin, leave the Sucuri plugin as the last one just to make sure that it is not the culprit.
[1]
grep -rn "DISALLOW_FILE_EDIT" -- $HOMEThank you for reporting this problem.
I will fix this now and merge the fix with the rest of the code in the development version of the project. Once the testing phrase has been finished and the project managers and co-workers in the development team have finished the review of my changes, a new version of the plugin will be released.
Thank you for your patience.
If I understand correctly, “Vibe Shortcodes” is a premium plugin provided by “Vibe Themes” which means that the source code is not publicly available in the WordPress marketplace, instead people have to pay them to get a copy. Because their plugin is not open-source I cannot check the compatibility between them and the Sucuri plugin, so I cannot offer you any solution.
You are paying them for the software, so it makes sense to ask them to fix the incompatibility with the Sucuri plugin rather than asking us to fix the problem because we don’t know how “Vibe Shortcodes” work, because — again — we don’t have access to the code. And even if we had a copy of their plugin right now, being outside of the WordPress marketplace means that they can modify the code without people knowing that the changes are about, which makes compatibility even worst.
Please contact “Vibe Themes” for support to get a solution for this problem.
Auto-drafts are automatically deleted after 7 days of going unused. They’re self-cleaning, basically. No need to worry about them. [1]
WordPress automatically saves your post while you are editing it, an action that they call “auto-draft”. If you don’t hit the publish or update button, then the post will be saved as an “auto-draft” and any modification to your will not be visible in your public site. Once you publish the post WordPress automatically deletes the “auto-draft” entries from the database, since this is an operation performed by your website itself it makes sense that the IP address is the same as the one used by your web server.
If you don’t want your website to create drafts automatically while you edit a post you can add this code [2] to your configuration file to increase the interval of the automatic saves. However, some people suggest that you should keep the auto-draft function enabled:
Auto-drafts exist because of the fact that multiple users can create new posts at the same time. If two people enter post-new at roughly the same moment, then have their first autosaves occur nearly simultaneously, then there is a race condition that can cause one of them to get back the wrong post ID, which will cause a post to be overwritten/lost when they then continue editing the post.
The auto-draft creates the post and gets the ID of the new post before the editing screen is displayed, thus preventing two simultaneous authors from accidentally having the same post ID in the data in their browser. [3]
[1] http://wordpress-hackers.1065353.n5.nabble.com/a-tp914p923.html
[2]define('AUTOSAVE_INTERVAL', 3600);
[3] http://wordpress-hackers.1065353.n5.nabble.com/a-td914.html#a917Go to the plugin’ settings page, in the “General” section you will find a panel called “API Key”, read and follow the instructions, you will get an API key right after that. The API key gives you access to the additional features provided by our API service.
Thank you for the suggestion, but the API key is already free for everyone no matter the size of their website.
I believe it is because Sucuri is not storing its settings in the database, but rather seems to be writing a file to the uploads folder?
That is correct, more specifically in this file [1].
SUCURI: Storage is not writable: /myname/public_html/wp-content/uploads/sucuri/sucuri-settings.php
This is the entire reason of why you are unable to enable/disable the security alerts. If the plugin has no access to write into this file then — technically speaking — it’s impossible to save the changes that you are trying to apply from the settings page.
I didn’t think it was considered proper to put a PHP file into your uploads folder, isn’t that a security risk?
Write permission is different than execution permission.
In Unix-like systems, there are three basic permissions that you can set to a file: read, write, execution. Allow the execution of a random file (no matter the programming language) is a bad idea in itself, but again, the plugin is asking for write permissions rather than execution, since none of the files in the “uploads/sucuri” directory need to be publicly accessible, they just need to be writable inside the server so the plugin can insert/delete data into/from them.
At least from what I have read; a quick search shows that most people recommend locking down the /uploads folder so you’re not executing php code there.
Locking down any directory with content that you don’t want to be publicly accessible from the Internet is a good idea. However, you are seeing this procedure incorrectly; in the context of WordPress websites, “locking down” a directory basically means that you are blocking access to it and/or any of its files from the web, but the server and any internal software still has access to it (unless you change the permissions, which is what is happening in your website).
You can keep your uploads directory locked down and grant write permissions to these files so the plugin can use them, this without affecting the security of the website. In fact, one of the features offered by the plugin — the Hardening — has an option that adds restrictions to the uploads directory to prevent the unwanted execution of publicly accessibly PHP files.
This must be a new thing, because there was no such message when I arrived on the settings page on a site where the plugin has been running for years.
The message is new, but the permission check is old.
The plugin used to fallback to the database to store the settings, that’s why people didn’t experience this problem with the file permissions before. However, this changed when it was decided that relying on WordPress’ would cause more problems than not, so we went full “flat files” and added the error message just in case something unexpected happens.
Sucuri is sort of vague about who gets notified. I would prefer to have an email address that is NOT an admin of the website, but some other address for a person whose job is just to monitor the notices. That person doesn’t need to be a registered user. It seems like maybe I could do this, in that there is a setting
Indeed! This is something that I need to change. I will include this as a feature request into our internal issue tracker. Once a priority is assigned to this task by the project manager, I will work on it and include it among the changes for a future update of the code.
SOLUTION: The solution to the issue mentioned in this thread is fixed by granting write permissions to the file linked below. Feel free to lock down the uploads directory to prevent the execution of PHP files, this lock down will not affect the reads/writes from the plugin. In fact, even if you grant them execution permission nothing bad will happen because these PHP files have no relevant PHP code, they just contain a call to the built-in
exit()function and then JSON-formatted data.[1]
/wp-content/uploads/sucuri/sucuri-settings.phpYes, all cronjobs can be executed via an URL for the same reasons explained above.
Some people configure their personal computers to send a ping to their websites every minute or so to guarantee the execution of all scheduled tasks. This is a very popular approach among web agencies that need to manage multiple website at the same time and want to keep their scheduled tasks running even if those websites have zero visits.
As far as I understand WordPress follows SEMVER [1]:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.
- Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
If WordPress is doing this correctly, any change in their code under the PATCH must follow the same API as the other patches, so if we [Sucuri] tested the plugin against WP4.8.0 it should work the same way for WP4.8.N where N is any positive number.
However, just to confirm, I tested the plugin today against WP4.8.1 and again with WP4.9 and everything works as expected. I actually run the automated tests for the entire codebase every day as part of our continuous delivery process [2].
Thank you for the interest; marking as resolved.
[1] https://semver.org/
[2] https://en.wikipedia.org/wiki/Continuous_deliveryThe plugin checks the integrity of the WordPress installation using data that comes from a public API service controlled by Automattic, the company who develops WordPress. In this case the language files are okay, it’s just that the data that is coming from the API is incorrect, and we [Sucuri] have no control over this.
However, because people keep reporting these warnings, I have decided to include the language files in the list of extensions that are ignored during a scan [1]. The development version of the code already contains this patch [2] so feel free to install it if you want to have an immediate solution or wait for the release of the update in a couple of weeks.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b88fd35
[2] https://github.com/cixtor/sucuri-wordpress-pluginI believe this is the same as this other ticket [1].
Marking as resolved, feel free to re-open this ticket if you believe that the issue is different to the problem described and resolved in the linked provided below. If you believe this is a new problem with the code please provide relevant information about your hosting provider so I can reproduce the issue and fix it, otherwise it will be impossible for me to provide a solution.
[1] https://wordpress.org/support/topic/wordpress-integrity-wont-load/
Feature implemented with commit #43627d5 [1].
Feel free to install the development version of the code from here [2] or wait until the official release of the next version of the plugin which will happen in a couple of weeks when my co-workers have finished the review of all the changes and all the testing has been done.
Thank you for the suggestion.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/43627d5
[2] https://github.com/cixtor/sucuri-wordpress-pluginFeature implemented with commit #03181ad [1].
Feel free to install the development version of the code from here [2] or wait until the official release of the next version of the plugin which will happen in a couple of weeks when my co-workers have finished the review of all the changes and all the testing has been done.
Thank you for the suggestion.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/03181ad
[2] https://github.com/cixtor/sucuri-wordpress-pluginThis is — technically speaking — not possible with WordPress.
The ability to set the time for the scheduled tasks is inherent to the way WordPress manages them. If you install the Sucuri plugin at 7:00 am one day the scheduled task will start at that time and then 24 hours later, this is 7:00 am the next day, theoretically…
The problem is, WordPress doesn’t uses cronjobs to manage these scheduled tasks, it basically just waits for any HTTP request from a visitor to trigger the code that checks for which scheduled tasks must be executed at the moment. If you haven’t received one single visitor in, lets say one month, the plugin will never execute the malware scanner because the scheduled task will not be executed by WordPress.
Basically, WordPress relies on the website visitors to execute these tasks; no visitors, no tasks.
However, assuming that your website gets at least one visit every day, you can reconfigure the time of execution of the scanner if you delete it at the moment when you want the plugin to execute them. There is a panel in the settings page for this, but again, technically speaking setting a specific time is useless considering how WordPress works.
[1] https://developer.wordpress.org/reference/functions/wp_schedule_event/
Since we are talking about WordPress plugins which are usually — if not always — written using the PHP programming language, I am going to assume that you are suggesting to add support for geo-location using the well-known GeoIP PHP Module [1]. Unfortunately, this cannot be accomplished without high-level access to each server that is hosting the website using the plugin because the installation of the GeoIP module requires both root access to install the databases (in some cases it can be skipped) and root access to install the respective PHP module (unless you are using a modern version of PHP that can read the databases using the raw files).
Many people who use the plugin are hosting their websites in shared hosting accounts, an environment that is so restrictive that asking for SSH access is just a dream. Implementing this feature would require not only time on development but also additional time on support because I would need to explain every single person in a shared hosting account what do they need to do in order to have this feature working in their web server.
As you can see, it’s a lot of work for little return.
However, I will add this feature request to our internal issue tracker and let my project manager decide what to do with it in the future. But I cannot guarantee its implementation. Thank you for the suggestion though.