TamCore

Hi,

how can this be a configuration problem on my side, if requests on xmlrpc.php?for=jetpack are the only affected ones?

Requests to the normal xmlrpc.php return a 200 and the correct content. Requests to xmlrpc.php?for=jetpack return a 403 but the correct content. If this would be a configuration problem, my webserver would deliver an access denied page.

Also there is no module like mod_security loaded, there is nothing in my configs that would affect explicitly “xmlrpc.php?for=jetpack” and my .htaccess is only used for WordPress’s internal rewrites and serving cached content.

Even taking the correct content and replacing the whole xmlrpc.php with it doesn’t change anything except for the fact, that the 403 is now a 200 code.

BR
Philipp

The 403 can’t be a configuration issue because there is nothing left that could cause any issues. Despite the fact that requesting xmlrpc.php?for=jetpack returns a 403 code, it still delivers the correct contents. (I’m sure you see that from your side.)

Nope, still the same error.

SSL is only forced for wp-admin (via FORCE_SSL_ADMIN). Even when I access wp-admin via http and try to connect Google+ I get the -32301.

I’ve already tested the mod_security theory a few weeks ago. Currently there’s nothing loaded that could deny access to the xmlrpc.php.

When I verify the xmlrpc.php accessibility everything looks fine

curl -i -H ‘Content-Type: text/xml’ –data ‘<?xml version=”1.0&”?><methodCall><methodName>demo.sayHello</methodName><params></params></methodCall>’ https://tamcore.eu/xmlrpc.php
HTTP/1.1 200 OK
Date: Tue, 18 Feb 2014 17:04:03 GMT
Server: Apache/2.2.22 (Debian)
Connection: close
Content-Length: 181
Vary: Accept-Encoding
Content-Type: text/xml; charset=UTF-8
[….]

But when I try to reach /xmlrpc.php?for=jetpack, I get a 403. I have no idea why.

DNS is fixed. Still getting -32301.

The plugin is working fine on my webserver.

Sorry for the late reply.

@andreas Voetz: You can ignore this warning. CURLOPT_FOLLOWLOCATION isn’t needed and I’ve removed it from the code I’ve linked in the OP.

@captainstu72: Not all webservers allow opening files on remote servers via file_get_contents(); fopen(); etc. This change tries to fetch the information via PHP’s cURL plugin, which isn’t affected by the described limitations.

I think allow_url_fopen is deactivated in php’s config and apache isn’t allowed to overwrite this setting. I’ve rewritten the sav_get_file() function to use cURL instead of file_get_contents().

Source is available on github

Maybe it’ll help you ??