WordPress.org

Resolved tom coady
(@tomcoady)

1 month, 3 weeks ago

Every time I create a post I’m asked to fetch an authorisation token using this app on an iPad, whereas the same app works perfectly on an iPhone, so I assume the problem related to the iPad application. After deleting and reinstalling the app it seems I can’t connect to the site as I get the following error message:
Couldn’t connect. We received a 403 error when trying to access your site’s XMLRPC endpoint. The app needs that in order to communicate with your site. Please contact your hosting provider to solve this problem.

it should be noted that wordFence is installed, but again this doesn’t explain why I can post from one device and not another. Any wordFence tips would however be much appreciated.

The page I need help with: [log in to see the link]

Viewing 11 replies - 1 through 11 (of 11 total)

Moderator Yui
(@fierevere)

永子

1 month, 3 weeks ago
/xmlrpc.php can be blocked
1. by plugin
2. by .htaccess rule
3. by hosting provider using general http-server configuration

As far as Wordfence is concerned, unchecking the “Disable XML-RPC authentication” checkbox in Wordfence > Login Security > Settings should allow authentication attempts through that file.

Also ensure you don’t see the following in your .htaccess file, which would block access to this file altogether:
```
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
```
Thread Starter tom coady
(@tomcoady)

1 month, 3 weeks ago

I noticed I hadn’t chosen the skip option, and since this screen shot disabled authentication and enabled 2FA.

Thread Starter tom coady
(@tomcoady)

1 month, 3 weeks ago

Thanks @fierevere but as you can see the authentication was already disabled, enabling it makes no difference when installing the app, iPhone app continues to work whereas iPad requests auth every time I create a new post and often gets stuck after gaining permission so I have to kill the app and restart it. Luckily it remembers and draft AND the permission gained so I wonder if it isn’t an iPad specific issue?
Moderator Yui
(@fierevere)

永子

1 month, 3 weeks ago
you can check yoursite/xmlrpc.php (in browser)
Proper response is that only POST requests are accepted

Your site returns 403, so its on the host side.

Also note that some apps may use REST API as alternative/additional method, so its the way your iPhone app seem to be working
- This reply was modified 1 month, 3 weeks ago by Yui.
Thread Starter tom coady
(@tomcoady)

1 month, 3 weeks ago

Finally mystery solved! It was a security setting in plesk, but I was thrown off by the continued working in iphone and intermittent on ipad suggesting xmlrpc isn’t always necessary? In any case it would be great if this call could be made without fear, but I’m sure that has been discussed many time already! I see you have commented on that too, so it would be great to know if there are plans to update the app to use REST instead!

FYI: https://support.plesk.com/hc/en-us/articles/16162742129175-WordPress-website-displays-error-403-intermittently-access-forbidden-by-rule-request-POST-xmlrpc-php-on-Plesk-server

Alin (a11n)
(@alinclamba)

1 month, 3 weeks ago

Hi @tomcoady ,
Alin here, from the team that helps maintain and support the WordPress mobile app.

I took a look and from what I can see now, XML-RPC is accessible and responding correctly.

You can verify this yourself here:
https://coadycode.co.uk/xmlrpc.php?for=jetpack

You should see the message:
“XML-RPC server accepts POST requests only”, which means the endpoint is working as expected.

I also checked the Jetpack side and the Jetpack connection looks healthy now. You can confirm that here as well:
https://jptools.wordpress.com/debug/?url=http://coadycode.co.uk/

At this point, everything looks good from our side.
If you still notice any odd behavior on the iPad app specifically, feel free to let us know and we’re happy to take another look.

Alin (a11n)
(@alinclamba)

1 month, 3 weeks ago

Oh, I started writing my reply while you were posting your update, and only noticed your message after publishing.

That’s great to hear, and nice catch with the Plesk security rule, that explains the intermittent 403s perfectly. Your observation about the iPhone vs iPad behavior is also spot on. The app doesn’t rely on XML-RPC all the time, some ctions already use the REST API, which is why things can appear to work on one device and not another when XML-RPC is being filtered.

