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

Pourquoi WAP AI Assistant affiche un avertissement HTTPS sur un site déjà en HTTPS

Un cadenas valide dans le navigateur confirme la connexion entre le visiteur et la périphérie, mais ne prouve pas à lui seul ce que WordPress reçoit à l’origine. Un proxy inverse, un répartiteur de charge ou un mode de chiffrement CDN peut laisser le navigateur utiliser HTTPS alors que la requête atteint WordPress en HTTP.

Le même avertissement peut aussi apparaître lorsque la détection HTTPS est correcte, mais que les mots de passe d’application sont désactivés globalement ou pour l’utilisateur courant. Testez les deux conditions séparément.

Causes probables

  • Le navigateur utilise HTTPS, mais WordPress ne considère pas la requête reçue à l’origine comme sécurisée.
  • Une extension de sécurité, une extension obligatoire ou un filtre personnalisé désactive globalement les mots de passe d’application.
  • La version installée de l’extension affiche un avis HTTPS erroné ou périmé.
  • L’adresse web de WordPress et l’adresse du site utilisent des schémas, hôtes ou chemins différents.
  • Une autre extension modifie la détection de HTTPS, l’accès REST ou la disponibilité des mots de passe d’application.

Séquence de diagnostic

  1. Consignez le message exact assaini, le code HTTP et le corps de réponse sans inclure de secret.
  2. Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.
  3. Confirmez que l’URL exacte utilisée par l’assistant se charge avec une connexion HTTPS valide.
  4. Confirmez que WordPress lui-même considère la requête comme HTTPS, et pas seulement le navigateur.
  5. Vérifiez si les mots de passe d’application sont globalement disponibles dans l’environnement WordPress actif.
  6. Comparez l’adresse web de WordPress, l’adresse du site, l’hôte canonique public et l’adresse de base REST.
  7. Comparez la version installée avec le journal officiel des changements et les versions correctives.

Appliquer le correctif minimal

  1. Corrigez la gestion du proxy approuvé et de l’origine afin que WordPress reconnaisse fiablement la requête HTTPS initiale.
  2. Supprimez ou restreignez le filtre qui désactive les mots de passe d’application seulement après avoir confirmé la politique de sécurité voulue.
  3. Alignez l’adresse web de WordPress, l’adresse du site, l’hôte public, le schéma HTTPS et l’adresse de base REST.
  4. Mettez à jour vers la version de l’extension qui documente ou corrige le comportement observé.
  5. Transmettez des preuves assainies et versionnées au soutien lorsque le comportement demeure propre à l’extension.

Vérifier le résultat

  • L’avis disparaît seulement dans la condition corrigée et ne revient pas sur des pages d’administration sans lien.
  • L’index REST répond depuis l’URL HTTPS canonique et expose les espaces de noms attendus.
  • La requête authentifiée atteint le point de terminaison canonique sans redirection inattendue.
  • La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.

Ce qu’il ne faut pas faire

  • N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
  • 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 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.
  • Ne qualifiez pas l’avis ou l’identifiant de logiciel malveillant, de porte dérobée ou de compromission sans preuve.

Guides connexes

Sources et vérification

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