I whad to delete and reinstall all of my plugins. I am now getting an error message that says “Stop XML-RPC Attack Plugin Error: Could not write to .htaccess file. Check your file permissions and then re-generate your .htaccess from the plugin settings page.”
However, when I view the .htaccess file, I see the code inserted by the stop-xmlrpc-attack plugin. File permissions for the .htaccess file are 644.
What should I do?
]]>So I’m not much of a PHP programmer, and OO code really makes my head hurt, but I’ve got over 100 sites using this plugin and the error message about “Stop XML-RPC Attack Plugin Error: Could not write to .htaccess file. Check your file permissions and then re-generate your .htaccess from the plugin settings page.” is really getting tired. So I tried looking in to it today.
It appears that under some circumstances the init() action is not getting called, because when that error occurs it’s because the $this->htaccessFile is actually not set and it’s trying to create/modify/whatever a file with literally no name. I have a very hackish solution, here’s the diff:
(5) diff -c stop-xmlrpc-attack.php.ORIG stop-xmlrpc-attack.php
*** stop-xmlrpc-attack.php.ORIG 2016-12-18 17:00:49.702906622 -0500
— stop-xmlrpc-attack.php 2016-12-18 16:53:40.422928706 -0500
***************
*** 283,288 ****
— 283,289 —-
}
function write_to_htaccess($data) {
+ if ($this->htaccessFile == ”) { $this->init(); }
if (@file_put_contents($this->htaccessFile, $data) === false) {
update_site_option(‘stop_xmlrpc_attack_error’, ‘Could not write to ‘ . $this->htaccessFile . ‘ file. Check your file permissions and then re-generate your .htaccess from the plugin settings page.’);
} else {
Yes, that is adding a line that literally checks to see if the htaccessFile location is an empty string, and if it is, calls the init() function. It quits complaining this way.
Anyone out there better at this than I am care to create a better fix? This is the only plugin that does exactly what it does, so getting this fixed and the plugin tested with current WP and the whole thing updated would be pretty awesome…
]]>The company that hosts my site (Hostpapa) suggest that I install plugin Stop XML-RPC. But I see that the plugin has not been updated for a while and has not been tested with my version of WordPress. Do I really need it? If so, what is the risk of installing it?
]]>The plugin uses the old Apache 2.2 access commands
order deny,allow
deny from all
allow from 1.2.3.4
even when it is running on Apache 2.4. Unless the access_compat module is enabled, this leads to a server error. When a future version of Apache drops even that support for the old way of doing things, this will affect you too ??
There’s an unofficial patch at the project’s git page.
]]>When I activate it, I get a…
“Stop XML-RPC Attack Plugin Error: Could not write to .htaccess file. Check your file permissions and then re-generate your .htaccess from the plugin settings page.”
.. message. But the .htaccess file has, in fact, been written to.
]]>The iOS app is being blocked.
Please advice if there is something I could do.
]]>Hi there,
I think it would be great if you add the option to exclude Zapier IP addresses or user agent from being blocked.
Zapier is a popular service and uses the XMLRPC method as well.
]]>Trying to get this running. As far as I can tell, I’ve given the .htaccess file the permissions the plugin needs, but it still complains it can’t write to .htaccess.
Can you please be specific in the installation instructions (1) which .htaccess files need permissions (root or just WP root or what) and (2) the specific permission settings required? Also, given that this plugin says it adapts as Jetpack changes its IP block, does the .htaccess need to be permanently set for these permissions, rather than just during the installation of your plugin?
Thanks.
]]>Hi, my website citrotux.org gets hits on it’s xmlrpc.php file from 146.185.251.102 which route, according to whois, is 146.185.251.0/24 (Russian federation), and your “Stop XML-RPC Attack” doesn’t produce any effect against this one. I have installed it at 6:25 pm my time, so the above IP should not appear anymore, at 7:11 pm.
Also, there is “192.0.84.33” from Automattic (legit request) which isn’t in the allow list produced by the plugin. So I added it’s CIDR manually.
Any thoughts why the plugin does not work against this russian IP?
Thanks.
]]>Hi! I’m just wondering, those .sh files, the makefile, and the tests folders… aren’t an active part of the plugin, right?
AFAIK, those will not be executed in this version. And in future versions?
]]>