Programming competitions. Introduction to XML-RPC Why do I need an xmlrpc php file

Introduction to XML-RPC

There are many different resources on the Web that provide users with certain information. This does not mean ordinary static pages, but, for example, data retrieved from a database or archives. This can be an archive of financial data (currency rates, data on securities quotes), weather data, or more voluminous information - news, articles, messages from forums. Such information can be presented to the page visitor, for example, via a form, as a response to a request, or it can be dynamically generated each time. But the difficulty is that often such information is needed not so much by the end user - a person, but by other systems, programs that will use this data for their calculations or other needs.

A real-life example: a page on a banking site that displays currency quotes. If you visit the page as a normal user, through a browser, you see all the page design, banners, menus and other information that "frames" the true purpose of the search - currency quotes. If you need to enter these quotes into your online store, then there is nothing else left but to manually select the necessary data and transfer it to your website via the clipboard. And you have to do this every day. Is there really no way out?

If we solve the problem head-on, then the solution immediately suggests itself: the program (script on the site) that needs data receives the page from the server as a "regular user", parses (parses) the received html code and extracts the necessary information from it. This can be done either with a regular regular expression, or with the help of any html parser. The complexity of the approach lies in its inefficiency. First, to get a small portion of data (data about currencies is literally a dozen or two characters), you need to get the entire page, which is at least several tens of kilobytes. Secondly, with any change in the page code, for example, the design has changed or something else, our parsing algorithm will have to be redone. Yes, and it will select resources decently.

Therefore, the developers came to the decision - it is necessary to develop some kind of universal mechanism that would allow transparent (at the protocol and transmission medium level) and easy data exchange between programs that can be located anywhere, be written in any language and run under any operating system. systems and on any hardware platform. Such a mechanism is now called the high-profile terms "Web services" (web-service), "SOAP", "service-oriented architecture" (service-oriented architecture). For data exchange, open and time-tested standards are used - the HTTP protocol is used to transfer messages (although other protocols can be used - SMTP for example). The data itself (in our example - exchange rates) is transmitted packed in a cross-platform format - in the form of XML documents. For this, a special standard was invented - SOAP.

Yes, now web services, SOAP and XML are on everyone's lips, they are beginning to be actively implemented and large corporations like IBM and Microsoft are releasing new products designed to help the total adoption of web services.

But! For our example with exchange rates that must be transferred from the bank's website to the online store engine, such a solution will be very difficult. After all, only the description of the SOAP standard takes indecent one and a half thousand pages, and that's not all. For practical use, you will also have to learn how to work with third-party libraries and extensions (only starting from PHP 5.0 it includes a library for working with SOAP), write hundreds and thousands of lines of your code. And all this to get a few letters and numbers is obviously very heavy and irrational.

Therefore, there is one more, with a stretch, we can say an alternative standard for information exchange - XML-RPC. It was developed with the participation of Microsoft by UserLand Software Inc and is designed for unified data transfer between applications over the Internet. It can replace SOAP when building simple services where all the "enterprise" features of real web services are not needed.

What does the abbreviation XML-RPC stand for? RPC stands for Remote Procedure Call - remote procedure call. This means that an application (whether a script on the server or a normal application on the client computer) can transparently use a method that is physically implemented and executed on another computer. XML is used here to provide a universal format for describing the transmitted data. As a transport, the HTTP protocol is used to transfer messages, which allows you to freely exchange data through any network devices - routers, firewalls, proxy servers.

And so, to use it, you need to have: an XML-RPC server that provides one or more methods, an XML-RPC client that can form a correct request and process the server response, and also know the server parameters necessary for successful operation - address, method name and passed parameters.

All work with XML-RPC takes place in the "request-response" mode, this is one of the differences between the technology and the SOAP standard, where there are both the concepts of transactions and the ability to make deferred calls (when the server saves the request and responds to it at a certain time in future). These additional features are more useful for powerful enterprise services, they greatly complicate the development and support of servers, and put additional requirements on the developers of client solutions.

The procedure for working with XML-RPC begins with the formation of a request. A typical request looks like this:

POST/RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Host: server.localnet.com
Content-Type: text/xml
content length: 172

