WordPress – XMLRPC – le client IXR et la protection ‘http Basic Authentication’

Le contexte :

WordPress contient des puissantes bibilothèques de code pour gérer des échanges de données entre sites WP via le protocole XMLRPC. On parle aussi de webservices.

Il y a quelques limites :
– Il est impossible d’envoyer des données d’un site WP à un autre qui est protégé basiquement par login, mot de passe ( http Basic Authentication (.htaccess et .htpasswd étant souvent utilisés temporairement par exemple pendant un développement pour éloigner les curieux ).
et l’utilisation d’un URI comme http://user:paswd@www.domain.tld/xmlrpc.php ne fonctionne pas, ce que confirme la lecture des sources.
– …

Compte-rendu d’un voyage de quelques heures dans la doc en ligne et les sources :

Dans le code source de WP, les fichiers les plus importants sont :

include_once(ABSPATH . WPINC . '/class-IXR.php'); /* not included in wp-settings */
include_once(ABSPATH . WPINC . '/class-wp-http-ixr-client.php'); /* not included in wp-settings */

qui s’additionnnent à ceux ajoutés lors du lancement de WP dont :

class-wp-xmlrpc-server.php

XML dans WP repose sur IXR ‘The Incutio XML-RPC Library’.
Tel qu’expliqué ici,
http://www.phppatterns.com/docs/develop/xmlrpc_progress
IXR ne contient pas les moyens de gérer l’authentication lors des échanges à partir du client.

En continuant les recherches, cette bibliothèque bien documentée attire toute notre attention.

http://phpxmlrpc.sourceforge.net/

En traçant le source notamment du fichier xmlrpc.inc, la façon d’envoyer l’authentification « basic » au serveur par le client est décrite en ajoutant dans le header.

$credentials='Authorization: Basic ' . base64_encode($username . ':' . $password) . "\r\n";

Comme le choix est d’utiliser au maximum, ce qui existe dans les sources WP…
Heureusement WP utilise son propre wp-ixr-client (extension de la classe IXR client) et utilise sa classe class-HTTP et la fonction wp_remote_post (présente dans le fichier http.php).

Cette classe WP_Http contient de nombreux filtres exploitables.
Ici, pour ajouter le header décrit plus haut, le filtre – http_request_args – est le plus intéressant (ligne 110 en WP 3.2.1)

Une solution rapide (et très, très basique) :

Avec le filtre – http_request_args – ajout de Authorization dans la méthode ‘request’.

Exemple de codes :

function xili_add_basic_authentication ( $args, $url ) {
 
	if ( false !== strpos($url, 'www.target_site.tld') ) {
		//error_log ($url);
		//error_log (serialize( $args ));
		$args['headers']['Authorization'] = 'Basic '. base64_encode('http_user' . ':' . 'http_passwd');
	}
	return $args;
}
 
add_filter ( 'http_request_args', 'xili_add_basic_authentication', 10, 2 );

Notez que :

– ‘headers’ est un tableau (array) et que la classe WP_Http fabrique les lignes envoyées au site distant.
– ‘http_user’ et ‘http_passwd’ sont le login et password présents dans le fichier .passwd file dont le path est dans .htaccess du site WP cible. Ne pas confondre avec ceux de WP donc ceux du protocole xmlrpc (wp users).
– Bien le mode d’authentification Basic soit très faible, ici c’est juste un exemple pour le wp ixr client présent dans WP et que, bien-sûr, on invite à enrichir.

Espérons que ce bref retour d’expérience sera utile aux férus de webservices entre sites WP !