Disable APP and XMLRPC publishing by default

First pass patch. Still needs to actually stop APP working.

Patch adds the options, UI and lockdown for xmlrpc but needs the lockdown for APP implementing.

(In [8136]) Disable remote publishing by default. Add options to turn them back on. Props josephscott. see #7157

Leaving open for APP lockdown.

What a bummer. Terrible news for desktop clients. I hope the security enhancing tradeoff is very high because this will be a support burden on developers who are supporting users of desktop clients.

It's also worth noting that this will add friction to the process of using a remote client with WordPress, and therefore make other systems such as Blogger potentially more attractive to such users.

Daniel

We should of course consider making these options part of the 5 minute install like the privacy ones are.

Something like Enable Remote Client access - which would enable both types by default?

Adding the option to enable in the 5 minute install would help a lot.

(In [8139]) Allow enabling of remote publishing at install time. See #7157.

Will there be a way to find out whether the remote publishing is disabled or not? I.e. some meaningful error message when you call the disabled XML-RPC methods or a special method that answers "disabled/enabled".

As a weblog client developer I would like to let the users know that why the "publishing" failed and tell them what they should do to fix the issue. So I need to distinguish this error from all other types of errors.

P.S. BTW adding the option to the "5 minute install" won't help much. People install blogs, then, after some time, they discover remote weblog clients. By that time they have already forgotten about those options they saw during the install.

Great points UseShots?. I think you're right about the "deciding later" to use a remote client. All in all I think this change will be disappointing for remote editors, and their users, but I like your idea about at least providing a meaningful way of detecting this condition.

One of the major nuisances with Movable Type is that users are required to know about and then use a separate "web services" password. It would help a lot in their case if they just arranged for the authentication failure to explain what might be going wrong.

Is it at all worth considering a "secured mode" xmlrpc.php and app.php, that just returns an error stating that the user has not enabled access?

"Enable remote publishing using the WordPress, Movable Type, MetaWeblog?, Blogger and Atom publishing protocols for my blog."

If I'm a new blogger, or a first-time WordPress user, how does that make any sense? It's confusing enough that I bet people will check it simple because they have no idea what it does, and it can't cause any harm if it's a checkbox in installation, right?

I don't think this needs to be an option in setup.

Something's wrong with this option. I was unable to enable it on the Options->Writing screen and have the change actually stick. I had to go into the options table and manually set the option to "1" to make it work.

(In [8180]) Save enable_app and enable_xmlrpc settings. see #7157

Here's an alternate approach that returns a descriptive error rather than the generic method not found error. The patch isn't complete.

I am still not a fan of this change, and I've decided to write some public debate to at least hopefully get some thoughts moving about the possibility of taking another approach:

http://www.red-sweater.com/blog/512/wordpress-to-disable-remote-access

Replying to matt:

I don't think this needs to be an option in setup.

I agree with Matt. This is a distracting option for setup and also currently written in Geek. A descriptive error message resolves all scenarios I can think of.

Assuming you decide to go ahead with this , I agree a descriptive error message will be very helpful.

I can proceed with my patch and remove the install options while discussions continue.

New patches:

• Provide helpful error message when XML-RPC is not enabled. Now done as part of the authentication check.
• Provide helpful error message when AtomPub? is not enabled.
• Enable XML-RPC and AtomPub? when doing upgrades.
• Remove check box for enabling XML-RPC & AtomPub? during install.

The only XML-RPC functions that don't attempt to authenticate users are:

• demo.sayHello
• demo.addTwoNumbers
• mt.supportedMethods (which seems pretty useless in light of system.listMethods)
• mt.supportedTextFilters
• mt.getTrackbackPings
• pingback.ping
• pingback.extensions.getPingbacks

Turned XML-RPC and AtomPub? back on for upgrades to reduce the amount of surprised existing users will have.

(In [8202]) More informative error message when remote publishing is disabled. Don't disable if upgrading. Props josephscott. see #7157

(In [8202])

The atomPub errror message is not translated.

Pass the AtomPub? error message through the translation.

(In [8234]) Pass AtomPub? disabled messaged through translation. props josephscott. see #7157

$allow passed to not_allowed() is expected to be an array, and joined into a comma-separated list of allowed values. If we're going to use not_allowed() to output this warning in the Allow: header, the content should be a single-element array rather than a string.

However, it may be better to use HTTP Status 403 instead, since Status 405 "MUST include an Allow header containing a list of valid methods for the requested resource", not an arbitrary user-oriented string. With Status 403, WordPress "SHOULD describe the reason for the refusal in the entity" body, not through the Accept: header.

not_allowed() requires an array

Should use 403 Forbidden instead.

(In [8267]) Send 403 if publishing is disabled. Props AlanJCastonguay. see #7157