Enable XML-RPC by default and remove the option

[nacin]

Quite a bit has changed since we introduced off-by-default for XML-RPC. Their code has improved, and it is no longer considered a second-class citizen when it comes to API development, thanks to the work of a large team of awesome contributors. Security is no greater a concern than the rest of core.

There is no longer a compelling reason to disable this by default. It's time we should remove the option entirely.

*applause*

Removing the option enable_xmlrpc

Added a patch that removes the option enable_xmlrpc everywhere and removes the option from the database.

I'm not sure if removing the option is the best way. Maybe setting it to 1 on upgrade maybe fits better.

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

Introduced in #7157

Replying to blobaugh:

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

I can see what you mean but I disagree the reasoning. There aren't a lot of plugins adding XML-RPC stuff but the do for other things and plugins are a big cause of security issues. Also if you really want to disable it then just remove the xmlrpc.php file because plugins can add methods that are always accessible even when you put xml-rpc off in your settings.

Per an IRC discussion a few weeks ago, we won't be removing the ability to turn off XML-RPC via a filter. Just the UI and DB option.

In [21804]:

Turn XML-RPC on and remove the option on the Writing Settings page.
props markoheijnen for the initial patch.

Introduces a new filter, xmlrpc_enabled.

Respects any current callbacks registered to the pre_option_enable_xmlrpc
and option_enable_xmlrpc filters, for anyone forcing it off via code.

fixes #21509.

In [21818]:

Remove AtomPub from core.

• Will be replaced with ​http://wordpress.org/extend/plugins/atom-publishing-protocol/.
• Introduces an action, xmlrpc_rsd_apis, to add APIs to xmlrpc.php?rsd.
• Introduces support for 'error' being 403 and 50x in class-wp.php.
• Removes 'Remote Publishing' from Writing Settings (see [21804]). Keeps the remote_publishing settings section.

DB version is bumped to generate the new wp-app rewrite rule and remove the old enable_app option.

props wonderboymusic.
fixes #21509.

In [21819]:

Remove accidental cruft in [21804] caused by renaming variables. see #21509.

[21818] and [21819] belonged on #21866.

In my honest opinion, it's very dissapointed to see XML-RPC forced on and no way for admin of the site to turn it off from settings (hey! let admins make some decisions in their sites ;)).

It's not only a matter of security to closing some doors that you don't need to use, it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

Anyway, having a filter to turn it off is fine for me. But the fact is that using the new xmlrpc_enabled only stops from making login, but the XML-RPC server is still running (and responding), and even if you made login previously in the site through XML-RPC and you're still logged in, you can access even if you hook to the filter to turn it off :(

Removing the xmlrpc.php file form installation maybe is a solution, but not a professional one. For example doing that can create a lot of 404 error messages and therefore make Apache access.log grow with no valid reason.

Please, don't leave it this way. What about put the new filter in some other place to make XML-RPC server totally off?? ;)

it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

For what it's worth, Having XML-RPC enabled or disabled does not increase, nor decrease used system resources on a standard site. It's not a seperate "server", and the load it places on the web server be it enabled, or disabled does not vary. The only way that it can increase system resources if someone is actually using it (by that, I mean logging in with a correct user/password AND posting articles OR uploading media) - and in all cases, it should require less system resources than visiting your blog dashboard.

furthermore, XML-RPC was always "enabled" it simply disallowed logins when it was "disabled", It was still used for Pingbacks and trackbacks, as well as by many plugins for inter-server communication. The changes here are not a significant change in the way it works.

Please open a new ticket if you'd like to discuss removing the feature entirely from core, but know in advance, that's not happening. Your best bet would be to block XML-RPC access through .htaccess directly and watch random plugins break.

Just wanted to let people know, if you want the function disabled, and not just from logging in, but fully disabled, you can filter the class itself. The reason being, someone has already come out with an exploit for this, that turns WordPress xmlrpc.php into a port scanner. My fix was to create a plug-in that uses a similar filter to the one above, but instead of:

add_filter( 'xmlrpc_enabled', '__return_false' );

I changed it to:

add_filter( 'wp_xmlrpc_server_class', '__return_false' );

You can download the plug-in from my site, or you can just add that line of code, to your current themes functions.php file. If the theme updates automatically though, and replaces the file, you will have to add it back every time. This is why I created a stand alone plug-in to address this issue, since it can not only be used to port scan the local server, it can also be used to send false pingback spam to other sites.

You can read more here: ​http://www.attack-scanner.com/security/wordpress-3-5-xml-rpc-enabled-by-default-vulnerabilities/

Replying to digip:

I changed it to:

add_filter( 'wp_xmlrpc_server_class', '__return_false' );

Just because I stumbled upon it and read what you're suggesting to later readers: This is not a good idea. When you look at ~/xmlrpc.php, ​then you'll see, what WP calls immediately after allowing to filter the class. Guess what happens when you call

false->serve_request();

;)