Distinguer l’accès XML-RPC de la connexion dans le navigateur
Votre client de publication affiche un refus XML-RPC, une erreur 403 ou un message d’authentification alors que l’administration WordPress s’ouvre dans le navigateur. Ces deux parcours n’utilisent pas nécessairement la même méthode ni la même identité. Un réglage qui protège les connexions interactives peut également modifier l’accès d’une application qui n’affiche pas de second facteur.
Le résultat recherché est une connexion autorisée du client au bon site, suivie d’une lecture ou d’un brouillon de test contrôlé. Il faut d’abord confirmer que ce client utilise réellement XML-RPC. Une intégration REST, une connexion par service intermédiaire ou une clé d’API externe ne se répare pas automatiquement en ouvrant xmlrpc.php.
Sur une installation auto-hébergée, le compte doit disposer des droits nécessaires à l’action et le responsable du site doit autoriser ce mode d’accès. Sur WordPress.com ou une offre gérée, suivez le parcours pris en charge par la plateforme et par le client. Dans un multisite, vérifiez le sous-site visé et les droits de ce compte à cet endroit, pas seulement son existence dans le réseau.
Préserver les publications et l’accès avant les essais
Mettez les envois automatiques du client en pause et conservez ses brouillons locaux. Ne relancez pas plusieurs fois une publication pour voir si la connexion revient : la première tentative peut avoir créé un contenu avant une erreur de réponse. Vérifiez les articles et les brouillons depuis l’administration avant de reprendre.
Notez la version du client, l’adresse configurée, le compte utilisé, l’heure et le message exact. Gardez les identifiants et jetons privés. Préparez une sauvegarde des réglages avant une modification de sécurité. Pour un essai d’écriture, utilisez une copie avec les effets externes neutralisés et un compte adapté au brouillon témoin.
Conservez une connexion administrative indépendante et votre moyen de second facteur pendant le diagnostic. Une réparation de client ne doit pas vous conduire à désactiver toutes les protections de connexion. Si une règle ciblée doit être modifiée, son ancienne valeur et son responsable doivent être connus pour pouvoir revenir en arrière. Ne supprimez pas les autres accès d’application avant d’avoir identifié celui qui correspond au client en panne.
Vérifier l’adresse exacte du point d’entrée
Consultez les réglages du site dans le client et la documentation de son mode de connexion. XML-RPC utilise normalement le fichier xmlrpc.php de l’installation WordPress. Si le cœur se trouve dans un sous-dossier, ce point d’entrée peut différer de l’adresse publique de l’accueil. Ne le déduisez pas d’une ancienne adresse mémorisée après migration. Dans Réglages, Général, l’Adresse web de WordPress peut aider à repérer où se trouve le cœur : consultez cette valeur sans la modifier pour ce diagnostic. Un chemin personnalisé reste à confirmer auprès du responsable.
Comparez le domaine, HTTPS, le chemin et l’éventuelle redirection. Un lien qui finit sur une page de connexion HTML ou sur un autre domaine ne constitue pas la réponse XML attendue. Ne transmettez pas des identifiants à une destination nouvelle sans confirmer son appartenance au site. Le client doit utiliser l’adresse finale officiellement prévue, selon son parcours de découverte.
- Ouvrez la configuration du site dans le client sans effacer ses brouillons.
- Comparez l’adresse à l’installation actuelle et à la documentation du client.
- Corrigez seulement l’adresse confirmée, en conservant l’ancienne valeur.
- Reprenez d’abord une lecture ou un rafraîchissement sans publication.
- Si une redirection inattendue persiste, corrigez son origine avant de renouveler les identifiants.
Ne pas confondre une visite GET avec un appel XML-RPC
Ouvrir le fichier dans la barre du navigateur envoie généralement une requête GET. Le message « XML-RPC server accepts POST requests only » peut montrer que le point d’entrée est accessible de cette manière ; il ne prouve pas qu’un appel POST du client passe le pare-feu ou que son authentification réussit.
Un refus 403 sur GET ne décrit pas non plus à lui seul le traitement du POST utilisé par l’application. Gardez la méthode, le statut et le type de réponse. Une page HTML de protection et une réponse XML contenant une faute d’authentification ne désignent pas le même niveau de panne.
Le filtre WordPress xmlrpc_enabled porte sur les méthodes qui demandent une authentification, notamment la publication. Il ne désactive pas nécessairement toutes les méthodes publiques. Une réponse à une demande publique peut donc coexister avec une publication désactivée. Ne concluez pas qu’un plugin ment sur son état simplement parce qu’un test de lecture obtient encore une réponse. La comparaison doit correspondre au type d’accès réellement nécessaire au client.
Faire un appel public borné si un terminal est disponible
Ce contrôle facultatif s’adresse à un lecteur qui dispose déjà de curl. Remplacez le domaine fictif et le chemin par le point d’entrée confirmé de votre site. La commande ci-dessous est écrite pour un shell de type Unix. Sous Windows, ouvrez PowerShell, remplacez curl par curl.exe et réunissez les lignes en retirant les caractères \ de continuation ; conservez les guillemets simples. Ne la copiez pas telle quelle dans l’invite cmd. Elle demande la liste des méthodes, sans identifiant et sans création de contenu.
Les délais limitent l’attente de ce contrôle. Les redirections ne sont pas suivies automatiquement : si une adresse différente est renvoyée, vérifiez-la avant un autre essai. Gardez la sortie privée si elle révèle des informations d’environnement. Aucun jeton ou mot de passe ne doit être ajouté pour cette étape.
Une liste XML reçue confirme seulement cette réponse publique sur ce trajet. Elle ne valide ni les méthodes authentifiées ni le compte du client. Une faute XML indiquant une méthode inconnue peut simplement signifier que cette méthode publique a été retirée : elle ne justifie pas l’ouverture de tout XML-RPC. Une page HTML de refus ou un statut de protection demande la vérification de la règle correspondante. Si vous n’avez pas de terminal, le relevé du client et les journaux du prestataire permettent de poursuivre sans installer une extension pour ce seul contrôle.
curl -q --silent --show-error --include --connect-timeout 5 --max-time 15 \
--header 'Content-Type: text/xml' \
--data '<methodCall><methodName>system.listMethods</methodName><params/></methodCall>' \
'https://exemple.invalid/xmlrpc.php'Classer le résultat avant de changer l’authentification
Si le client ne reçoit jamais la réponse XML du point d’entrée, recherchez d’abord le trajet : adresse incorrecte, redirection, protection HTTP, pare-feu ou blocage d’hébergement. Faites rapprocher le message et l’heure des journaux de la couche concernée. Le mot 403 dans l’application ne dit pas à lui seul si le refus vient de WordPress ou d’un service placé devant lui.
Si une réponse XML signale des identifiants refusés, vérifiez le mécanisme attendu par le client et la politique du site. Un numéro de faute dans un document XML n’est pas automatiquement le statut HTTP de la réponse. Conservez ces deux informations distinctement pour éviter une modification de serveur qui ne peut pas corriger l’identité utilisée.
Si la connexion réussit mais qu’une opération précise est refusée, examinez les droits du compte et la méthode demandée. Ne lui accordez pas immédiatement un rôle administrateur. Enfin, si un seul appareil échoue, comparez sa version et sa configuration avec celui qui fonctionne ; une ancienne session encore valide sur l’autre appareil ne prouve pas que le nouvel accès utilise les mêmes identifiants.
Choisir une identité compatible avec le client et la protection
Un mot de passe d’application WordPress est un accès révocable lié à un utilisateur précis. Il convient aux outils qui prennent en charge ce mécanisme, sans leur communiquer le mot de passe principal. Il ne sert pas à ouvrir une connexion interactive dans wp-admin. Le compte conserve ses droits : ce secret ne lui accorde pas automatiquement des capacités supplémentaires. Son nom est une étiquette, pas une restriction aux seules fonctions de ce client ; choisissez donc un compte dont les droits correspondent réellement au besoin.
La manière de le transmettre dépend du protocole et du client. WordPress permet son usage avec XML-RPC, mais une protection peut imposer une méthode particulière. Vérifiez les deux documentations avant de coller le secret dans un champ nommé mot de passe. Certains outils utilisent une autorisation déléguée ou une signature propre ; il ne faut pas remplacer leur jeton par un mot de passe d’application arbitraire.
Si le client ne prend pas en charge l’accès autorisé par le site, choisissez sa mise à jour ou un parcours officiel compatible. Ne tentez pas de stocker un code de second facteur temporaire comme un mot de passe permanent. N’utilisez pas non plus une session copiée du navigateur pour contourner le mécanisme : elle peut expirer et ne constitue pas une configuration d’intégration maintenable.
Créer un mot de passe d’application dédié lorsque ce parcours convient
Sur l’installation auto-hébergée, cette voie demande HTTPS et l’accès au profil de l’utilisateur concerné. Dans Comptes ou Utilisateurs, Profil, recherchez Mots de passe d’application. Si la section manque, vérifiez la disponibilité de la fonction et la politique du site avec son responsable. Ne forcez pas son activation par un extrait de code sans connaître le réglage qui l’a masquée.
Créez un accès portant le nom précis du client et de l’appareil. Le secret est affiché une seule fois ; conservez-le dans le gestionnaire de secrets prévu et saisissez-le uniquement dans le parcours documenté du client. Gardez le mot de passe principal et le second facteur pour leur usage habituel.
- Ouvrez le profil du compte réellement utilisé par le client.
- Ajoutez un nom explicite dans Mots de passe d’application, puis générez cet accès.
- Enregistrez le secret en privé et configurez le client selon sa documentation.
- Testez une lecture avant tout envoi de contenu.
- Si l’essai échoue ou est abandonné, révoquez seulement cet accès depuis le même profil ; ne supprimez pas ceux d’autres intégrations.
Examiner Wordfence seulement s’il protège déjà le site
Dans Wordfence, Login Security, Settings, l’option Disable XML-RPC authentication refuse les appels qui demandent une authentification. La désactiver peut être nécessaire à un usage autorisé, mais cette décision doit correspondre à la politique du site. Conservez sa valeur initiale. Le réglage Require 2FA for XML-RPC call authentication constitue un contrôle distinct : ne basculez pas toutes les options pour obtenir une connexion.
La documentation décrit l’usage de mots de passe d’application, notamment via l’en-tête Authorization pour une intégration compatible. Vérifiez que le client sait utiliser le mécanisme retenu. Ne supposez pas qu’un secret saisi dans n’importe quel champ contourne automatiquement une politique de second facteur.
Il n’est pas nécessaire d’installer Wordfence pour réparer un autre dispositif. Vérifiez l’extension et sa version déjà présentes avant de suivre ce menu : Wordfence Security et une solution de sécurité différente ne partagent pas forcément les mêmes réglages.
- Relevez les valeurs actuelles dans Login Security, Settings.
- Faites valider le mode d’accès nécessaire et changez seulement la règle confirmée. Enregistrez la modification, puis rechargez les réglages pour contrôler la valeur conservée.
- Reprenez une lecture avec le client compatible.
- Si l’essai est inutile, restaurez immédiatement la valeur initiale et enregistrez ce retour. Gardez le second facteur de la connexion interactive actif.
Corriger la seule règle serveur qui refuse l’appel légitime
Si les journaux confirment un refus avant WordPress, le responsable doit examiner le chemin et la méthode POST concernés. Une règle peut bloquer entièrement xmlrpc.php, appliquer une protection HTTP ou traiter différemment certaines origines de requête. Gardez le texte exact de la règle et son contexte avant toute modification.
La correction doit autoriser le parcours nécessaire selon la politique du site, sans retirer la protection de tout le domaine. Si le prestataire impose un blocage non modifiable, le client doit utiliser un autre mode officiellement pris en charge. Une ouverture partielle ne convient que si l’origine, l’identité et les méthodes peuvent être gérées correctement ; ne copiez pas une ancienne règle Apache universelle dans un environnement inconnu.
- Faites identifier la règle dans la couche qui enregistre réellement le refus.
- Conservez sa valeur, sa portée et son propriétaire.
- Adaptez uniquement le cas autorisé, d’abord sur copie ou dans le périmètre d’essai prévu.
- Testez le même client puis une navigation ordinaire.
- Si la modification est inutile ou trop large, restaurez la règle et choisissez le parcours compatible du client.
Vérifier les droits lorsque la connexion fonctionne déjà
Une authentification réussie ne garantit pas le droit d’effectuer chaque méthode XML-RPC. Le compte peut lire certaines informations mais ne pas publier, modifier un article d’un autre auteur ou envoyer un type de contenu. Comparez l’action attendue avec ce que le même utilisateur peut faire dans l’administration du sous-site concerné.
Si le client choisit le mauvais site ou le mauvais type de contenu, corrigez ce choix avant d’augmenter les permissions. Dans un multisite, un compte peut exister dans le réseau sans posséder le rôle requis sur chaque sous-site. Un identifiant de site transmis par le client peut aussi désigner un autre contexte que celui affiché au premier écran.
Attribuez seulement le rôle ou la capacité nécessaire selon l’organisation du site. Ne créez pas un administrateur permanent pour tester une simple lecture. Conservez les droits initiaux et retirez les permissions de diagnostic devenues inutiles. Si l’opération reste refusée malgré le bon contexte, gardez le nom de méthode et le message exact pour le responsable du client ou du composant qui ajoute ce type de contenu.
Valider une lecture puis un brouillon de test sur copie
Commencez par le rafraîchissement des contenus ou une autre lecture documentée du client. Vérifiez que les bons éléments apparaissent et que l’accès utilise le compte prévu. Comparez les journaux de la même heure pour confirmer que le POST atteint le service attendu, sans blocage silencieusement déplacé à une autre couche.
Si le besoin comprend une écriture, créez ensuite sur la copie un brouillon clairement identifié, avec les envois externes neutralisés. Contrôlez son auteur, son statut, son site de destination et son contenu dans l’administration. Ne publiez pas sur le site réel pour prouver une connexion. Vérifiez avant une nouvelle tentative que le brouillon précédent n’existe pas déjà.
Reprenez aussi une connexion interactive normale pour confirmer que ses protections prévues restent utilisables. Retirez le contenu témoin et les accès provisoires devenus inutiles. Si la correction dépend d’une règle de sécurité modifiée, documentez sa portée exacte. Un compte qui se connecte une fois ne valide pas toutes les fonctions annoncées par le client ; contrôlez séparément celles qui sont réellement nécessaires, sans élargir les permissions par habitude.
Retirer les accès d’essai et garder un parcours compatible
Une fois le client rétabli, conservez le nom de son accès dédié, le compte et le protocole utilisés. Révoquez seulement les secrets créés pour des essais abandonnés. Si un secret a été partagé dans une capture ou un ticket, révoquez cet accès et recréez-en un par le parcours normal ; le masquer après publication ne retire pas la copie déjà exposée.
Si le site doit garder XML-RPC bloqué, vérifiez si le client propose un mode REST, une connexion déléguée ou une autre méthode officiellement maintenue. Cette alternative doit être configurée et validée selon sa documentation ; renommer l’adresse du point d’entrée ne convertit pas le protocole. Évitez de laisser une ouverture temporaire alors que le client utilise finalement un autre trajet.
Pour un incident futur, gardez l’adresse exacte, la méthode, le statut HTTP, la faute XML éventuelle et l’heure. Ajoutez le changement de politique qui précédait l’échec, sans inclure de secret. Ce dossier permet de distinguer un blocage du transport, une authentification incompatible et un droit manquant. La connexion durable repose sur l’accord entre le client et la protection du site, avec un retour arrière connu pour chaque réglage essayé.
