Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Who's afraid of XML-RPC?
thebombsite wrote:
But by way of reversing that aren’t we going to be shipping xmlrpc by default with 4.0.7? How come we feel safe enough to do that and they don’t?
I was wondering the same thing, how safe is the XML-RPC service inside of Textpattern?
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Who's afraid of XML-RPC?
Is this a correct understanding?
- security risk = known issue that can be exploited?
- reduced attack surface = any code that someone could try to exploit with or without success at some unknown time in the future?
- XML-RPC for Textpattern is secure or it wouldn’t be included.
Would the preference button enable or disable XML-RPC by changing folder permissions?
Having read past threads, XML-RPC seems to be a feature that mature CMSes are “supposed to have”. I think it helps perception as well as usability for some people. I think it was the right decision to bring it in-house as an official development and to ship it with the default install. It’s easy enough to delete for those who don’t have a use for it, and don’t want it taking up space.
I suppose one could set it up as an option during the install, then its either installed or not – no preference needed . . . .
Mike
Offline
Re: Who's afraid of XML-RPC?
btw the xmlrpc package also provided the TXP wrapper class which is a great way to interface with TXP from outside scripts, tools, etc. the RPC package is one client that accesses it, but it can be used for a bunch of other things.
Shoving is the answer – pusher robot
Offline
Re: Who's afraid of XML-RPC?
This actually came up in another thread about a week ago Bert.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Who's afraid of XML-RPC?
When I was using Nucleus CMS, we had an XML-RPC security issue, but we were using the XML-RPC for PHP library.
In Textpattern’s case, the XML-RPC interface was written by Pedro Palazon and then Wet took it over. That’s why I was asking about the security of it, but Wet has answered that in the thread you link to. I can now leave the rpc directory around every time I synch with SVN, no need to worry about script kiddies who can’t afford a blog but want their voices heard.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Who's afraid of XML-RPC?
+1 on having a preference that defaults to off (no diagnostics, no “has user removed part of TXP” detection) that makes the xml-rpc interface respond with a HTTP 503 error at a very early stage during execution.
Personally, I don’t expect to actually use XML-RPC myself (apart from testing/debugging).
Offline
Re: Who's afraid of XML-RPC?
personally i dont even see the point of xml-rpc for textpattern seeing as i’m assuming you cant use metaWeblog.newMediaObject (so no file uploading/attachment to articles, no article images, etc), no way to input custom fields which all of my txp sites have to some extent, etc etc. unless these changes were made in the past while?
Offline
Re: Who's afraid of XML-RPC?
Just thinking about how TXP copes with this, I don’t think it needs to do anything whether in Prefs or anywhere else. For those of us that use SVN we will probably be aware that the rpc folder can be deleted without any effect on TXP. If you sync directly from your host server you will end up with the folder being re-installed on each update but you can then delete it. If like me you sync from your PC/Mac you simply wouldn’t bother uploading the folder or any modified files within it.
The main sector we are looking at here I think is new installs. If that is the case then I think some blurb could be added to the install instructions suggesting that if the user has no use for xmlrpc then they needn’t bother uploading the folder in the first place. I think that is all that really needs doing. No messing with TXP for checks or Prefs or anything.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Who's afraid of XML-RPC?
ruud wrote:
+1 on having a preference that defaults to off (no diagnostics, no “has user removed part of TXP” detection)
Ok, the “no” is definitely clear. ;)
What is not so clear (and I’m interested on) is the “why”. “Unnecessary” is not an answer: nothing is really necessary apart a post-and-publish function…
Why do you think this isn’t a worthy option for user interfaces? Not to be argumentative: I’m professionally interested in dev’s opinion about that. Even privately, if this is not the appropriate place. Anyway, I won’t go further with that.
Thanks.
Offline
Re: Who's afraid of XML-RPC?
ruud wrote:
… that makes the xml-rpc interface respond with a HTTP 503 error at a very early stage during execution.
This requires an in-depth consideration: On layer 4, IXR_IntrospectionServer generally replies with HTTP status ‘200’. Error conditions are signalled to the client on layer 7 as a XML response packet.
I think we should not deviate too much from the expected behaviour and just disable the accepted method signatures, but not the service itself. This gives more clue to clients to present users with a friendly error message. Specifying a correct XML endpoint is a challenge for end-users in itself, so any high-level clues we provide will reduce support load for both us and the desktop client vendors.
I am very hesitant to cripple the interface too much, as verbosity in error reporting is a benefit from my POV with all the different third-party clients involved (given that if we do not expect to fail substantially with the package as a whole).
Offline