yorman
Forum Replies Created
-
This error message indicates that SiteCheck [1] which is the service that the plugin uses to execute the malware scans, is unable to connect to your website using the URL that the plugin is sending. This URL comes directly from the settings page using
site_urlbut you can configure it from the plugin’ settings page, in the “API Service Communication” section, in a panel called “Malware Scan Target” [2].In this panel you will find a blue box with a link that includes the URL that the plugin is currently sending to SiteCheck to initiate the scan. The solution is to change that URL to point SiteCheck to the correct address of the website. Every time you change it, make sure to click the link to see if SiteCheck is able to run the scan.
If you are having problems configuring this option, send me the URL of your website to my personal email at
[removed](removed to avoid spam) and I will run some tests, then will reply to you with the instructions to fix this error in your installation.[1] https://sitecheck.sucuri.net/
[2] http://i.imgur.com/rh5p8Nf.pngThank you for the suggestions, I will implement both of them.
I will keep this ticket open until the features are implemented.
The plugin scans this directory [1] to see if the Portuguese language file exists, if it doesn’t it checks if the same directory is writable and then proceeds to copy the English POT file to create a new this one [2] or this one [3] if your website is using the Brazilian version of the language. If this operation succeeds, the plugin will render its templates in English and leave the rest of the admin interface in Portuguese.
However, and this is probably what happened in your website, if the languages directory is not writable the plugin will not be able to copy the English POT file, it will proceed to change the global
$localevariable to English, this variable is the use that controls the language for the entire website, that is why you are seeing a mix of English and Portuguese.The solution to this problem is to grant write permissions to the languages directory. You can understand this process much better if you read the code available here [4].
[1] /wp-content/plugins/sucuri-scanner/languages/
[2] /wp-content/plugins/sucuri-scanner/languages/sucuri-scanner_pt_PT.pot
[3] /wp-content/plugins/sucuri-scanner/languages/sucuri-scanner_pt_BR.pot
[4] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/globals.php#L95-L166Many people sent me messages complaining because they didn’t want the plugin to log the passwords because they are constantly entering the wrong password when they are legitimately logging in to their accounts. I decided to convert this into an option and leave it disabled by default.
You can go to the plugin’ settings page, click on “Alerts” and scroll down to “Security Alerts” and check the box that says “Receive email alerts for failed login attempts including the submitted password”.
@eleven-sites — You are absolutely right; I fixed this here [1] please install the development version of the code from here [2] or wait until the public release of version 1.8.9 in a couple of weeks.
If you are going to install the development version of the code, please copy the API key, deactivate and delete the plugin from your website first, then download this Zip archive [3] and proceed with the normal installation.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/a5a0297
[2] https://github.com/cixtor/sucuri-wordpress-plugin
[3] https://github.com/cixtor/sucuri-wordpress-plugin/archive/master.zipHello again, I finished working in your website.
To be honest, I was not able to find the root of the issue, after several changes to the code I just learned that your website was not supporting internationalization at all, so it was not really the plugin’s fault, I went to the global settings page and changed the interface to French and it didn’t work, so I decided to download a fresh copy of WordPress and replaced the admin, includes and content directories, and now everything works.
I left the old directories in the server with a different name [1][2][3] in case that you want to compare the code between these folders and the ones that I installed. I reactivated all the plugins as well as the custom theme that you were using, none of them were involved in the problem that you were experiencing.
Due to limitations in the access to the server (no SSH for example) I couldn’t go into details of why the directories that you had before were blocking the translation of the interface. Please use a tool like Meld [4] to compare the content of these directories [1][2][3] with these other directories [5][6][7] considering that you have SSH access it will be easier for you to find out what was happening there.
Please visit all the Sucuri plugin’s pages and verify that everything loads correctly on your side, I tested here and everything looks fine. If anyone else stumble across a similar issue, please be sure to have “gettext” installed in your server and that both “wp-admin” and “wp-includes” contain the correct source code.
Let me know if you need more information.
[1]
/public_html/__wp-admin
[2]/public_html/__wp-content
[3]/public_html/__wp-includes
[4] http://meldmerge.org/
[5]/public_html/wp-admin
[6]/public_html/wp-content
[7]/public_html/wp-includesThank you, I received the link but it returns a “403 Forbidden” when I try to generate the password. Can you please whitelist my IP address temporarily?
[removed](removed to maintain privacy).Okay, lets do this… You said that you have a website where I can investigate this issue, does your offer still stands? It will probably be fast to investigate the bug in your environment than to wait for me to reproduce the issue in my own servers.
I will use the Plugin/Theme Editor to temporary modify the source code of the plugin to find the root of the error during the translation of the interface. Please be sure to grab a copy of the entire website and the database just in case; I will not modify anything unrelated to the plugin, but is better to be safe. You can send the credentials to
[removed](removed to avoid spam).@shklenny — I don’t understand what you mean by “logs in the back-office”, the plugin sends all the logs to the API automatically when they are triggered. Maybe a screenshot would help, that way I can understand where exactly are you seeing these passwords and give you a solution. Please sending it to my personal email
[removed](removed to avoid spam).@bruceinlouisville — did you receive that mail before or after the update to version 1.8.8? The current code [1] is supposed to translate “FailedLoginFooter” to this text [2] which basically contains an explanation of what the mail is about and how to disable such notifications. I have tested this several times and it works as expected, it makes me wonder what kind of configuration does your website has that the text is not correctly translated.
To answer your question, yes you can ignore that part of the alert for now, I will try to reproduce the issue and fix it for the next version, although the code that we released yesterday with version 1.8.8 was supposed to fix that once and for all.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/event.lib.php#L513-L520
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/languages/sucuri-scanner-en_US.po#L304-L306Awesome! Thank you for testing and verifying that the problem was with the cache.
For future references, the plugin stores the logs, settings, and cache in flat files in this directory [1] they are mostly JSON-encoded objects and can be safely deleted at any time without causing a disruption, even the API key can be recovered in the event of an accidental deletion of the settings file.
The cache for SiteCheck is stored here [2][3]; if the data in the cache has not expired the plugin will use it to display the information the dashboard, this makes the page load fast. When the cache expires after 20 minutes, the plugin requests a new scan to SiteCheck. Notice that SiteCheck has an independent cache system which stores the data for 48 hours, this can be flushed clicking a button at the bottom of the results page.
[1]
/wp-content/uploads/sucuri/
[2]/wp-content/uploads/sucuri/sucuri-sitecheck.php
[3] http://i.imgur.com/neVcCYi.pngWere the passwords in the logs submitted before the option was disabled?
The current version of the code [1] uses the same option for both the security alerts and the audit logs. If the option is disabled (as you already did) the plugin will stop appending the password in the mails and the logs. I believe that the passwords that you are seeing in the logs were sent to the API before the option was disabled. There is no option to delete the logs from the server. You would need to generate a new API key and start from scratch.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/hook.lib.php#L156-L162
There were several changes between versions 1.8.6 and 1.8.8 associated to the code that is communicating with SiteCheck to scan your website, but nothing that could cause a consistent 40x error. The plugin basically sends a GET request like this [1] decodes the response and reports back whatever SiteCheck found.
Give it a try, just change “example.com” with your domain name. If you can see the same error message in the JSON object then we will be sure that the problem is in the API, I will contact my colleagues and ask them to fix the error. However, if the error does not appears in the JSON object, we could consider that the problem is actually with the cache of the plugin, it caches the results from the API for 20 minutes and can be flushed form the settings page (from the data storage panel).
If you want, you can send me the domain name of your website to my corporate email at
[removed](email removed to avoid spam) and I will investigate the issue in my own server. Then will report back with a solution.[1] https://sitecheck.sucuri.net/?fromwp=2&json=1&scan=example.com
Step by Step and a screenshot here [1]:
1. Click the “Sucuri Security” in the sidebar,
2. Go to the plugin’ settings page,
3. Click in the “Alerts” panel,
4. Scroll down until “Security Alerts”,
5. Uncheck “Receive email alerts for failed login attempts including the submitted password”.I could give you more details, but I don’t know what is inside your website or hosting account that is be blocking the requests, I just know that SiteCheck is getting a “403 Forbidden” status code when it sends a request to your website.
If you are using a firewall, whitelist the IPs in the firewall. If your web server has a security module, whitelist the IPs in the security module. If your website has another security plugin, whitelist the IPs in that plugin. Maybe it’s your hosting provider the one applying the block rather than your website, talk to them and ask them for assistance, they have access to your server and the logs to know why the requests are being block. Once you have made the respective changes, verify that SiteCheck works using this link [1] changing “DOMAIN” with the URL of your website.