XML-RPC is still used for some flows though, so having POST requests to xmlrpc.php blocked or rate-limited can still cause exactly the symptoms you ran into.

Thanks for sharing the Plesk article here, that context will definitely help others. For now, allowing XML-RPC POST requests is still the safest setup for the mobile apps. If you notice anything else odd going forward, just let us know and we’re happy to take another look.

Thread Starter tom coady
(@tomcoady)

1 month, 2 weeks ago

OK thanks for your detailed analysis which is useful as I have started to see errors again after restarting the app using REST and the errors persist albeit much more intermittently.

My understanding is that enabling XML-RPC is a security risk because it’s an outdated protocol with vulnerabilities that are exploited for brute force attacks, DDoS amplification, and server compromise, and it should be disabled in favour of alternatives like the REST API, so I look forward to the time when the app doesn’t need the legacy protocol.

Alin (a11n)
(@alinclamba)

1 month, 2 weeks ago

Hi @tomcoady,

Thanks for the follow-up, and I completely understand the concern around XML-RPC from a security perspective.

Just to ground things in the present state first, from what I can see right now your site’s Jetpack connection looks healthy and xmlrpc.php is accessible and responding as expected. So at the moment, nothing appears broken or misconfigured on the Jetpack side.

Where the confusion comes in is that the mobile apps are in a transition phase. They already use the REST API for a growing number of actions, which is why things can appear to work even if XML-RPC is partially restricted. However, some flows, including parts of authentication and publishing, still rely on XML-RPC as a fallback. If POST requests to xmlrpc.php are blocked or intermittently filtered by the server, that can lead to exactly the kind of sporadic errors you’re seeing, sometimes differing between devices.

You’re also right that XML-RPC is considered legacy in the broader ecosystem. In Jetpack’s case, though, it’s implemented differently than the classic setup that’s often targeted. Jetpack does not send a username or password, it uses a token-based signature similar in spirit to OAuth. That’s one of the reasons it’s still supported today, mainly for stability and compatibility while the REST-based flows continue to mature.

There is ongoing work to move more functionality fully onto REST, but there isn’t a public timeline yet for completely removing the XML-RPC dependency in the mobile apps. For now, the most stable setup is to allow XML-RPC POST requests while keeping your other security protections in place.

If XML-RPC ends up being restricted again in the future, that would very likely explain a return of the intermittent app issues. And if you do notice anything new while everything is enabled, feel free to let us know and we can take another look.

If you’d like some extra background on how Jetpack uses XML-RPC specifically, this doc goes into more detail:
https://jetpack.com/support/jetpack-and-xml-rpc/

Thanks again for the thoughtful questions and for sticking with the investigation here.

Thread Starter tom coady
(@tomcoady)

1 month, 1 week ago

Thank you for the detailed explanation and for confirming that my site’s Jetpack connection is currently functioning as usual. I really appreciate the clarity on how the mobile apps are transitioning to the REST API while still relying on XML-RPC for certain critical functions, such as authentication and publishing as this explains some of my unexpected experiences!

Your point about XML-RPC being implemented differently in Jetpack—using token-based signatures rather than traditional username/password authentication—helps contextualize its continued support. I understand that, for now, allowing XML-RPC POST requests is key to ensuring stability while the REST-based flows mature.

I’ll keep an eye on the setup and monitor for any intermittent issues. Should anything arise, I’ll be sure to reach out. Thanks also for sharing the documentation link—I’ll review it to better understand Jetpack’s specific use of XML-RPC.

I appreciate your thorough support and the ongoing work to improve the platform. Looking forward to the continued evolution of the REST API integration.

fujifika (a11n)
(@fujifika)

1 month, 1 week ago

Hi @tomcoady ,

Thanks so much for the thoughtful follow-up, and I’m really glad my colleagues explanation helped clarify what you were seeing. It sounds like you’ve got a solid handle on how things fit together now.

We appreciate you taking the time to dig into this and share your experience, and of course, if anything changes or new questions come up down the line, feel free to start a new thread.

All the best, and thank for being part of the community!