PAGUP Agent ControlAccès WordPress pour les assistants IA
Essayer gratuitement

Boucle de redirection d’une connexion IA WordPress : contrôles HTTP, HTTPS et URL canonique

Une redirection change le schéma, l’hôte ou le chemin et peut aussi supprimer les en-têtes d’authentification.

Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.

Causes probables

  • Une redirection change le schéma, l’hôte ou le chemin et peut aussi supprimer les en-têtes d’authentification.
  • L’adresse web de WordPress et l’adresse du site utilisent des schémas, hôtes ou chemins différents.
  • Le navigateur utilise HTTPS, mais WordPress ne considère pas la requête reçue à l’origine comme sécurisée.
  • Le client appelle le mauvais domaine, chemin de base, point de terminaison REST ou point de terminaison MCP.
  • L’hébergement, le proxy inverse, une redirection ou le WAF supprime l’en-tête Authorization avant son arrivée dans WordPress.

Séquence de diagnostic

  1. Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.
  2. Comparez l’adresse web de WordPress, l’adresse du site, l’hôte canonique public et l’adresse de base REST.
  3. Confirmez que WordPress lui-même considère la requête comme HTTPS, et pas seulement le navigateur.
  4. Vérifiez au moyen de preuves serveur assainies que l’en-tête Authorization atteint WordPress.
  5. Confirmez le schéma, l’hôte, le chemin de base et le point de terminaison exacts configurés dans le client.
  6. Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.

Appliquer le correctif minimal

  1. Supprimez ou corrigez la redirection qui modifie la requête authentifiée de manière inattendue.
  2. Alignez l’adresse web de WordPress, l’adresse du site, l’hôte public, le schéma HTTPS et l’adresse de base REST.
  3. Corrigez la gestion du proxy approuvé et de l’origine afin que WordPress reconnaisse fiablement la requête HTTPS initiale.
  4. Configurez le chemin serveur ou proxy approuvé pour transmettre l’en-tête Authorization à WordPress.
  5. Corrigez le point de terminaison, le transport, le nom d’outil ou la référence d’identifiant sans élargir les permissions WordPress.

Vérifier le résultat

  • La requête authentifiée atteint le point de terminaison canonique sans redirection inattendue.
  • Les preuves serveur assainies confirment que l’en-tête Authorization atteint WordPress.
  • La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.
  • La lecture étroite approuvée réussit avec une réponse reproductible.

Ce qu’il ne faut pas faire

  • N’ajoutez pas un contournement permanent et non vérifié du proxy avant de confirmer le chemin approuvé de la requête.
  • Ne désactivez pas globalement le WAF ou l’extension de sécurité pour contourner une seule requête.
  • Ne modifiez pas le cœur de WordPress ou les fichiers d’une extension tierce comme première étape de diagnostic.
  • N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
  • Ne placez jamais un mot de passe d’application, un en-tête Authorization, un jeton ou un témoin dans une invite, un billet, un extrait de journal ou une capture.

Guides connexes

Sources et vérification

Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .