ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Remove XML-RPC specification

September 7, 2018 · 14:56 · Pieter Bos
Description

Voters
+85 more
Tags
Difficulty: Moderate
Request: Remove feature
Discussion
KTS915

I am not particularly keen on this one, unless there is a simple way to convert use of the XML-RPC spec to using the REST API. I think having a wide range of means of accessing CP will always be a good thing. I actually use XML-RPC on my localhost test sites (though never on a live site). I would prefer simply to have a simple on-off switch for XML-RPC, and for the default setting to be off.

Pieter Bos

That can also be an idea. As this one already has votes, I don't want to edit it anymore (if even possible), maybe open a new one that gives that option?

KTS915

OK, good idea!

James Nylen

Let's investigate which plugins this would break, especially widely used plugins. Jetpack is one.

Pieter Bos

Jetpack is a topic for a different discussion I think :)

James Nylen

I think it's pretty closely related. Before we can make any decision to remove or disable a feature, we need to know roughly which plugins it will break, and decide whether we are OK with that.

Pieter Bos

Yes, I agree about investigating which plugins it would break. What I mean about Jetpack, the mere fact that you need a wordpress.com account for it to work and it is constantly talking to wordpress.com, means that I would be inclined to vote the whole thing as restricted, meaning: has no business on ClassicPress. And of course I do realise that there are a bunch of people in love with that things, so that is why I said topic for a different discussion :)

invisnet

XML-RPC should be moved to a core plugin; if people need it they can enable it, if they don't they can delete it. This improves the security profile of CP without breaking backwards-compatibility.

KTS915

I like the idea of its being a core plugin.

James Nylen

I like the idea of moving less-used features out to plugins too.

However, we'd still want to handle other plugins that depend on those features. Still using Jetpack as an example: if someone requests to install Jetpack, we should prevent this unless the XML-RPC plugin is also installed (or auto-install it too).

This means we need to solve plugin dependencies before we can really start removing stuff, and calculate our own dependencies for at least the most popular plugins.

Dora D.
Pieter Bos

I agree with that James

BlogAid

What little my client's use of Jetpack (stats and VaultPress) doesn't require XML-RPC. I hard code XML-RPC off, as it is still the hacker's fave way to brute force the login page. It needs to go!

James Nylen

BlogAid: I think Jetpack is still using XML-RPC behind the scenes here.

BlogAid

James, agreed, but the 2 things I mentioned work with it turned off otherwise.

Avrom

I've done research on this. Yes its problematic, and can cause security issues (big time) - but its also a core function of how WordPress works and integrates with other plugins. Think this one carefully.

Duncan McClean

Don't know if this has been mentioned or not but XML-RPC is required to use the mobile apps for WordPress.

BlogAid

Is there any reason why those mobile apps can't use an API instead? Maybe deprecating this will light that fire.

Daniele Scasciafratte

Maybe we can migrate all the xml-rpc as external plugin, so for who need compatibility can have it but for the majority of users is removed from the core.

Avrom

@Daniele, sounds like a good approach.

Ian

If nothing else, the 'feature' that allows attackers to try hundreds of username / password combinations in a xml-rpc single call has to go. There is zero legitimate use for this and it's in active use against WP sites.

Daniel Hendricks

Agree with pretty much everyone. I believe XML-RPC should be disabled by default (including in WP) since it is enabled on probably 96%+ of sites that do not need/use it (though as @KTS915 mentioned, it should be easily enabled in settings, maybe even a question in famous 5-minute: "Enable XML-RPC? Note: This is only required by some external apps, such as the mobile app. If you're not sure, it is highly recommended that you leave it disabled."). The idea of separating it into a plugin would be okay as well, but a default-off checkbox in settings might minimize difficulties that may be encountered with future back-porting (?).

As it is, enabling the ability to hammer xmlrpc by default is lame.

Jesse

XML-RPC should definitely be removed from Core. As @James hit upon, the API is almost entirely retained for Jetpack + WordPress.com access:

https://wptavern.com/its-time-for-xml-rpc-in-wordpress-to-hit-the-road

When I wrote this piece in 2015, Matt Mullenweg lashed out, but did not clearly explain why he disagreed. We can assume it's because it would cause headaches primarily (only) for the Jetpack integration. And yes, I can confirm based on several years of managed hosting clients that disabling XML-RPC will break pretty much any Jetpack-infused services, like VaultPress, because those services check first that XML-RPC is enabled even if its not being used. In other words, it's almost entirely an Automattic-exclusive API at this point.

The REST API is already here, and its the future. Even Automattic's desktop client Calypso has already moved to that API instead of XML-RPC.

Besides Jetpack, I think the only other relevant software to mention here would be the Android and iOS apps for WordPress. But these have been poorly maintained for years, I wouldn't be surprised if the REST API takes over soon...

James Nylen

There are other third-party integrations that still use XML-RPC, like https://www.red-sweater.com/marsedit/ for example.

Daniel Jalkut

Thanks Jesse Nickles for alerting me about this thread, and thanks James Nylen for mentioning MarsEdit. It's a really bad idea to remove XML-RPC support for your fork of WordPress unless you want to eliminate support for all 3rd party clients, such as MarsEdit, that rely on it to connect to WordPress/ClassicPress.

For years I have been anticipating an eventual shift to the REST API but as of yet no clients such as MarsEdit can switch to the REST API because the only supported authentication scheme is cookie-based (in-browser).

Notably the WordPress iOS and (I assume) Android apps still use the XML-RPC API because they are also not able to reliably authenticate with self-installe WordPress sites for the REST API.

If ClassicPress wants to retain support for 3rd party clients such as MarsEdit, and for the WordPress.org iPhone app, then it should not remove the XMLRPC API.

James Nylen

Note we are not going to remove the XML-RPC API entirely, rather we are going to make it possible to disable this and other less-used features from within the UI.

Per discussion above and https://www.classicpress.net/roadmap/, this will be achieved by moving things out into core plugins which can be disabled or even deleted if desired.