I finally made it work, so I wanted to share some things to check.
In my case it was possible to login via the (android) WP mobile app, but it neither showed already published articles nor was it able to publish anything. There is no jetpack plugin installed, though, but I am optimistic that if one works, the other will as well. And this did not work out of the box, due to the following reason.
One thing to keep in mind is the WAF / mod_security. In my setup Comodo ruleset is active, which probably is hard to debug when you don't have shell access, because the corresponding log file can only be found in /var/log/modsec_audit.log, and I don't think there's any chance to access these information when you only have user permission or only access to the web management panel. 403 was what I was experiencing in the logs, too, so you could check whether there's a shortcut to WAF settings in the domain's dashboard. Or has access to that xmlrpc.php file worked out of the box in your case?
What was odd is that only one specific rule was triggered according to the modsec log, namely the one that prevents access to xmlrpc.php:
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at IP. [file "/etc/apache2/modsecurity.d/rules/comodo_free/30_Apps_OtherApps.conf"] [line "5956"] [id "240335"] [rev "5"] [msg "COMODO WAF: XML-RPC Attack Identified (CVE-2013-0235)|Source xxx.xxx.xxx.xxx (0+1 hits since last alert)|example.de|F|2"] [severity "CRITICAL"] [tag "CWAF"] [tag "OtherApps"] [hostname "example.de"] [uri "/xmlrpc.php"] [unique_id "ZPm7BeNQVN@W2NXX5XfsvAAAAQA"]
Disabling this rule id (240335) led to the strange situation that for another user / wordpress instance publishing sometimes worked, but at other times not. This was months ago, and at that point I only started to have a look at this problem, plus another network than usual was used - so I can't say for sure whether this specific experience was due to mod_sec, network or firewall settings. What I do recall is that neither the webserver's access nor error log had entries with the ip address that was used, so it might be something totally else too. Disabling this rule alone just didn't seem to do the trick, because in another case - as well as in my test setup - neither pulling nor pushing was possible.
Nevertheless no other rule id was referenced in the mod_sec log.
Important: when you disable any WAF rules related to xmlrpc.php, you should limit access to this file by other means, e.g. via webserver settings, I did it this way through the additional apache settings:
<Files 'xmlrpc.php'>
require ip <ip_address or network>
</Files>
This alone did only help in regard to logging in / connecting the app to the CMS. Still neither pulling nor pushing drafts worked in my specific test setup, while another user experienced that it worked only sometimes. So I digged even deeper, and had a look at the modsec rules itself. There seems to be a counter how often xmlrpc.php is requested, but since it's part of the same chain as the above rule 240335, it does not have a message to log - my guess is that the other related rules were still triggered nevertheless. But I'm no mod_security expert by any means, I know how to set it up, but I haven't messed with the rules' syntax or inner workings.
Hence in the end I disabled the following rule ids via domain's WAF settings (not globally, of course):
240331
240332
240333
240334
240335
240336
And finally it worked like a charm! I set up a fresh WP install for my debugging, so there were no security plugins or any other plugins installed - this might be worth checking too, as preventing access to this file might be caused by security plugins as well.
Plus you need to be careful when limiting access via ip address, because I have managed to get myself "Fail2Ban"-ned at one point, too, which obviously also lead to 403 response codes in the error log, so without further insight might seem as one and the same source of the problem, while in reality it's not.
I also got the feedback that with these modifications iOS Wordpress App was able to publish to their productive instance now, too, so I really think it's not due to the app itself, but some server settings preventing it to connect correctly / permanently. There too was no jetpack or security plugins installed.
I really hope this helps someone, because it really took long to solve this issue.
Facebook
Twitter
