yorman
Forum Replies Created
-
I will mark this one as not-resolved for now while I investigate the issue. Thank you for your patience.
The plugin provides additional features to the premium services, but not as many to justify the installation if you already are a premium customer and are using the Sucuri Firewall, or in your case GoDaddy CDN.
If GTMetrix is not reporting the CDN yet, it may be because the DNS replication is still happening. If this continues after several hours, I suggest you to ask GoDaddy Support about it, since they are in control of the system, I have no access to customers accounts to know what is happening.
Because you created five tickets about the same issue [1], you just need one to get my attention, they other are duplicates, so I marked them as resolved. I will only work with one.
Thank you for the report; marking as resolved.
Thank you for the report; marking as resolved.
Thank you for the report; marking as resolved.
This URL [1] is the one that is being used by the Sucuri plugin to check which files are corrupt or not. This API is maintained by WordPress itself, the organization, not Sucuri.
Your suggestion to create this list in the Sucuri servers was already tried some time ago, but it posed more problems than a solution because people would complain a lot after every new WordPress update because the database in our servers would not synchronize immediately, but it would take a couple of minutes to download the latest version of the CMS including all the tens of supported translations. I went ahead and decided to remove that code from the plugin and start using their public API, since they are the ones releasing the new version of their CMS it makes sense to wait for them to put up the checksums on their API instead of rolling our own solution.
If you access the URL linked below and search for any of the files flagged by the plugin as corrupt, for example,
admin-nb_NO.poyou will find this checksums [2]. Now, if you log into your server and obtain the checksum of the same file you will notice that the hash is different, that is what the plugin is reporting. So the solution to this problem must be implemented by Automattic, the maintainers of WordPress, be we [Sucuri] have no access to the source of that API.[1] https://api.wordpress.org/core/checksums/1.0/?version=4.8.1&locale=nb_NO
[2]admin-nb_NO.po -> 81cdf0024fdcd95dece6fa18afbc46f8Can you please enable the “WordPress Integrity Diff Utility” option available in the “Scanner” panel of the plugin’ settings page? Once this option is enabled, please go back to the plugin’s dashboard and click any language file that is marked as “modified” (one of the POT files if possible, since they are still in plain text). A window show appear showing the differences between the version that you have installed and the one provided by WordPress.
The data used to determine if a file was modified or not is provided by a public API maintained by WordPress, this API accepts a locale as a parameter, so if your website is in French the API should return the checksum for all the files associated to the French version of WordPress. If there is a modified file is surely because WordPress is incorrectly tracking those files.
That is why I suggest people to ignore those warnings for now, because we have little power over that information, we could include a hardcoded list into our own code, but if WordPress changes something in their files at any time, we would need to release a new version of the plugin immediately, which would make the development very erratic.
There is not an official option to obtain all the logs within a time period, at least not in the plugin, but the API service is public and you can query your own data for inspection. Use this link [1] to access the latest 999,999 logs associated to your website, replace the
API_KEYtext with your own API key. You will obtain a JSON-encoded object (like in the example below) that you can load into your favorite JSON viewer.{ "status": 1, "verbose": 0, "action": "get_logs", "total_entries": 9907, "request_time": 1505755439, "output": [ "2017-08-11 15:38:00 noreply@example.com : Info: 127.0.0.1; WordPress version detected 4.9-alpha-41238", "2017-08-11 12:47:30 noreply@example.com : Info: admin, 192.168.1.53; A total of 2 alert events were changed", "2017-08-11 12:46:10 noreply@example.com : Info: admin, 192.168.1.53; A total of 1 alert events were changed" […] ] }[1] https://wordpress.sucuri.net/api/?k=API_KEY&a=get_logs&l=999999
I am 100% sure that this is a cache issue, there is no other explanation.
Send me the URL of the website to
[removed](email removed to avoid spam) I will try to replicate the issue in my own installation and check the expiration time for the cache generated in the SiteCheck service. However, I am fairly sure that this problem will be resolved by itself, just waiting a bit more until the cache flushes itself, we can try to flush it manually though; send me the URL and we can continue from there.Marking as resolved as this is going to be resolved in private.
Questionable security at best, and horrible customer support
Thank you for your criticism; it was a bit harsh considering that you didn’t provide any details to explain your point of view so other users can understand why exactly you consider our security “questionable” and our support “horrible”.
I am proud to say that the Sucuri WordPress plugin has one of the most responsive customer support in the market, always trying to help customers and non-customers to resolve their issues, not only security related enquires but also tech and non-tech (which to be fair we are not supposed to be answering, but we still do because we want to help everyone).
I know that you created your account today explicitly to write this review, thank you for taking the time to do that, but please consider to expand your essays when you write a review, specially if you are writing a critique because it helps us improve the bad aspects of our business and also helps other users to understand the progress of our products and services. Apply this to any review that you want to write in the future about other companies, not just ours.
Thank you once again.
This is not a problem with the plugin, so a new release will not fix it. The problem is with the code that powers SiteCheck [1] which is the server that is being used by the plugin to scan your website. Even if the plugin sends the correct URL, the API service will still try to scan the lowercase version of the address.
I already talked with my co-workers, and more specifically to the developers who maintain that code base, they will make the appropriate changes if necessary, some of these business decisions are taken because some of our customers have a special setup so am not sure if this is going to change soon or not.
ALTERNATE SOLUTION: You could create a symlink between then directory with the uppercase character into one where all the letters are in lowercase, this way you don’t have to change anything. You could also create a redirection rule in your access control file, in fact, this sounds like the real solution to me and you can apply it immediately.
Thanks for the report, I will check the compatibility between these two plugins.
[…] But the worst thing it does is disable the plugin page with this error.
This is a WordPress thing, it automatically disables any plugin or theme that fails to load during the execution of the “init” hook. This is a fail-safe way to keep running your website without being affected by whatever the plugins are failing for.
Can you please share which page of the Sucuri plugin is triggering the memory allocation error? This only happens when a piece of code is assigning too much data into a variable that the server can handle. I an address this issue today if you can tell me which page is triggering this message.
When the plugin is preparing to request a scan it sends the naked domain name to a remote API service here [1] which then sends multiple HTTP requests to your website in order to search for signs of an infection. Sometimes people install their websites in certain way that the plugin cannot understand and decides to send a incorrect domain name which SiteCheck cannot reach, hence the message “404 Not Found”.
In your specific case, it seems that your website is not here [2] but here [3] so you have to go to the “API Service Communication” panel in the plugin’ settings page, scroll to the bottom and change the value for the option “Malware Scan Target”, you have to put the real URL of your website so SiteCheck can scan it.
EDIT: I have to clarify, what I stated above is true for most cases, but in your website it seems that the installation path is using a letter that is in caps, so instead of being
newsiteyou are usingNewsite, SiteCheck doesn’t understands this and decides to send the request to the first one which doesn’t exists, that is why the plugin doesn’t works in your installation. You will have to use the website for now until we can fix the issue, or you can change the name of the directory to be all in lowercase.Marking as resolved, feel free to re-open if you need more information.
[1] https://sitecheck.sucuri.net/
[2] http://www.cantabsrowing.org.uk/
[3] http://www.cantabsrowing.org.uk/Newsite/
