Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Who's afraid of XML-RPC?
XML-RPC as an administrative interface for desktop blogging clients has been around since Textpattern 4.0.3 as a separate download package. For Txp 4.0.7, we have plans to integrate this functionality right into the stock download.
Recently, a blogging platform with an apparent inclination towards perpetual security enhancements decided to disable the XML-RPC server by default and enable it only at the administrator’s discretion. This would reduce attack surface for those who run their sites with disabled XML-RPC interface, but on the other hand won’t help users a lot who need the feature.
Q: Should Textpattern have this switch, too?
Discuss.
Offline
Re: Who's afraid of XML-RPC?
Could this be just a radio button preference in the Admin tab?
TXP is ahead the competition as far as the security of the cms. That for me is more important than having to add entries from my desktop instead of my browser.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Who's afraid of XML-RPC?
colak wrote:
Could this be just a radio button preference in the Admin tab?
This is how it would look like, yes. I wouldn’t add any other warning or instructions, just a plain on/off radio.
It should be noted that this option won’t increase security, it will merely reduce the attack surface for those who switch it off. As XMLRPC would be a part of Textpattern (and has been since 4.0.3), we must obey security precautions without any restriction.
Last edited by wet (2008-06-27 08:21:24)
Offline
Re: Who's afraid of XML-RPC?
wet wrote:
This is how it would look like, yes. I wouldn’t add any other warning or instructions, just a plain on/off radio.
Sounds good:)
I think that this option would keep those who want to use it happy and the rest of us safe:)
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Who's afraid of XML-RPC?
wet wrote:
I wouldn’t add any other warning or instructions, just a plain on/off radio.
The warning could go in the popHelp? If anyone reads those…
I’m not exactly clued up on XML-RPC or what it can do for me (must… read.. docs…) but is the security risk having the directory within your install or the fact that there’s an API/server in TXP that gives the ability for misuse? Or both?
If switching off the radio doesn’t change security, would switching it off and deleting the directory work for those that don’t want the functionality? What about those who just delete the directory without changing the admin pref? Will stuff break? Or is the extra directory the “old way” of using it and now it’s integrated with TXP 4.0.7, there is no dir any more? Sorry if I’m acting a bit of a biffer in this.
Edit: P.S would the current status of XML-RPC be shown in the diagnostics tab (in use, not in use, any other states?)
Last edited by Bloke (2008-06-27 08:34:25)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Who's afraid of XML-RPC?
Bloke wrote:
I’m not exactly clued up on XML-RPC or what it can do for me (must… read.. docs…) but is the security risk having the directory within your install or the fact that there’s an API/server in TXP that gives the ability for misuse? Or both?
Inexistent code is obviously the most secure code ;-) So, yes deleting the /rpc folder terminates any risk from undiscovered bugs in XML-RPC. BTW: Removing all of Textpattern reduces the security risk to absolutely zero, if no other loaded software undermines that measure. It also reduces functionality to zero, but that’s another story.
But seriously: Deleting the /rpc directory won’t break Textpattern. The switch would be intended for those who don’t love to mess around with their FTP, plus it would protect one from inadvertently uploading /rpc again as part of a Txp update.
Technically, XMLRPC will be optional just like it is since 4.0.3 in the sense that it is not required to run Txp. We will change two things with 4.0.7:
- XMLRPC is packaged with the Txp download file.
- XMLRPC is no longer a step-child of development and will receive its fair share of developer love in future versions, so to speak.
Edit: P.S would the current status of XML-RPC be shown in the diagnostics tab (in use, not in use, any other states?)
Maybe. I expect support cases out of this “feature”.
Offline
Re: Who's afraid of XML-RPC?
wet wrote:
Removing all of Textpattern reduces the security risk to absolutely zero
lol
Deleting the
/rpcdirectory won’t break Textpattern. The switch would be intended for those who don’t love to mess around with their FTP, plus it would protect one from inadvertently uploading/rpcagain as part of a Txp update.
Excellent. Then the switch is probably a good move. I like the ability to choose stuff (meh, look at the number of attributes in my plugins for stupid examples of over-the-top switchoffability :-) and if it helps upgrades, all the better
XMLRPC is packaged with the Txp download file.
Good show. So will the switch be in the ‘on’ or ‘off’ state by default, do you think? Or is that what this thread is about…?
I’d vote for “off”, but then I don’t use XML-RPC. Perhaps people that use it would prefer it ‘on’ by default? Or as an option during install? But perhaps that’s getting silly to have an option that governs an option :-p
Last edited by Bloke (2008-06-27 09:17:05)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Who's afraid of XML-RPC?
I vote for the switch on/off in the admin side, with off being the default. Also, a check about rpc folder existance would be nice before presenting the option. If rpc folder is not present, the option should displayed (I think), but greyed down, that is, deactivated. Maybe with a paragraph telling “RPC folder unjustified absent”, or so, in the row below.
This for GUI consistance. But also not displaying the preference at all when the folder is not there would be an option. A check should be made, anyway. Just my opinion.
Offline
Re: Who's afraid of XML-RPC?
Nope. I won’t write code to detect and react on an incomplete installation, besides the already present file consistency check in diagnostics.
Offline
#10 2008-06-27 12:11:37
- masa
- Member
- From: Asturias, Spain
- Registered: 2005-11-25
- Posts: 1,091
Re: Who's afraid of XML-RPC?
colak wrote:
TXP is ahead the competition as far as the security of the cms. That for me is more important than having to add entries from my desktop instead of my browser.
I never understood why one would want to use yet another piece of software to add content, when one could just fire up the browser and do it right in txp with all its niceties available.
So personally I see little use in this feature and would keep it a separate download for those that actually want it.
Offline
Re: Who's afraid of XML-RPC?
Masa – If I’m not mistaken you can now use the xmlrpc protocols with your mobile which is handy for people who may be on holiday and want to do a few updates whilst they are on the move. You can also carry the desktop blogging application on a memory stick which is great if you can access a PC/Mac whilst away from home, maybe at work, which means that it is self-contained and you wouldn’t end up inadvertently leaving passwords on a computer which isn’t yours. Desktop blogging is probably not a good description these days as it has gone past that.
Back to the point though, as I just have no need for it at all I shall probably do what I do now which is to remove the folder. It’s basically a waste of space to me more than anything else.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Who's afraid of XML-RPC?
wet wrote:
Nope. I won’t write code to detect and react on an incomplete installation, besides the already present file consistency check in diagnostics.
Why? Is this considered dirty? Wouldn’t this open to a failure scenario? Like: User forgot she/he once deleted the folder and then turns the option on, and then the system doesn’t work without telling the user why.
It’s more a fail-proof concept, but I see more developers resisting to this sort of things. I’m interested in knowing why, from your pow.
Last edited by Zanza (2008-06-27 13:10:04)
Offline