Publishing to WordPress using MarsEdit

Website, Application, Performance Security
, ,
1

Hello, everyone.

I am using a third party app called MarsEdit to publish to my WordPress. My WP is hosted on a DigitalOcean droplet. My domain and DNS is handled by Cloudflare. MarsEdit uses XMLRPC to publish directly to my blog. But I keep getting an XMLRPC error. Specifically, “Invalid XML response.” I’ve contacted MarsEdit’s support and sent a copy of my network log to troubleshoot. They said Cloudflare is causing my site to redirect the API URL that MarsEdit needs to access. That URL is an XMLRPC and Cloudflare seemingly redirects it to my homepage instead of the API URL needed.

it seems like something in Cloudflare may be blocking it. How can I ensure that XML site doesn’t get redirected and/or blocked? I’ve checked the Cloudflare Firewall and have not seen an event.

Reference WordPress Configuration - Red Sweater Help

I’ve looked at Activating XMLRPC and don’t have MarsEdit’s IP or FQDN. I’m not sure that’s relevant?

Thanks for your help. I apologize if any of the above is unclear or misuses technical terms.

2

It sounds like you’ve been pretty thorough. It should be pretty straightforward for hitting xmlrpc.php, so a redirect is strange.

As I mentioned in that thread you linked to, checking server logs might help.

Do you have any Page Rules set up here?

Can you post the output of: curl -I https://example.com/xmlrpc.php so we can see the redirect?

2 Likes
3

Hello, sdayman. Good to hear from you, being that you were really helpful in the previous thread.

I’ve checked the server log and that’s what I sent to the MarsEdit support team, who directed me to Cloudflare. They’re not sure but they’re inclined to believe the issue is with a Cloudflare redirect.

I have one Page Rule set up which I made in an attempt to rectify this problem. Otherwise, prior to that repair attempt, I had no page rules in place. The Rule is directing the XMLPRC url to Browser Integrity Check: Off, Always Online: Off, Security Level: Low, Cache Level: Bypass.

Here’s the redirect:
HTTP/2 301

date: Sun, 21 Apr 2019 15:15:09 GMT

content-type: text/html; charset=iso-8859-1

set-cookie: __cfduid=d3417a475f3b15efeac8b381cd737343b1555859708; expires=Mon, 20-Apr-20 15:15:08 GMT; path=/; domain=.example.com; HttpOnly; Secure

location: https://example.com/

expect-ct: max-age=604800, report-uri=“https://report-uri.Cloudflare.com/cdn-cgi/beacon/expect-ct”

server: Cloudflare

cf-ray: 4cb04fcd0913cf6a-IAD

4

Cloudflare probably isn’t the source of the redirect. With your one subtractive Page Rule that’s removing barriers, that’s not the problem.

Here’s another Curl command to hit your server directly to test that URL:
curl --silent --verbose https://example.com/xmlrpc.php --resolve example.com:443:123.123.123.123

Change both example.coms, and the IP address to your Droplet’s IP address.

1 Like
5

curl --silent --verbose https://example.com/xmlrpc.php --resolve example.com:443:123.123.123.123

  • Added example.com:443:123.123.123.123 to DNS cache

  • Hostname example.com was found in DNS cache

  • Trying 123.123.123.123…

  • TCP_NODELAY set

  • Connected to example.com (123.123.123.123) port 443 (#0)

  • ALPN, offering h2

  • ALPN, offering http/1.1

  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

  • successfully set certificate verify locations:

  • CAfile: /etc/ssl/cert.pem

CApath: none

  • TLSv1.2 (OUT), TLS handshake, Client hello (1):

  • TLSv1.2 (IN), TLS handshake, Server hello (2):

  • TLSv1.2 (IN), TLS handshake, Certificate (11):

  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):

  • TLSv1.2 (IN), TLS handshake, Server finished (14):

  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):

  • TLSv1.2 (OUT), TLS handshake, Finished (20):

  • TLSv1.2 (IN), TLS change cipher, Client hello (1):

  • TLSv1.2 (IN), TLS handshake, Finished (20):

  • SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305

  • ALPN, server accepted to use http/1.1

  • Server certificate:

  • subject: CN=example.com

  • start date: Apr 13 22:43:42 2019 GMT

  • expire date: Jul 12 22:43:42 2019 GMT

  • subjectAltName: host “example.com” matched cert’s “example.com”

  • issuer: C=US; O=Let’s Encrypt; CN=Let’s Encrypt Authority X3

  • SSL certificate verify ok.

> GET /xmlrpc.php HTTP/1.1

> Host: example.com

> User-Agent: curl/7.54.0

> Accept: /

>

< HTTP/1.1 301 Moved Permanently

< Date: Sun, 21 Apr 2019 15:33:07 GMT

< Server: Apache/2.4.29 (Ubuntu)

< Location: https://example.com/

< Content-Length: 312

< Content-Type: text/html; charset=iso-8859-1

<

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>301 Moved Permanently</title>

</head><body>

<h1>Moved Permanently</h1>

<p>The document has moved <a href=“https://example.com/”>here</a>.</p>

<hr>

<address>Apache/2.4.29 (Ubuntu) Server at example.com Port 443</address>

</body></html>

6

That shows you hit your Apache server directly and it redirected it with a 301 to the home page.

Now you just need to track down why, whether it’s in .htaccess, or something in an Apache conf file. There’s also the chance a WordPress plugin is doing it.

2 Likes
7

Thanks. I’ve done a little digging so far and can’t quite figure it out. I do not have any plugins enabled. However, there is a Must-Use plug-in of fail2ban. I wonder if this XML issue is related to the fail2ban plugin?

I will keep digging. Thanks so much for your help so far. I will be sure to post my findings or continued issue for future users stumbling upon this post.

1 Like
8

Well, I figured it out. I destroyed my droplet and made a fresh install of the One Click WordPress install. Still the same problem so I knew it had to be something with the One Click.

Turns out Digital Ocean disables xmlrpc by default: WordPress | DigitalOcean Marketplace 1-Click App
“* Disables XML-RPC to help prevent DDoS and other brute force attacks.”

I looked up how to reenable it and it seems like someone else had the issue previously: Wordpress on 16.04 One-Click connectivity issue | DigitalOcean

I hope this answer helps someone in the future. Thanks, sdayman, for all your help.

3 Likes
9

This topic was automatically closed after 30 days. New replies are no longer allowed.