2 questions
-
1. Do I need a unique email each time I generate an API key for a new website? We have 20 websites. Does that mean we need 20 different emails OR can we use the same company email for each website’s API key?
2. We are using Google Cloud Platform (Hosting) with Kinsta.com. I noticed that the WordPress Integrity will not fully load in Sucuri (it says Loading…). Is there a server setting that could be preventing this from fully loading?
Thank you
-
1. Do I need a unique email each time I generate an API key for a new website? We have 20 websites. Does that mean we need 20 different emails OR can we use the same company email for each website’s API key?
You can generate the API keys with the same email address. As long as the combination “email + domain” are unique in the system, the request will be accepted.
2. We are using Google Cloud Platform (Hosting) with Kinsta.com. I noticed that the WordPress Integrity will not fully load in Sucuri (it says Loading…). Is there a server setting that could be preventing this from fully loading?
There is no server setting that needs to be switched on to activate the WordPress Integrity tool. I believe there is an incompatibility between the code that powers this utility and the way Kinsta configured their servers. The “Loading…” text stays there infinitely because there was a server error that prevented the Ajax request to load the result of the scan.
I have a contact at Kinsta, I will check with them to see if they can troubleshoot the issue for me, because I have no account with them so I cannot do it myself. Once they reply back, I will send a patch to our development repository to include the fix with the next update of the plugin.
Wonderful, thank you for your detailed and swift reply Yorman!
Hi @yorman
A Kinsta rep replied with this:
I think this is easy enough to solve actually, if you can pass this on to Sucuri folks:
PHP Fatal error: Uncaught RuntimeException: SplFileInfo::isFile(): open_basedir restriction in effect. File(/www/websitename/public/..) is not within the allowed path(s): (/www/websitename/public:/www/websitename/mysqleditor:/www/websitename/web:/www/websitename/deploy:/www/websitename/deployment:/www/websitename/deployments:/usr/share:/tmp) in /www/websitename/public/wp-content/plugins/sucuri-scanner/src/fileinfo.lib.php
Why is it trying to open the parent directory for scanning? I think that might be a mistake. I think the solution is simply for them to catch exceptions on the foreach ($objects as $fifo) { block – I’m not sure what the correct behaviour is, but basically what’s happening is Sucuri’s scanner is trying to scan your public/ dir, which is okay, but the first file in there (after “the directory itself”) is the parent dir, which our PHP engine is raising an exception for because there’s absolutely no reason for a PHP script to attempt to open files out there. Because they’re not catching that exception, PHP is terminating the script with a fatal error.
I tried adding exceptions for that directory (/www/websitename/public/..) in different permutations but couldn’t get the scan to run anyway, I think it’ll require changes to the code to get it to work (they probably want to be gracefully handling exceptions in that loop anyway, really).
I hope that leads them in the right direction!
Ah okay! I understand, thank you for contacting Kinsta.
This error was fixed in August 14, 2017 as you can see here [1].
Unfortunately, the fix was just recently merged (21 days ago, on Dec 11, 2017) as you can see here [2]. My co-workers in the development team are still running unit, integration and vulnerability tests against the new code base to verify that all my changes are correct. If you check the pull-request, you will notice a lot of changes, that’s why it is taking some time for these modifications to be released to the public.
Feel free to download the development version of the plugin from here [3] or wait until the official release of the update which will happen in a couple of weeks. I will notify my project manager that this bug will be fixed with this update so they can consider a faster release process.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/commit/2795c7e
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/43
[3] https://github.com/Sucuri/sucuri-wordpress-pluginHi Yorman,
Thank you, Kinsta said:
“Awesome!
You might ask them if it’s possible to exclude that directory from being scanned somehow, as it looks like it’s going to log an error every time because of open_basedir, but that’s more of an annoyance than anything.”Definitely!
I will make the appropriate modifications to exclude all the directories contained in the
open_basedir
whitelist during a malware scan. Thank you for reporting the problem. I will make sure that the fix gets included in the next update.Happy New Year ??
Thank you! I’m just curious, did you create Sucuri or are you one of their top engineers? Happy New Year!
By the way, you said “I will make the appropriate modifications to exclude all the directories contained in the open_basedir whitelist during a malware scan.”
You mean “to exclude all the directories NOT contained in the open_basedir whitelist” correct? – Kinsta asked
-
This reply was modified 7 years, 2 months ago by
audiowarrior.
[…] did you create Sucuri
No, I am just one of the many developers working at Sucuri. The company was funded by Daniel Cid and Tony Perez [1]. Later, we joined GoDaddy after an acquisition at the beginning of 2017.
[…] are you one of their top engineers?
I wish ?? but no, I am just average in the Sucuri hierarchy.
By the way, you said “I will make the appropriate modifications to exclude all the directories contained in the open_basedir whitelist during a malware scan.” You mean “to exclude all the directories NOT contained in the open_basedir whitelist” correct? – Kinsta asked
Ah yes! My bad, the naming of that variable is confusion — and I am not a native English speaker — what Kinsta said is correct: I will modify the code that powers the WordPress Integrity tool in the Sucuri plugin to exclude all the directories NOT contained in the “open_basedir” whitelist”.
Thank you @yorman
Can you please post here when they’ve added the changes in the official release? The development version seems to work, I tested it.
hi, any news when this will be officially pushed to the new release? thank you
Hello @zonwarrior
I don’t have any news when this fix will be officially pushed to the new release. The patch that handles the runtime exception is already available in the development repository here [1] that you can download from here [2].
But the modifications requested by Kinsta.com to consider
open_basedir
during a scan is still in the backlog of my TODO list, there are other tasks with more priority right now so I haven’t had time to work on this. The priority of this change is low because it is not really affecting the functionality of the website, it’s just a “nice thing to have” requested by Kinsta. You will probably receive a notification from your WordPress installation about the update once we release the new version.Thank you for your patience.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/43/commits/2795c7e
[2] https://github.com/Sucuri/sucuri-wordpress-pluginHi @yorman
1. What is the difference between the patch and open_basedir request? I thought they were the same request lol. What is this ‘nice thing to have’ ?
2. I’ve been noticing my diskspace moving up on my websites that have sucuri. My suspicion is that sucuri is storing security logs on my server, and that’s why it’s growing. Is there a way to delete all my old security logs to make space on my server?
Thank you
Hello @zonwarrior
What is the difference between the patch and open_basedir request?
The patch fixes the PHP exception that is preventing the WordPress Integrity tool to load. The “open_basedir” request is a modification requested Kinsta.com to force the plugin to scan the directories specified in this setting during a file system scan, and skip any directory outside the tree.
I thought they were the same request lol.
They are conceptually related but technically speaking are two different things. One is a bug (the one I patched) and the other one is a feature request (the one requested by Kinsta.com).
What is this ‘nice thing to have’ ?
I was referring to the request made by Kinsta.com; the feature request to skip the directories not specified in the “open_basedir” setting. I say that it is a “nice thing to have” because if I don’t implement this feature nothing will be broken. Kinsta.com requested this change to reduce the number of logs in their system, because according to them, their system is still logging the exception even if the PHP script is gracefully handling it.
I’ve been noticing my diskspace moving up on my websites that have sucuri. My suspicion is that sucuri is storing security logs on my server, and that’s why it’s growing. Is there a way to delete all my old security logs to make space on my server?
This may be related to the logs created by Kinsta.com and that’s why they requested the modification besides the patch that I already submitted. However, this is just speculation from my side, as I don’t have access to an account in their servers to check what is actually happening.
You can delete the security logs stored in your server using the “Data Storage” panel located in the plugin’s general settings page. You can also manually delete the logs which are all located here — “/wp-content/uploads/sucuri/”
-
This reply was modified 7 years, 2 months ago by
- The topic ‘2 questions’ is closed to new replies.