Mike Carter

Thanks for looking into it. Yes, I already tried reviewing Security Events in Cloudflare for xmlrpc.php, but couldn’t find any. I did quite a bit of debugging prior to contacting support.

Yes, it’s possible one of the Cloudflare security challenges could be causing an issue, but the error response does appear (I’ve actually tested this) to originate from my own web server, not from the edge network/firewall, and it’s a 405 response, not a 403. Is it possible that WordPress.com/Jetpack is sending a bad request, and that I may need to reconnect to the Jetpack service again?

Also, do you know if this alternate_xmlrpc() method is compatible with WordPress?

Here is the original post, so it’s easier for you to investigate the code and see exactly which line in IXR_Server is triggering the error response:

I narrowed it down to the version of Jetpack 9.1.2 that is included with Woo Tax. In my case, xmlrpc.php is not being blocked and Automattic’s APN and IP’s are both whitelisted. The trouble seems to be that WordPress.com is making a GET request to my server that triggers a method called alternate_xmlrpc(). I have narrowed it down to these lines in Jetpack’s class-manager.php (lines 263:278):

// Alternate XML-RPC, via ?for=jetpack&jetpack=comms.
		// phpcs:ignore WordPress.Security.NonceVerification.Recommended -- This just determines whether to handle the request as an XML-RPC request. The actual XML-RPC endpoints do the appropriate nonce checking where applicable. Plus we make sure to clear all cookies via require_jetpack_authentication called later in method.
		if ( isset( $_GET['jetpack'] ) && 'comms' === $_GET['jetpack'] ) {
			if ( ! Constants::is_defined( 'XMLRPC_REQUEST' ) ) {
				// Use the real constant he// Alternate XML-RPC, via ?for=jetpack&jetpack=comms.re for WordPress' sake.
				define( 'XMLRPC_REQUEST', true );
			}

			add_action( 'template_redirect', array( $this, 'alternate_xmlrpc' ) );

			add_filter( 'xmlrpc_methods', array( $this, 'remove_non_jetpack_xmlrpc_methods' ), 1000 );
		}

		if ( ! Constants::get_constant( 'XMLRPC_REQUEST' ) ) {
			return false;
		}

The resulting handler in the WordPress IXR library rejects the request with a 405 response, because it is expecting a POST instead. It sounds like this code was added as a workaround for servers who block xmlrpc.php, but it doesn’t appear to be functioning correctly. Woo Tax is working fine, and it is able to access the API for receiving tax data without problems. The warning seems to be a false alert. Here are the lines in IXR_Server that trigger the error (lines 39:59):

function serve($data = false)
    {
        if (!$data) {
            if (isset($_SERVER['REQUEST_METHOD']) && $_SERVER['REQUEST_METHOD'] !== 'POST') {
                if ( function_exists( 'status_header' ) ) {
                    status_header( 405 ); // WP #20986
                    header( 'Allow: POST' );
                }
                header('Content-Type: text/plain'); // merged from WP #9093
                die('XML-RPC server accepts POST requests only.');
            }

            $data = file_get_contents('php://input');
        }
        $this->message = new IXR_Message($data);
        if (!$this->message->parse()) {
            $this->error(-32700, 'parse error. not well formed');
        }
        if ($this->message->messageType != 'methodCall') {
            $this->error(-32600, 'server error. invalid xml-rpc. not conforming to spec. Request must be a methodCall');
        }
        $result = $this->call($this->message->methodName, $this->message->params);

Expand

I’m testing with WordPress 7.1.1 and Woo Tax 3.6.16

Have your engineers tested Woo Tax with WordPress 7.1.x and does the request GET request from WordPress.com ?for=jetpack&jetpack=comms actually return a successful 200 response?

Here is the status report:

https://pastebin.com/zujddfLQ

Connection Error Warning (Displayed in Site Health):

A healthy Jetpack Connection allows connected plugins (such as Jetpack and WooCommerce) to provide features like Stats, Site Security, and Payments.

Error WordPress.com reached your site but the request was blocked (HTTP 405). This is usually caused by a firewall, security plugin, or server rule rejecting requests from WordPress.com.

Ask your host or security provider to allow requests from WordPress.com to your site’s xmlrpc.php file. Reconnecting will not resolve this. If you need further help, contact Jetpack support.

Please contact Jetpack support. (opens in a new tab)

Hi Pear,

Sorry for the delay. I had to wait for the off hours to be able to test on the live site. Here are the results for the customer review form:

WordPress 7.1.2 – image upload works okay, but form submit to admin-ajax.php returns a 403 response
WordPress 7.1 – image upload and form submit both work

Is there a way to share an image without a url? I don’t see an option to upload an image directly here.

It looks like I will have to uninstall the plugin since it’s not compatible with the current version of WordPress. I like to keep WordPress updated, and most of my plugins are auto-updated.

It seems like this topic should not have been marked as resolved yet.

Thanks,

Mike

• This reply was modified 1 week, 5 days ago by Mike Carter.
• This reply was modified 1 week, 5 days ago by Mike Carter.

No, I meant I clicked on the link in the review reminder email, but because I had previously left a review, it shows an edit button instead.

I will send out a new email reminder and test it again this evening.

In my case, I’m unable to deregister that script, because apparently woocommerce is using wp-i18n for a block that involves stripe payments.

Funny that CF7 seems to have a call to load that script as well.

Hi Takayuki,

Thanks! Yes, that might be useful.

I’m specifically curious about this change to index.asset.php

https://plugins.trac.wordpress.org/changeset?old_path=%2Fcontact-form-7&old=3103416&new_path=%2Fcontact-form-7&new=3130500&sfp_email=&sfph_mail=

Do you know why the dependency for wp-i18n was added? I’m not using any sort of internationalization in my contact forms and would prefer not to load that script on pages that use a contact form.

Mike