Identifier un défaut de configuration reCAPTCHA
Après un changement de domaine, une restauration ou un transfert de configuration, reCAPTCHA peut signaler un domaine non autorisé ou une clé de type incompatible sur une page qui contient Contact Form 7. Le diagnostic consiste à rapprocher trois éléments. Il faut connaître le nom d’hôte de la page réellement chargée, la clé de site que le navigateur reçoit et l’enregistrement qui fournit le secret attendu par le serveur.
Dans l’intégration native moderne de Contact Form 7, reCAPTCHA v3 fonctionne en arrière-plan. La présence d’une case à cocher peut correspondre à une autre intégration. L’absence de case est normale pour v3. Si vous avez ajouté un module tiers ou si le code du thème charge son propre script, identifiez le composant avant d’interpréter le message. Une page peut charger reCAPTCHA pour plusieurs usages, avec des clés différentes.
Un message de domaine invalide, de type de clé invalide ou une erreur de paramètre n’a pas la même portée qu’un score faible calculé sur une soumission. Un score faible après validation ne démontre pas un défaut de domaine ou de paire. Un POST qui reçoit une page HTML de sécurité ne fournit pas de verdict reCAPTCHA. Ce guide rapproche d’abord la configuration et les relevés disponibles, puis propose une soumission synthétique de recette pour vérifier le résultat après correction.
Recueillez l’heure, le chemin de la page, l’environnement, la version de Contact Form 7 et le texte exact du diagnostic déjà observé. Gardez seulement des libellés de référence pour les clés. Les copies d’écran doivent masquer les valeurs et le contenu des champs. Avec ces éléments, choisissez la piste du domaine, de la paire ou de la configuration effectivement chargée.
Préparer les accès et un essai de recette sans exposer les clés
Travaillez sur une copie privée avec ses propres réglages et des accès séparés. Pour vérifier une configuration déjà connue, partez de l’inventaire de la recette et de relevés expurgés fournis par la personne qui gère la console Google. Attribuez un identifiant lisible à chaque paire, par exemple « recette actuelle » et « ancienne production ». Utilisez ces libellés pour rapprocher les environnements. Les valeurs réelles restent dans leur gestionnaire et dans les écrans réservés aux administrateurs autorisés.
Commencez l’inventaire à partir des réglages, des fichiers et des traces expurgées. L’intégration v3 peut déjà joindre Google au chargement de la page. Pour cette première lecture, un relevé HTML existant ou une copie avec les sorties externes bloquées suffit. Pour l’essai final, autorisez le chargement et la vérification Google nécessaires à la paire de recette, selon le protocole de votre environnement. Une ressource bloquée volontairement pendant l’inventaire ne démontre pas une panne du site.
Conservez le point de retour de la recette avant d’éditer ses paramètres. Relevez les noms d’hôte attendus, le projet et le type de clé, la source de configuration et le rôle de chaque valeur. Séparez les références utilisées côté navigateur des secrets de validation conservés côté serveur. Un export complet de configuration, un journal de requête ou un outil de capture réseau peut inclure des informations à garder privées.
Pour l’essai, utilisez uniquement la paire dédiée à la recette, des données synthétiques et un transport de courrier capturé localement. Neutralisez les webhooks, CRM et destinations réelles ; l’ouverture vers Google ne doit pas réactiver ces autres sorties. La soumission normale du formulaire doit produire un nouveau jeton : ne copiez pas un jeton de trace et ne lancez pas de requête siteverify manuelle. Si vous ne disposez pas des accès ou du protocole nécessaires, vous pouvez terminer le contrôle de configuration et consigner séparément l’essai restant à faire.
Approche 1 — Rapprocher le domaine final de la liste autorisée
Identifiez le nom d’hôte final de la page qui charge le formulaire. Relevez les redirections déjà observées et la page qui contient réellement le script. Pour une intégration en iframe, identifiez l’origine du document intégré. L’adresse de l’administration ou une URL mémorisée avant redirection peuvent désigner un autre hôte. Si la page est accessible par plusieurs domaines, inventoriez chaque variante réellement servie.
Comparez ce nom à la liste de domaines de l’enregistrement correspondant à la clé de site. Saisissez ou examinez des noms d’hôte, sans recopier le protocole, le port ni le chemin dans la liste. Google documente la couverture d’un domaine et de ses sous-domaines selon la configuration de la clé. Un autre domaine de premier niveau ou un nom de recette fourni par l’hébergeur peut exiger une entrée distincte. Évitez d’ajouter une famille de domaines plus large que le besoin.
Pour une migration fictive de ancien.example vers nouveau.example, une page servie par nouveau.example ne correspond pas à une liste limitée à ancien.example. Un hébergement de recette pourrait également publier la page sous recette.hebergeur.example. Ce troisième nom doit être examiné pour sa propre paire, plutôt que d’élargir par défaut la paire de production. Pour localhost, la documentation Google prévoit un enregistrement explicite lorsque ce mode de développement est nécessaire.
Préparez la correction sur une paire réservée à la recette et gardez la validation de domaine active. Comparez le relevé avant et après et vérifiez la portée exacte du changement. Si vous ne gérez pas l’enregistrement, remettez au propriétaire les noms d’hôte et le libellé de la clé, sans aucune valeur secrète. Le retour arrière restaure la liste précédente du seul enregistrement de recette concerné.
- Identifier l’hôte du document qui contient réellement le formulaire.
- Vérifier le périmètre autorisé de la paire de recette à partir d’un relevé expurgé.
- Préserver la validation de domaine et consigner la différence expliquée.
Approche 2 — Vérifier que la clé de site et le secret forment la même paire
Sur la copie, ouvrez Contact → Intégration et repérez la carte reCAPTCHA. Identifiez l’origine de la clé de site et celle du secret à l’aide des références de l’inventaire. La clé de site est transmise au navigateur par l’intégration. Le secret est utilisé par le serveur. Vérifiez que les deux se rapportent au même enregistrement, à la même famille d’intégration et au bon environnement. Un collage depuis deux projets différents peut laisser une configuration renseignée qui échoue à la vérification.
Pour l’intégration native, suivez le modèle v3 fondé sur un score décrit par Contact Form 7. Les clés d’une intégration v2 à case ne conviennent pas à ce modèle. Avec Google Cloud, la documentation prévoit l’identifiant de la clé Web et le secret hérité associé pour les extensions qui utilisent siteverify. Une clé d’API Cloud, une identité de compte de service ou une valeur destinée à un autre produit ne joue pas le rôle de ce secret.
Si le projet a migré depuis reCAPTCHA Classic, retrouvez d’abord l’enregistrement migré et son identité dans le projet propriétaire. Google précise que siteverify reste utilisable après migration. La migration en elle-même ne démontre ni que le site doit changer de clés, ni qu’il a changé de domaine. Vérifiez la provenance du couple actuel avant de préparer un remplacement.
Dans l’interface du plugin, un indicateur de configuration signifie que des valeurs sont présentes. Il ne prouve pas que la paire fonctionne. Pour corriger une erreur identifiée, le gestionnaire autorisé prépare les deux références d’une seule paire de recette et remplace ensemble les deux paramètres si nécessaire. Dans le dossier de diagnostic, notez le projet, le type et le libellé avant et après. Gardez le point de retour dans le gestionnaire prévu, sans afficher de valeur réelle.
Approche 3 — Vérifier quelle configuration est réellement utilisée
Une modification dans Contact → Intégration peut rester sans effet si le site charge une paire globale. Dans CF7 6.2.4.1, le code lit les constantes WPCF7_RECAPTCHA_SITEKEY et WPCF7_RECAPTCHA_SECRET lorsqu’elles sont définies, puis applique les filtres wpcf7_recaptcha_sitekey et wpcf7_recaptcha_secret. Les deux valeurs globales effectives doivent être renseignées pour prendre la priorité sur la paire enregistrée. Avec une seule valeur globale, CF7 utilise la paire enregistrée si elle est disponible. Vérifiez la version installée et faites relever la source de chaque valeur et le libellé de l’environnement, sans les afficher.
Commencez par le code et la configuration gérés de la recette. Demandez si une valeur provient d’un fichier de configuration, d’une extension indispensable ou d’un mécanisme propre à l’hébergeur. Si une surcharge est volontaire, la correction appartient à sa source gérée. Si deux sources se contredisent, évitez de corriger à la fois le code et la fiche de l’extension. Conservez un seul changement à la fois et un point de retour adapté à cette source.
Dans un relevé HTML ou réseau déjà expurgé, repérez le script reCAPTCHA, le contexte qui le charge et le marqueur de clé de site retenu par votre équipe. Le code CF7 prépare notamment une adresse de script avec un paramètre render. Une ancienne page conservée dans le cache ou un autre plugin peuvent fournir un autre script. Une clé publique différente dans le navigateur peut ainsi venir d’une autre page ou d’un autre composant. Une clé correcte dans le navigateur ne démontre pas quel secret le serveur utilise.
Si la configuration de recette a été corrigée mais que le relevé reste ancien, comparez une copie du HTML avant et après et examinez le cache de page de cette recette. En cas de purge utile, limitez-la à la copie et au périmètre identifié. Vérifiez que le chemin de chargement correspond à la version et à la configuration voulues, avec les sorties distantes toujours bloquées durant ce contrôle.
Lire les codes de vérification déjà disponibles
Si un relevé historique contient une réponse de siteverify, cherchez success, error-codes, hostname et, lorsqu’il figure dans le résultat v3, score. Si ce dernier champ manque, inscrivez « score absent ». Une valeur affichée par le journal CF7 peut provenir de son calcul de repli. Vérifiez que le relevé correspond au même environnement et à la même tentative. Le statut HTTP, la réponse JSON du service et le résultat du formulaire décrivent trois étapes distinctes.
Les codes missing-input-secret et invalid-input-secret orientent vers l’absence ou l’invalidité du secret présenté. Ils ne prouvent pas à eux seuls quelle paire aurait dû être utilisée. Les codes relatifs à la réponse, comme missing-input-response et invalid-input-response, invitent à examiner le jeton ou son absence. timeout-or-duplicate est compatible avec un jeton expiré ou déjà utilisé. Google indique que les jetons du parcours classique ont une durée limitée et un usage unique. Rejouer une requête archivée brouillerait la preuve.
Si la vérification historique indique un hôte différent de celui attendu, comparez la page ou l’iframe et le domaine de l’enregistrement. Si les traces montrent seulement un échec réseau sortant, cherchez la couche qui a refusé l’appel. Ne concluez pas que le secret est faux parce qu’une recette sans accès Internet ne peut pas joindre Google. Dans ce scénario, la validation distante est hors du périmètre.
Évitez d’activer un journal détaillé du corps des appels pour obtenir ces codes. Le code du plugin passe le secret et le jeton dans l’appel serveur. Un relevé réutilisable se limite au statut HTTP, aux champs utiles de la réponse, à l’heure et au libellé de la paire. Les valeurs réelles et les archives réseau restent hors de la fiche de diagnostic.
Vérifier la correction par une soumission de recette
Terminez d’abord le rapprochement de configuration. L’hôte final doit être couvert par la paire de recette avec validation de domaine active ; la clé de site et le secret doivent appartenir au même enregistrement v3 ; leur source effective doit correspondre aux réglages attendus. Le contrôle du navigateur seul ne démontre pas le secret utilisé par le serveur. Conservez ces repères avant l’essai pour savoir ce que la correction a changé.
Sur la recette autorisée, gardez les traitements annexes isolés et le courrier dirigé vers le collecteur local. Activez uniquement les accès Google nécessaires au chargement du script et à sa vérification serveur. Ouvrez la page dans un profil distinct et suivez le mécanisme de consentement prévu. Avec l’intégration native v3, aucun défi à résoudre n’est normalement affiché. Si une case ou un autre défi apparaît, identifiez le composant qui le charge avant d’attribuer son résultat à cette intégration.
Remplissez les champs avec des données fictives et cliquez une seule fois. Relevez l’heure, le POST feedback, le résultat applicatif et le message visible. Dans les diagnostics expurgés autorisés de la même tentative, recherchez le résultat de vérification, hostname et le score numérique lorsqu’il est fourni. Gardez secret, jeton et corps de formulaire hors du rapport. Ne mettez pas en place un journal global des requêtes pour obtenir ces informations. Sans trace suffisante, notez le résultat CF7 observé et la limite d’attribution, au lieu d’affirmer que la validation distante a réussi.
Le témoin positif doit emprunter la configuration corrigée, cesser de montrer l’erreur de domaine ou de type de clé et produire un résultat cohérent. Une réponse mail_sent accompagnée du message attendu dans le collecteur confirme le parcours jusqu’au transport de recette. Avec skip_mail, elle ne démontre que le scénario simulé : utilisez le transport capturé pour vérifier aussi la remise du courrier. Un verdict spam peut subsister à cause du score ou d’un autre filtre. Dans ce cas, lisez le motif et la réponse disponibles ; ne baissez pas le seuil pour forcer un succès.
Faites ensuite une tentative neuve avec un champ requis volontairement vide. Elle doit afficher une erreur compréhensible et ne produire aucun courrier capturé. Ce témoin vérifie la validation des champs, pas l’efficacité antispam de Google. Revenez à un jeu complet pour confirmer le parcours positif. Les résultats de recette ne mesurent pas la réputation ni les faux positifs du trafic public ; la réparation de configuration et la qualité du filtrage restent deux conclusions distinctes.
- Confirmer la paire dédiée, l’hôte final et la source effective des valeurs, sans révéler le secret.
- Vérifier le collecteur local et l’isolement des autres intégrations avant d’autoriser le parcours Google de recette.
- Soumettre une nouvelle entrée synthétique complète ; corréler le POST, le résultat CF7 et les diagnostics disponibles.
- Contrôler le courrier capturé si le scénario inclut son transport, puis effectuer un témoin de champ invalide et un dernier témoin complet.
- Noter les observations et leurs limites, restaurer les paramètres temporaires et nettoyer les messages de test.
Remettre une correction ciblée et son point de retour
Indiquez pour chaque écart le domaine attendu, le domaine observé, le projet, le type de clé et la source du réglage. Ajoutez la cause retenue et la couche qui doit changer. Par exemple, une migration fictive peut avoir laissé la recette sur un hôte autorisé avec une paire de production dans un fichier géré. Dans ce cas, la correction concerne la source de la paire de recette et le périmètre de sa clé. Les détails secrets ne figurent pas dans la proposition.
Pour le retour arrière sur recette, restaurez la liste d’hôtes précédente ou remettez ensemble les deux paramètres antérieurs de la paire de recette à leur source d’origine. Comparez le relevé de configuration et le HTML attendu. Rétablissez le périmètre réseau antérieur, conservez le transport capturé et supprimez les données synthétiques. Si le périmètre d’un changement reste incertain, laissez ce changement à l’état de proposition avec les éléments nécessaires à son propriétaire.
Un changement appliqué au mauvais enregistrement pourrait toucher d’autres formulaires ou hôtes. Avant d’envisager une modification réelle, faites identifier les dépendances de la paire concernée. Un retour à une paire valide de recette ne demande pas de supprimer une clé. Google documente qu’une clé supprimée ne se récupère pas. La conservation des références antérieures facilite la comparaison et le retour arrière.
Le dossier de remise distingue les réglages rapprochés, les tentatives réellement effectuées, les réponses observées et les étapes non vérifiées. N’annoncez pas un fonctionnement de bout en bout à partir du seul inventaire des clés. Si le test de recette a eu lieu, indiquez le résultat obtenu et les différences qui subsistent avec la production, notamment le domaine, la paire, le réseau et le transport de courrier.