TestMethod
Hello XML-RPC!

The first lines form the standard HTTP POST request header. Required parameters include host, data type (MIME type), which must be text/xml, and the length of the message. The standard also states that the User-Agent field must be filled in, but may contain an arbitrary value.

Next comes the normal header of the XML document. Root element of the request - , there can be only one, and cannot contain such nodes as children. This means that only one method on the server can be called per request.

Line TestMethod indicates that we are calling a method named TestMetod. If necessary, here you can specify the name of the program or module containing the method, as well as the path to it. Although the XML-RPC specification imposes some restrictions on the set of characters that can be used to designate a method, how to interpret them depends entirely on the implementation of the server.

Next, the passed parameters are set. For this, the section Which can contain an arbitrary number of subelements Which contain the parameter described by the tag . We will look at parameters and data types a little further. In our version, the method is passed one string parameter, enclosed in the tag .

After describing all the parameters, closing tags follow. Request and response in XML-RPC are normal XML documents, so all tags must be closed. But there are no single tags in XML-RPC, although they are present in the XML standard.

Now let's analyze the server response. The HTTP response header is normal, if the request is successfully processed, the server returns an HTTP/1.1 200 OK response. Just like in the request, you should correctly specify the MIME type, message length, and the date the response was generated.

The body of the response is the following:

true

Now instead of the root tag tag is indicated , which immediately contains the results of processing the request. Unfortunately, the method name is not passed in the response, so you should store it on the client side to avoid confusion if different methods are called at the same time.

If an error occurred while processing your request, instead of The response will have an element , in which the structure describing the error will be nested. The error description contains a numeric error code and a textual description of the error.

Now let's take a quick look at the data types in XML-RPC. There are 9 data types in total - seven simple types and 2 complex ones. Each type is described by its own tag or set of tags (for complex types).

Simple types:

Whole numbers- tag or ;

boolean type- tag , can take both values ​​0/1 and true/false;

ASCII string- described by tag and may contain an arbitrary string of characters;

Floating point numbers- tag , may also contain a number sign, the fractional part is separated by a dot;

date and time- described by tag and must conform to the iso8601 format. For further processing in scripts, this format is a little inconvenient, so it is always converted when sending / receiving a request. This can be done by a special function in the library, or if there is none, the developer must convert the date manually.

The last simple type is base64 encoded string, which is described by the tag . This type is universal, it can be used to transfer any data between the client and the server, although the amount of data transferred due to this encoding increases. But this is a consequence of the textual nature of the protocol and the XML format in particular.

Complex types are represented by structures and arrays. Structure defined by root element , which can contain an arbitrary number of elements , defining each member of the structure. A structure member is described by two tags: the first, , describes the member name, second, , contains the value of the member (along with a tag that describes the data type).

Arrays have no names and are described by a tag , which contains one element , and one or more child elements , where specific data is specified. An array can contain any other types in any order, as well as other arrays, which allows you to describe multidimensional arrays. You can also describe an array of structures. But the fact that an array has no name complicates its use in some cases; in order to transfer complex data, they have to be repeatedly packed into other types (for example, to transfer several arrays, you can separately pack each array into a structure, and then create one array from these structures).

Of course, someone will say that such a list of data types is very poor and "does not allow you to expand." Yes, if you need to transfer complex objects, or large amounts of data, then it is better to use SOAP. And for small, undemanding applications, XML-RPC is quite suitable, moreover, very often even its capabilities turn out to be too much! When you consider the ease of deployment, the very large number of libraries for almost any language and platform, and the wide support in PHP, then XML-RPC often simply has no competitors. Although it is impossible to immediately advise it as a universal solution - in each case it is necessary to decide according to the circumstances.

His post also shows how to do browser authentication, as below:
$request = xmlrpc_encode_request("methodName" , array("methodParam" ));
$auth = base64_encode($username . ":" . $password );
$header = (version_compare(phpversion(), "5.2.8"))
? array("Content-Type: text/xml" , "Authorization: Basic $auth " )
: "Content-Type: text/xml\r\nAuthorization: Basic$auth" ; //
$context = stream_context_create (array("http" => array(
"method" => "POST" ,
"header" => $header ,
"content" => $request
)));
$webservice = "http://www.example.com/rpc";
$file = file_get_contents ($webservice , false , $context );
$response = xmlrpc_decode($file );
if (xmlrpc_is_fault ($response )) (
return "xmlrpc: $response [ faultString ] ($response [ faultCode ] )" ;
) else (
return $response ;
}
?>
1 - EDITOR NOTE: THIS IS A FIX FROM "SandersWang dt php at gmail dot com"

