Distinguer un refus d’API d’une connexion au tableau de bord
Vous avez généré un mot de passe d’application dans WordPress, mais votre outil reçoit une erreur 401 ou un message indiquant que l’identification est incorrecte. Votre compte continue parfois à ouvrir le tableau de bord normalement. Le résultat recherché est une requête d’API reconnue comme provenant du bon utilisateur, puis autorisée à effectuer uniquement les actions prévues.
Ce guide concerne l’authentification native d’un WordPress autohébergé par mot de passe d’application. Cette fonction existe depuis WordPress 5.6. Elle sert aux logiciels qui interrogent les interfaces du site ; elle ne remplace pas le mot de passe que vous saisissez dans le formulaire habituel de connexion. WordPress.com, les clés d’API propres à une extension et les autorisations d’un service externe suivent d’autres parcours.
Relevez la version de WordPress, l’adresse exacte appelée, le logiciel utilisé et le message complet, en masquant les secrets. Une erreur 401 ne prouve pas à elle seule que vous avez mal copié le mot de passe : une protection placée avant WordPress peut aussi refuser la demande. Inversement, réussir à consulter une page publique ne prouve pas que l’API vous a identifié. Commencez donc par un essai limité qui distingue ces situations, au lieu de créer des identifiants en série.
Si votre outil fonctionne mais que son accès doit être retiré, passez au parcours d’inventaire et de révocation en fin de guide. La réussite recherchée est alors le refus de l’ancien secret et le maintien des intégrations autorisées. Il n’est pas nécessaire de provoquer d’abord une erreur 401.
Vérifier le compte, le site et le type de secret
Un mot de passe d’application appartient à un utilisateur d’une installation précise. Avec votre compte autorisé, ouvrez Comptes, Profil, ou Comptes, Tous les comptes, puis Modifier pour l’utilisateur concerné. Les traductions peuvent afficher Utilisateurs. Repérez la section Mots de passe d’application et la ligne correspondant à l’outil que vous configurez.
Confirmez que ce compte est celui dont vous utilisez l’identifiant de connexion. Le nom visible sous un article n’est pas toujours cet identifiant. Vérifiez aussi l’hôte et le chemin du WordPress visé : un secret créé sur une copie de préproduction ne doit pas être supposé valable sur le site public. Un même nom d’utilisateur sur deux installations ne les rend pas interchangeables. À l’inverse, une copie complète de la base peut avoir conservé des secrets encore valides : le changement de domaine ne les révoque pas. Vérifiez séparément les accès de chaque environnement.
Le champ du logiciel doit recevoir le mot de passe généré pour l’application, pas le mot de passe principal du compte, une clé d’un service tiers ou un jeton de connexion unique. Le secret généré n’est affiché qu’à sa création. Si vous ne l’avez plus, WordPress ne permet pas de le relire depuis cette liste ; préparez un remplacement ciblé plutôt que de chercher à afficher les valeurs stockées en base. Conservez le nom et la date de la ligne existante pour pouvoir identifier précisément l’accès lors du diagnostic.
Préparer une comparaison qui n’envoie rien à vos visiteurs
L’essai de départ doit lire l’identité du compte, sans créer d’article, envoyer un courriel ou modifier un produit. Prévoyez l’accès à votre profil WordPress et, si vous utilisez la commande proposée, un terminal dans un environnement de confiance. Vous n’avez pas besoin de devenir super administrateur ni d’installer une nouvelle extension pour effectuer cette comparaison.
Gardez les paramètres actuels du connecteur dans une note privée avant de les modifier, sans recopier son secret dans un rapport partagé. Consignez l’URL, le mode d’authentification et l’identifiant du compte. L’objectif est de pouvoir revenir à la configuration initiale si l’essai révèle que le problème se situe ailleurs.
Choisissez ensuite deux observations distinctes : la requête minimale décrite ci-dessous et la demande qui échoue dans votre logiciel habituel. Si la première fonctionne, concentrez-vous sur ce logiciel et sur la route qu’il appelle. Si les deux échouent, vérifiez le compte, la disponibilité de la fonction et le trajet vers WordPress. Cette méthode évite de désactiver successivement toutes les protections du site sans savoir laquelle intervient. N’envoyez pas votre mot de passe d’application à une personne ou à un outil public de diagnostic pour obtenir ces résultats.
Faire un essai GET isolé, sans secret dans la commande
La commande suivante convient à un terminal où curl est déjà disponible. Remplacez l’identifiant et l’URL fictive par vos valeurs, en conservant le chemin éventuel d’installation. Sous Windows PowerShell, utilisez explicitement curl.exe si curl désigne une autre commande. L’option --disable, placée en premier, évite de charger un fichier de configuration curl personnel qui fausserait cet essai.
curl demande le mot de passe séparément : saisissez alors le secret d’application, sans l’ajouter à la ligne de commande. L’URL appelle votre propre fiche via une requête GET, donc sans demander de modification de contenu. Le résultat contient des informations sur votre compte ; gardez-le privé et relevez seulement l’identité attendue, le statut et un éventuel message d’erreur.
Si votre installation n’utilise pas les permaliens lisibles et que la route renvoie 404, demandez au mainteneur de confirmer la variante HTTPS /?rest_route=/wp/v2/users/me, à ajouter après le chemin de cette installation. Une route absente ne démontre pas un mauvais secret.
L’essai ne réutilise pas les cookies de votre navigateur et ne suit pas automatiquement une redirection. Si vous obtenez une redirection, contrôlez d’abord sa destination et utilisez l’adresse HTTPS canonique. N’ajoutez pas une option qui transmettrait les identifiants à une destination différente sans contrôle. N’utilisez pas non plus une option ignorant les erreurs de certificat : une panne TLS doit être corrigée avant l’authentification. Cette commande est un exemple à exécuter sur votre site autorisé ; aucun résultat n’est supposé à l’avance.
curl --disable --basic --user 'VOTRE_IDENTIFIANT' --connect-timeout 5 --max-time 15 --write-out '\nHTTP %{http_code}\n' 'https://votre-site.example/wp-json/wp/v2/users/me'Lire la réponse avant de changer les droits
Une réponse attendue de cette route est un document JSON correspondant au compte identifié. Vérifiez que son identifiant est celui prévu, et pas seulement que le serveur affiche 200. Une page HTML de connexion renvoyée avec un succès HTTP n’est pas une réponse d’identité WordPress valable. Une page de blocage de l’hébergeur peut également précéder le traitement par l’API.
Si la réponse WordPress indique que l’utilisateur n’est pas connecté ou que les identifiants sont incorrects, gardez son code et son message, sans publier l’en-tête Authorization. S’il s’agit d’une page de protection HTTP, notez le nom de cette protection. Une erreur de certificat, un délai réseau et une erreur de mot de passe demandent des corrections différentes.
Si l’identité est correctement reconnue mais qu’une autre route refuse une action, l’authentification minimale a réussi. Vérifiez alors les capacités du compte et les exigences de cette route. Une requête visant des réglages d’administration n’est pas équivalente à la lecture de votre propre profil. N’accordez pas un rôle Administrateur simplement parce qu’une réponse comporte le nombre 403 ou 401 : recherchez d’abord la couche et le contrôle qui produisent ce refus. Le statut HTTP est un indice à rapprocher du corps de la réponse, pas une conclusion suffisante.
Vérifier HTTPS et la disponibilité de la fonction
Sur un site public, utilisez une adresse HTTPS dont le certificat est valide et qui correspond bien au domaine prévu. Le cœur rend normalement les mots de passe d’application disponibles avec HTTPS, ou dans un environnement local reconnu. Une fonction forcée sur un site public en HTTP exposerait les identifiants pendant leur transmission ; ce n’est pas une solution au refus.
Lorsque la section manque du profil ou que WordPress signale la fonction indisponible, le mainteneur vérifie aussi la détection HTTPS derrière un éventuel proxy. Le fait que le navigateur affiche HTTPS ne décrit pas toujours la façon dont PHP reçoit la requête. La configuration doit suivre le circuit de confiance prévu par l’hébergeur.
Des filtres de WordPress, une extension de sécurité ou du code spécifique peuvent désactiver cette méthode globalement ou pour certains comptes. Consultez la politique existante avant de la modifier. Si cette désactivation est volontaire, utilisez un mode de connexion approuvé par le responsable ; ne copiez pas un filtre qui réactive tout le monde pour faire apparaître un champ. Le résultat attendu est une disponibilité cohérente avec la politique du site et avec le compte concerné. En cas de correction de configuration, conservez sa valeur précédente et validez le même essai minimal après le changement.
Corriger le client quand l’essai minimal fonctionne
Si la lecture d’identité réussit avec curl, gardez le même compte, le même secret et la même URL pour comparer votre logiciel habituel. Dans son écran de connexion au site ou ses paramètres d’authentification, choisissez le mode Basic Authentication lorsque cette intégration utilise bien les mots de passe d’application natifs. Le champ utilisateur reçoit l’identifiant WordPress et le champ mot de passe reçoit le secret d’application.
Retirez seulement les paramètres contradictoires que vous avez ajoutés pour cet essai : un ancien jeton Bearer, un en-tête Authorization saisi manuellement ou des cookies importés du navigateur. Un client ne doit pas fabriquer plusieurs méthodes incompatibles pour une seule demande. Si le logiciel est prévu pour des clés propres à une extension, consultez sa documentation au lieu de placer le secret WordPress dans un champ portant un autre usage.
Exécutez ensuite la même lecture d’identité, avant de réessayer une action de publication. Le résultat attendu est le même compte reconnu par les deux parcours. Si le logiciel échoue toujours, restaurez ses paramètres sauvegardés et transmettez au mainteneur le nom de la méthode choisie ainsi que le message obtenu. Ne joignez pas le secret. La différence entre deux demandes équivalentes fournit une piste concrète sur le client ; elle ne justifie pas de modifier tous les comptes ou de remplacer le système d’authentification du site.
Vérifier les capacités seulement après une identification réussie
Un mot de passe d’application ne crée pas automatiquement un rôle plus puissant pour le logiciel. Les actions disponibles dépendent du compte auquel il appartient, des capacités exposées par l’API et des restrictions éventuelles du site. Lire votre propre profil et modifier des contenus d’autres auteurs sont des demandes différentes.
Dans Comptes, Tous les comptes, le responsable autorisé examine le rôle du compte utilisé et le rapproche de la fonction réellement nécessaire. En multisite, il vérifie également l’affectation au sous-site ciblé. Un utilisateur du réseau peut ne pas posséder le rôle requis sur ce sous-site. Le contrôle doit donc porter sur la bonne URL et la bonne fiche, sans transformer une difficulté locale en attribution de super administration.
Si une capacité manque réellement, le responsable choisit le rôle minimal adapté ou un compte d’intégration dédié, selon la politique du site. Le nom donné au mot de passe d’application sert à le reconnaître ; il ne constitue pas à lui seul une restriction de droits. Après une modification autorisée, validez la lecture d’identité puis une opération sans effet public correspondant au besoin, sur la copie prévue pour les essais. Si la fonction exige davantage de privilèges que nécessaire, revoyez le parcours du logiciel. Une montée de rôle ne corrige pas un identifiant que WordPress ne reçoit pas.
Faire vérifier la transmission de l’en-tête Authorization
Lorsque le secret et le compte sont cohérents mais que WordPress continue à traiter la demande comme anonyme, le trajet de l’en-tête Authorization devient une hypothèse à vérifier. Un proxy, un serveur Web, une règle de protection ou la liaison avec PHP peut intervenir avant le cœur. Le simple accès public à l’URL REST ne vérifie pas cette transmission.
Le mainteneur rapproche l’heure exacte de votre essai des journaux du serveur et de l’application. Demandez-lui de constater la présence de l’en-tête au bon niveau, sans en enregistrer ni vous renvoyer la valeur. En Basic Authentication, cette valeur contient des identifiants encodés ; son encodage ne la rend pas publiable. Une capture complète des demandes peut donc compromettre le secret.
La correction doit se faire dans la couche identifiée et selon son mode d’hébergement : configuration du proxy, du serveur ou du gestionnaire PHP réellement utilisés. Une directive Apache copiée dans un réseau servi par Nginx ne répond pas au même besoin. N’ajoutez pas plusieurs recettes dans des fichiers au hasard. Le responsable garde la configuration précédente, applique une seule correction documentée et compare la même lecture d’identité. Si le résultat ne change pas, il rétablit cette modification avant de tester une autre hypothèse. Un refus de sécurité doit être expliqué par sa règle et sa portée, pas traité par une désactivation générale du pare-feu.
Distinguer la protection de préproduction de l’authentification WordPress
Une copie peut demander un nom et un mot de passe HTTP avant même de charger WordPress. Ces identifiants protègent l’environnement de préproduction ; ils sont distincts du compte WordPress et du secret d’application. Si cette couche consomme déjà l’en-tête Authorization pour une authentification Basic, la demande peut ne plus présenter à WordPress les identifiants dont il a besoin.
Ne tentez pas de résoudre ce conflit en ajoutant deux en-têtes Basic ou en mélangeant les deux couples d’identifiants dans un seul champ. Vérifiez dans le panneau de protection de la copie quelle méthode est activée et à quel chemin elle s’applique. Le mainteneur peut alors concevoir un accès de diagnostic compatible avec la politique de cette copie, par exemple par le circuit privé déjà prévu pour l’équipe, en conservant son isolation.
Le résultat attendu est que la demande franchisse la protection de l’environnement tout en fournissant à WordPress son authentification propre. Cela demande parfois un changement de méthode d’accès plutôt qu’une modification du secret. Ne rendez pas publiquement accessible toute la préproduction pour obtenir un succès ponctuel. À la fin de l’essai, rétablissez tout accès temporaire selon le plan prévu et vérifiez que les pages privées de la copie restent protégées. Un fonctionnement sur le site public et un échec sur la copie doivent être comparés avec cette différence d’infrastructure en tête.
Inventorier l’accès avant une révocation volontaire
Avant de retirer un secret encore fonctionnel, confirmez l’outil, le compte et le site avec son responsable. Le libellé du secret aide à le reconnaître, mais ne constitue pas une preuve suffisante si plusieurs lignes portent des noms proches. Dans le profil, rapprochez nom, date de création et usage observé de la configuration privée du connecteur. Notez la décision attendue : arrêter l’intégration ou remplacer son secret.
La date de dernière utilisation et la dernière adresse IP sont des indices. Le cœur espace la mise à jour de ces renseignements ; ce n’est pas un journal de chaque requête. Une absence d’heure récente ne suffit donc pas à affirmer qu’un traitement mensuel est abandonné. Une adresse IP de relais ou d’hébergement n’identifie pas nécessairement une personne.
Établissez une liste courte des fonctions à préserver, par exemple la lecture d’un rapport et la synchronisation d’un brouillon de travail. Si plusieurs outils partagent le même secret, ils seront tous affectés par sa révocation. Dans un réseau multisite, le secret appartient au compte du réseau : le retirer depuis un sous-site peut interrompre les intégrations des autres sous-sites qui l’emploient. L’URL de la commande ne limite pas cette révocation à un seul sous-site. Préparez leur séparation avant un retrait planifié. En revanche, un secret exposé appelle une décision de sécurité immédiate ; n’attendez pas artificiellement un cycle de traitement pour le laisser actif.
Choisir entre retrait définitif et rotation du secret
Pour une intégration arrêtée, ouvrez Comptes, Profil, ou la fiche autorisée du compte concerné. Dans Mots de passe d’application, repérez la ligne confirmée et choisissez son bouton Révoquer. Lisez la confirmation et vérifiez que seule cette ligne disparaît. N’utilisez pas la révocation de tous les secrets pour gagner une étape. Le compte, ses articles et les secrets des autres lignes doivent rester présents.
Pour un outil qui reste nécessaire, suivez les étapes de rotation ci-dessous. Elles supposent que l’ancien secret peut rester autorisé pendant cette courte transition. Si une fuite est soupçonnée, le responsable décide d’abord du retrait immédiat et de l’interruption ciblée.
Si le nouveau secret échoue avant le retrait de l’ancien et qu’aucune fuite n’est suspectée, rétablissez temporairement la configuration privée encore autorisée du client pendant le diagnostic. Si l’ancien secret est compromis, ne revenez pas à ce secret pour restaurer le service : acceptez l’interruption ciblée et corrigez le nouveau parcours. Le choix doit être consigné par le responsable.
- Dans le profil du compte confirmé, saisissez un nom distinct dans Nouveau nom du mot de passe d’application, puis choisissez Ajouter un nouveau mot de passe d’application. Les libellés peuvent varier avec la traduction.
- Placez la valeur affichée une seule fois dans le gestionnaire de secrets de l’intégration ; ne la collez pas dans un ticket ou dans un historique de commandes.
- Remplacez uniquement le secret de ce client. Vérifiez la lecture d’identité et la fonction attendue sans publication ni effet externe.
- Révoquez l’ancienne ligne précisément identifiée, puis effectuez les contrôles négatif et positif de la fin du parcours.
Voie facultative : lire la liste avec WP-CLI
Un mainteneur disposant déjà de WP-CLI et d’un accès serveur autorisé peut lister les secrets du compte exact. Ces sous-commandes existent à partir de WP-CLI 2.6 ; si elles sont absentes, utilisez l’interface plutôt qu’une modification de base de données. Cette voie ne donne pas l’autorisation d’inspecter tous les utilisateurs.
Dans l’exemple, remplacez le chemin d’installation, l’adresse et 123 par les valeurs confirmées du site et du compte. La sortie expose des métadonnées privées, pas la valeur réutilisable des secrets. Gardez-la dans un emplacement protégé. Le champ uuid identifie la ligne à retirer ; ce n’est ni le nom, ni le champ app_id qui décrit l’application. Si plusieurs lignes se ressemblent, comparez leur date et leur configuration avant de choisir. Ne demandez pas le champ password : il contient une empreinte dont ce diagnostic n’a pas besoin.
Avant toute commande de suppression, comparez cet UUID au relevé de la ligne visée et faites confirmer l’opération par le responsable de l’intégration. Si la liste ne correspond pas à l’installation ou au compte attendu, arrêtez ce parcours. WP-CLI travaille avec l’autorité de l’accès serveur : le choix de l’URL ou d’un utilisateur ne remplace pas l’autorisation d’intervenir sur ce compte. Un retour vide ou une erreur de connexion n’est pas la preuve qu’il n’existe plus d’accès.
wp --path='/chemin/wordpress' --url='https://votre-site.example/' user application-password list 123 --fields=uuid,name,created,last_used,last_ip --format=jsonRévoquer uniquement l’UUID confirmé avec WP-CLI
Après cette lecture, la commande ci-dessous retire un seul mot de passe d’application. Remplacez UUID_CONFIRME par l’UUID réellement relevé, et reprenez exactement le même chemin, la même URL et le même utilisateur. Ne remplacez pas ce paramètre par un nom approximatif. N’ajoutez ni option visant tous les secrets ni boucle sur des utilisateurs.
Relisez la sortie : un message indiquant un secret supprimé doit être suivi d’une nouvelle lecture de la liste, pas d’une supposition sur tous les accès du compte. Les autres UUID doivent être conservés. Si l’opération échoue, conservez son message et revérifiez le contexte ; ne multipliez pas les suppressions pour obtenir un résultat positif.
La révocation ne fournit pas de bouton d’annulation pour retrouver le même secret. Si le mauvais accès a été retiré, le retour fonctionnel consiste à créer un nouveau secret autorisé et à mettre à jour son client. Ne restaurez pas toute la base du site : vous pourriez réintroduire des accès révoqués et écraser des contenus récents. La correction doit rester limitée à l’intégration affectée.
wp --path='/chemin/wordpress' --url='https://votre-site.example/' user application-password delete 123 UUID_CONFIRMEVérifier le refus attendu et les intégrations conservées
Depuis un terminal de confiance, répétez la lecture d’identité avec l’ancien secret, sans cookies ni autre méthode d’authentification ajoutée. Elle ne doit plus identifier le compte par ce secret. Comparez le statut et le message WordPress au résultat antérieur. Un blocage réseau ou une fonction désactivée globalement rend cet essai non concluant : la disparition du seul UUID visé et le succès de l’accès conservé doivent aussi être établis. Un simple affichage public ou une page de connexion HTML n’établit pas ce contrôle. Si l’ancien secret paraît encore fonctionner, vérifiez d’abord que le client n’a pas déjà été reconfiguré et qu’il vise bien le site prévu.
Validez ensuite la lecture d’identité avec le nouveau secret ou avec une intégration autorisée conservée. Contrôlez le prochain traitement prévu sans déclencher pour essai une commande, un courriel ou une publication réelle. Le couple de résultats recherché est précis : accès retiré refusé, accès maintenu fonctionnel. Une panne généralisée demande un diagnostic de contexte, pas la création précipitée de nouveaux secrets pour tout le monde.
La révocation de ce secret ne ferme pas les sessions du navigateur, ne change pas le mot de passe principal et ne retire pas les clés propres à d’autres services. Examinez ces accès séparément si la décision concerne le départ d’un collaborateur ou un incident.
Enfin, retirez du client arrêté la configuration devenue inutile et suivez votre politique de conservation des secrets. Gardez dans le compte rendu le nom de l’intégration, l’UUID retiré, le décideur, la date et les contrôles réalisés, sans la valeur du secret. Cette trace n’affirme pas qu’aucune utilisation antérieure n’a eu lieu ; elle documente le retrait effectué.
Clore le diagnostic avec un relevé reproductible
Conservez un relevé de la cause retenue et du contrôle qui l’appuie : identité obtenue, route appelée, correction du client, disponibilité du compte ou couche serveur concernée. Ajoutez l’heure de l’essai et l’adresse canonique. Un relevé exploitable ne contient ni le secret, ni la valeur d’Authorization, ni une exportation de tous les cookies du navigateur.
Validez d’abord la lecture d’identité après correction, puis la fonction réelle sur un environnement et un contenu adaptés. Une opération qui envoie des notifications, crée une commande ou publie un article ne doit pas devenir un simple test de connexion. Si l’identité reste correcte mais qu’une fonction métier échoue, ouvrez le diagnostic propre à cette fonction en conservant ce résultat comme point de départ.
Aucune nouvelle extension d’authentification n’est nécessaire pour les parcours natifs de ce guide. Une extension ajoutant une autre méthode ne réparera pas automatiquement le trajet des en-têtes et peut compliquer la comparaison. Pour éviter une récidive, gardez une correspondance entre compte, outil, nom du secret et responsable de maintenance, puis révoquez les accès devenus inutiles selon votre politique. Ce suivi facilite un remplacement ciblé et permet de distinguer une panne technique d’un accès qui n’a plus de raison d’exister.
