Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix multiple bugs with the API calls and queue system #40
This pull-request includes all the bug fixes applied to the code before version 1.8.7 was released.
This also includes a fix for the display of the newsletter invitation which was appearing in places that we didn't intend it to appear like the result of the plugin updates and other parts of the admin dashboard. From now on, the plugin will only display this invitation inside the pages associated with the plugin; notice that this modification also excludes the Ajax requests.
This pull-request also changes the status of the three hardening options that suggest the user to block the execution of PHP files in the core WordPress directories. If the plugin detects that the website is behind the Sucuri Firewall it will mark these three options as applied automatically, this is because the Firewall has built-in features to prevent the execution of vulnerable files (not only PHP but also other extensions) in places not intended by the developer.
This also includes a fix for a rare case where the plugin was deleting the entire content and uploads directories. This was happening because an admin can change the location of the storage folder for the plugin' settings, and if the directory was the same as the content or uploads directories the plugin would delete them if the admin requested the deactivation of the plugin, which eventually triggered the deletion of the settings, security logs and the parent directory where these files are contained.
Some modifications to the code that powers the audit logs panel. This includes the error messages at the bottom of the table and a fix for the order of the logs when the data from the local queue system is merged with the data coming from the API service, they will be now ordered correctly by the date when the event was triggered.
This pull-request also adds an option to allow admins to force the plugin to stop sending email alerts for events associated to a post status transition, for example, when a post is changed from being a draft to published, or from being private to trash, etc. This will help some users to reduce the amount of alerts that they get in their inbox due to the amount of data in their websites.
A fix for an infinite loop when a custom SMTP plugin is installed along the Sucuri plugin. In this scenario, the Sucuri plugin will send an email alert to the admins when a successful or failed login is detected. The message is intercepted by the custom SMTP plugin and then (for some technicalities in their code) a temporary object is created before the message is sent. The Sucuri plugin detects the creation of this temporary object and sends an alert to notify the admins, and here they both fall into an infinite loop.
This pull-request also modifies the execution of the tools available in the "Firewall (WAF)" page, they will be now retrieve the data for the settings and audit logs via Ajax, and the execution of the cache flush will also run via Ajax to make the interface more responsive.
This pull-request also adds a new option in the "Firewall (WAF)" page to allow users to blacklist IP addresses when the Firewall API key is available. Notice that this option is only available to Sucuri customers, and more specifically those who have purchased the Firewall. Additionally, the plugin will automatically blacklist any IP address who fails log into the website more than five times during the same day. Users will have to ask one of the admins to log into the Firewall dashboard to unblacklist them.
Add an option to configure the automatic flush of the Sucuri Firewall cache (disabled by default). Every time a page or post is modified and saved into the database the plugin will send a HTTP request to the firewall API service and except that, if the API key is valid, the cache is reset. Notice that the cache of certain files is going to stay as it is due to the configuration on the edge of the servers.
Add smart limit to send logs from the queue to the API. We will use the maximum execution time setting to limit the number of logs that the plugin will try to send to the API service before the server times out. In a regular installation, the limit is set to 30 seconds, since the timeout for the HTTP request is 5 seconds we will instruct the plugin to wait (30 secs - 5 secs) and an additional one second to spare processing, so in a regular installation the plugin will try to send as much logs as possible to the API service in less than 25 seconds.