16 years ago

Binary strings (set with xmlrpc_set_type) go into a ...block like you"d expect. But after every 80th character, this function inserts the XML entity " ", which is a Unicode newline, as if to cause a line-wrap, which is admittedly silly.

Silly though it may be, it causes real problems for some XML-RPC servers, such as http://jakarta.apache.org/xmlrpc/ (nee Helma). Stripping out those entities with something like

$req = preg_replace("/ /", "", xmlrpc_encode_request("my.method", $args));

works around the problem.

11 years ago

It should be noted that encoding does not seem to encode anything, just specify what goes into the XML header.

We had problems with double-encoded UTF strings being saved to database when using this function, sending it of to a apache xml-rpc servlet and storing it in mysql database. It was solved by setting "escaping" to just "markup" and "encoding" to "UTF-8" (don"t forget to set "utf-8" in xmlrpc_decode too).

It seems that UTF-8 encoded strings gets escaped with their bytes as entities instead of their characters as entites.

9 years ago

Ever tried transmitting an array like the following with xmlrpc?
$var1=array(7=>14,9=>18);

The output array looks quite different! It will look like that:
$var2=array(14,18);

The only solution i found is to prepend a space to the index:
$var3=array(" 7"=>14," 9"=>18);

Using that method you"ll get the right result. ($var1)

16 years ago

This function should be used by an XML-RPC client to create an XML payload for an XML-RPC request;

$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$request = xmlrpc_encode_request($method , $params );
echo($request);
?>

Produces;

system.methodHelp

system.methodSignature

The second argument recognizes the type of variable and generates the correct XML-RPC structure. See xmlrpc_encode() for more details.

12 years ago

Simple OO client with function Overload:

the php metho test_helloworld is translated to xmlrpc method test.helloworld.

class RpcClient(

Private $_methods;
private $_context;
private $_url;

Function __construct ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(array(
"http" => array(
"method" => "POST",
"header" => "Content-Type: text/xml\r\n".
"Authorization: Basic $auth" ,

)
));
$this->_url = $url;

$this->registerMethod("Test_HelloWorld");

Function __call($methodName, $params) (
if (array_key_exists($methodName,$this->_methods)) (
// on appelle la fonction RPC
$m = str_replace("_", ".", $methodName);
$r = xmlrpc_encode_request($m, $params,array("verbosity"=>"newlines_only"));
$c = $this->_context;
stream_context_set_option($c,"http","content",$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
return $resp;
) else (
// on appelle la fonction de l "objet
call_user_method_array($methodName, $this,$params);
}
}

Private function registerMethod ($method) (
$this->_methods[$method] = true;
}

Using XML-RPC in PHP to Publish Content to LiveJournal.com (LJ)

First you need to download the XML-RPC library. The most successful version seems to me freely distributed through sourceforge " ": All examples below will be given for this library version 2.2.

What is XML-RPC? RPC stands for Remote Procedure Call, respectively, it can be translated into Russian as a remote procedure call using XML. The remote procedure call technique itself has been known for a long time and is used in technologies such as DCOM, SOAP, CORBA. RPC is intended for building distributed client-server applications. This makes it possible to build applications that operate in heterogeneous networks, for example, on computers of various systems, to perform remote data processing and control of remote applications. In particular, this protocol is used by the well-known Russian site livejournal.com.

Let's consider an example of how to place a Cyrillic entry (namely, problems often arise with this) in LiveJournal. Below is the working code with comments:

new xmlrpcval($name, "string"), "password" => new xmlrpcval($password, "string"), "event" => new xmlrpcval($text, "string"), "subject" => new xmlrpcval ($subj, "string"), "lineendings" => new xmlrpcval("unix", "string"), "year" => new xmlrpcval($year, "int"), "mon" => new xmlrpcval( $mon, "int"), "day" => new xmlrpcval($day, "int"), "hour" => new xmlrpcval($hour, "int"), "min" => new xmlrpcval($min , "int"), "ver" => new xmlrpcval(2, "int")); /* create a structure based on the array */ $post2 = array(new xmlrpcval($post, "struct")); /* create an XML message for the server */ $f = new xmlrpcmsg("LJ.XMLRPC.postevent", $post2); /* describe the server */ $c = new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $c->request_charset_encoding = "UTF-8"; /* optionally look at the XML code of what will be sent to the server */ echo nl2br(htmlentities($f->serialize())); /* send the XML message to the server */ $r = $c->send($f); /* parse result */ if(!$r->faultCode()) ( /* message received successfully and returned XML result */ $v = php_xmlrpc_decode($r->value()); print_r($v); ) else ( /* server returned an error */ print "An error occurred: "; print "Code: ".htmlspecialchars($r->faultCode()); print "Reason: "".htmlspecialchars($r->faultString( )).""\n"; ) ?>

In this example, only one LJ.XMLRPC.postevent method is considered - a complete list of possible commands and their syntax (in English) is available at:

WordPress has always had a built-in tool to access your site remotely. Indeed, sometimes you need to get to your site, and the computer is far from you. For a long time, the solution was a file called xmlrpc.php. However, in recent years this file has become more of a problem than a solution.

Below we will take a closer look at xmlrpc.php and why it was created. We will also look at the common security issues it can cause and how to fix them for your WordPress site.

XML-RPC is a WordPress feature that allows you to transfer data, with HTTP as the transport and XML for the encoding. Since WordPress is not a closed system and often communicates with other systems, solutions have been found for this task.

For example, let's say you want to make a post on your site from your mobile phone. You need to use the remote access provided by xmlrpc.php.

The main functionality of xmlrpc.php is the ability to connect to the site from a smartphone, the implementation of trackbacks and linkbacks from other sites, and some functions associated with the Jetpack plugin.

Why was Xmlrpc.php created and how was it used?

The implementation of XML-RPC goes way back in the early days of WordPress and even before WordPress became WordPress.

Going back to the early days of the internet, connections were very slow and the process of recording and publishing on the web was much more difficult and time consuming. Instead of making changes directly through the browser, most made them offline and then copied and pasted their content online. And this process was far from ideal.

The solution (at the time) was to create an offline blogging client where you could compose your content, then connect to your blog and publish it. This connection was made via XML-RPC. With the core functionality of XML-RPC, early applications used these connections to allow people to access their WordPress sites from other devices.

XML-RPC today

In 2008 with version 2.6 of WordPress, there was an option to turn XML-RPC on and off. However, with the release of the WordPress app for the iPhone, XML-RPC support was enabled by default and there was no way to disable it. It has remained so to this day.

Of course the functionality provided by this file has decreased significantly over time, and the file size has decreased from 83kb to 3kb, it no longer plays the same role as before.

XML-RPC properties

With the new WordPress Application Programming Interface (API), we can expect XML-RPC to be completely disabled by now. Today, this new API is still in testing and can only be enabled through a dedicated plugin.

Although you can expect the API to be included directly in the core of WordPress in the future, which will completely eliminate the need for xmlrpc.php.

The new API isn't perfect, but it provides good security, unlike xmlrpc.php.

Why disable Xmlrpc.php

The biggest issue with XML-RPC is security. The problem is not directly related to XML-RPC, but it can be used to enable an attack on your site.

Of course you can protect yourself with a very strong password and WordPress security plugins. But the best protection mode would be to simply turn it off.

There are two major weaknesses in XML-RPC that have been exploited in the past.

The first is using a brute force attack to gain access to your site. The attacker will try to access your site using xmlrpc.php by guessing various combinations of usernames and passwords. They can effectively use one command to test hundreds of different passwords. This allows them to bypass security tools that normally detect and block brute-force attacks.

The second is taking the site offline by means of a DDoS attack. Hackers will use WordPress's back notification to send it to thousands of sites at the same time. This xmlrpc.php functionality gives hackers an almost infinite number of IP addresses to propagate a DDoS attack.

To check if XML-RPC is working on your site, you can run it with a tool called XML-RPC Validator . Run your site with the tool and if you get an error, then you don't have XML-RPC support.

If you get a success message, you can stop xmlrpc.php with one of the two approaches below.

Method 1: Disabling Xmlrpc.php Using a Plugin

Disabling XML-RPC on your WordPress site is incredibly easy.

Go to section Plugins › Add New in your WordPress admin console. Find a plugin Disable XML-RPC and install it, it looks like the picture below:

Activate the plugin and you're done. This plugin will automatically insert the necessary code to disable XML-RPC.

However, remember that installed plugins may use parts of XML-RPC, and then disabling it may cause a conflict between plugins or individual parts of them and take them out of operation.

If you only want to disable individual XML-RPC elements, but allow other plugins and features to work, then refer to these plugins:

• Stop XML-RPC Attack . This plugin will stop all XML-RPC attacks, but it will allow plugins like Jetpack and other automated tools and plugins to continue working by giving them access to the xmlrpc.php files.
• Control XML-RPC Publishing . This allows you to keep control and use publications remotely.

Method 2: Disabling Xmlrpc.php Manually

If you don't want to use a plugin and prefer to do it manually, follow this approach. It will stop all incoming requests to xmlrpc.php before it is passed to WordPress.

Open the .htaccess file. You may need to enable ‘show hidden files’ in your file manager or FTP client to find this file.

Paste this code into the file .htaccess:

# Block WordPress xmlrpc.php requests order deny,allow deny from all allow from 123.123.123.123

Final Thoughts

All in all, XML-RPC was a good solution to some of the problems that came with remote publishing to your WordPress site. However, at the same time, some security holes appeared that turned out to be quite dangerous for some WordPress site owners.

To keep your site secure, it's recommended to disable xmlrpc.php completely unless you need some of the functionality needed for remote publishing and the Jetpack plugin. You can then use workaround plugins that allow you to use these features while still patching the security holes.

Over time, we can expect XML-RPC functionality to be integrated into the new WordPress API, which will support remote access without sacrificing security.

Did you block access to XML-RPC through a plugin or manually? Or were there any security issues due to the fact that it was previously active? Share your experience in the comments below.

XML-RPC technology is used in the WordPress system for various nice features like pingbacks, trackbacks, remote site management without logging into the admin area, etc. Unfortunately, attackers can use it to DDoS attacks on websites. That is, you create beautiful interesting WP projects for yourself or to order, and at the same time, without suspecting anything, you can be part of a DDoS botnet. Connecting together tens and hundreds of thousands of sites, bad people create a powerful attack on their victim. Although your site also suffers, because. the load goes to the hosting where it is hosted.

Evidence of such bad activity can be server logs (access.log in nginx) containing the following lines:

103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"

But back to the XML-RPC vulnerability. Visually, it manifests itself in the slow opening of sites on your server or the inability to load them at all (502 Bad Gateway error). The technical support of my FASTVPS hoster confirmed my guesses and advised:

1. Update WordPress to the latest version along with plugins. In general, if you follow, you might have read about the need to install the latest 4.2.3. due to security criticisms (just like previous versions). In short, updating is good.

1. Install the Disable XML-RPC Pingback plugin.

Disabling XML-RPC in WordPress

Previously, it seems to me, the option to enable / disable XML-RPC was somewhere in the system settings, but now I can not find it there. Therefore, the easiest way to get rid of it is to use the appropriate plugin.

Find and download Disable XML-RPC Pingback or by installing it directly from the system admin panel. You do not need to configure anything additionally, the module starts working immediately. It removes the pingback.ping and pingback.extensions.getPingbacks methods from the XML-RPC interface. Also removes X-Pingback from HTTP headers.

In one of the blogs, I found a couple more options for removing the XML-RPC disable.

1. Disable XML-RPC in the template.

To do this, a line is added to the theme's functions.php file:

Order Deny,Allow Deny from all

I personally did not use the last two methods, because. I connected the Disable XML-RPC Pingback plugin - I think it will be enough. Just for those who do not like extra settings, I offered alternative options.