Protection anti-spam pour WPForms et Forminator sans captcha
Une protection anti-spam pour WPForms et Forminator sans captcha signifie que le site vérifie qu’un vrai navigateur a affiché et envoyé le formulaire, au lieu de demander à l’expéditeur de le prouver. ReportedIP Hive fait exactement cela pour les deux plugins : l’envoi d’un bot est refusé comme une erreur propre au formulaire, au-dessus du formulaire, aucune entrée n’est écrite, aucun e-mail ne part, et un vrai expéditeur ne voit jamais d’énigme, d’image ni d’étape supplémentaire.
Les deux adaptateurs font partie de la formule Business et s’activent avec un commutateur chacun sur la page Protection, sous Protection des formulaires. WPForms est arrivé avec Hive 2.1.65, Forminator avec la 2.1.66 ; ils sont testés contre WPForms Lite 2.0 et Forminator 1.57.
Pourquoi un captcha est le mauvais outil pour un formulaire de contact
Un captcha fait travailler la mauvaise personne. L’expéditeur, qui veut vous joindre, lit des lettres déformées ou clique sur des feux de circulation ; le script qui inonde le formulaire n’allait de toute façon jamais le résoudre et passe à un site avec un captcha plus faible. Chaque tentative ratée vous coûte un message, et vous ne saurez jamais combien ont abandonné.
Les bots forment deux groupes, et un formulaire doit gérer les deux. Le premier remplit chaque champ qu’il trouve, y compris celui qu’il devrait sauter. Le second ne charge jamais la page : il poste directement sur l’Endpoint avec une charge copiée d’un envoi réel. WPForms et Forminator livrent chacun un champ honeypot pour le premier groupe. Le second passe à côté d’un honeypot, parce qu’il n’affiche jamais le balisage qui le porte.
Comment la preuve d’exécution juge un envoi WPForms ou Forminator
Hive plante un champ d’ancrage invisible dans chaque formulaire des deux plugins, exclu de l’ordre de tabulation et des lecteurs d’écran. Un petit script ajoute un second champ dont le nom diffère sur chaque installation, si bien qu’une charge enregistrée sur un site ne convient à aucun autre. À l’envoi, le serveur relit les deux champs et classe la requête dans l’un des quatre verdicts :
| Verdict | Ce que contenait l’envoi | Ce qui se passe |
|---|---|---|
proved | Ancrage vide, champ de preuve présent | Un navigateur a affiché le formulaire et exécuté son script. L’entrée est enregistrée. |
tripped | Le champ d’ancrage, rempli | Refusé. Un champ invisible rempli est de l’automatisation sans explication innocente. L’adresse est bloquée et signalée dès la première tentative. |
failed | Ancrage vide, champ de preuve absent, le site sait qu’il affiche le champ | Refusé. La page a été récupérée, le script n’a jamais tourné. L’adresse n’est pas comptée. |
absent | Aucun des deux champs présent | Indulgent. Hive ne s’est pas encore vu afficher le champ sur ce site, rien n’est donc jugé. |
Rien de propre à la requête n’atteint le HTML. L’ancrage est le même à chaque chargement de page et le nom aléatoire vit dans le script, si bien qu’un cache de pages peut continuer à servir le formulaire aussi longtemps qu’il veut sans qu’un seul visiteur soit exclu. La règle derrière les quatre verdicts est une méthode partagée par chaque formulaire protégé, si bien que WPForms, Forminator, le formulaire de commentaire et l’inscription WordPress lisent la même preuve de la même façon.
WPForms : l’ancrage se place devant le bouton d’envoi
WPForms déclenche wpforms_display_submit_before à l’intérieur de l’élément form juste avant le bouton d’envoi, au chargement de la page comme sur le chemin en arrière-plan, et seulement quand le plugin affiche un de ses propres formulaires. Hive y écrit l’ancrage. Le message de confirmation est affiché ailleurs, si bien que l’ancrage ne se retrouve jamais à côté d’un texte de remerciement.
Le verdict est rendu sur wpforms_process, qui se déclenche après que le plugin a validé chaque champ et avant qu’il n’écrive une entrée ou n’envoie un e-mail. Un refus placé à ce moment dans la liste d’erreurs du processeur arrête les deux. WPForms affiche cette liste au-dessus du formulaire comme sa propre erreur d’en-tête, au rechargement de la page comme dans la réponse en arrière-plan, si bien que l’expéditeur lit toujours pourquoi rien n’a été envoyé. Les erreurs de champ viennent d’abord, par construction : le hook n’est pas atteint tant qu’un champ est invalide, si bien qu’un formulaire incomplet ne coûte aucune consultation.
Le côté navigateur n’a besoin d’aucun hook propre. WPForms valide sur l’événement submit du formulaire, celui que le script de Hive écoute déjà, si bien que le champ de preuve est rempli et que l’envoi retenu fonctionne sans changement. Une seule chose a dû être forcée : la feuille de style du plugin remet à zéro les éléments cachés, ce qui avait fait apparaître le leurre sur la page où un visiteur pouvait le remplir. La règle hors écran du champ leurre l’emporte désormais sur cette remise à zéro.
Forminator : l’ancrage dans le bloc d’envoi, le verdict dans la liste d’erreurs
Forminator construit le bloc qui porte son nonce et le bouton d’envoi via forminator_render_form_submit_markup, et ce bloc est toujours écrit à l’intérieur de l’élément form, au rendu de la page comme au rendu AJAX. Forminator y accroche son propre honeypot pour la même raison, et Hive y ajoute son ancrage. Le filtre plus large forminator_render_form_markup serait faux : son balisage dépasse la balise de fermeture du formulaire, si bien qu’un champ ajouté tomberait hors du formulaire.
Le verdict tombe sur forminator_custom_form_submit_errors, deuxième étape du gestionnaire d’envoi, avant la construction de l’objet entrée, avant son enregistrement et bien avant l’envoi de l’e-mail. Une liste d’erreurs non vide y arrête le gestionnaire, et Forminator répond avec la liste que l’expéditeur lit sur le formulaire. Rien n’est stocké, rien n’est envoyé, aucun module complémentaire ne tourne. Forminator associe chaque erreur à un identifiant de champ et affiche le message à côté de ce champ, si bien que le refus est rattaché au premier champ de l’envoi. Le hook se déclenche une seconde fois pendant le traitement des pièces jointes ; un refus déjà présent dans la liste n’est jamais ajouté deux fois.
Un formulaire chargé après la page est jugé comme un formulaire dans la page
Un formulaire Forminator peut être chargé dans la page après coup, et les deux plugins réaffichent un formulaire après une validation échouée. Le côté serveur est couvert parce que l’ancrage voyage dans le rendu propre du plugin, quel que soit le chemin qui l’a produit. Le côté navigateur est couvert au moment de l’envoi : le script de Hive agit sur l’événement submit, et si aucune réponse calculée n’est encore en réserve, il retient l’envoi au plus huit secondes le temps d’en récupérer une, puis expédie le formulaire exactement comme le visiteur l’a envoyé. Un visiteur qui clique avant le retour de la tâche n’est pas un bot, et un champ vide l’aurait refusé.
Pourquoi un envoi refusé est une erreur et non une entrée du dossier spam
Les deux plugins proposent un dossier spam. WPForms peut marquer une entrée comme spam, et le filtre anti-spam propre à Forminator dépose un envoi dans le dossier spam et, selon un réglage par formulaire, montre à l’expéditeur un message de réussite. Hive n’utilise ni l’un ni l’autre, volontairement. Une entrée dans un dossier spam est un message pour lequel l’expéditeur a été remercié et que l’exploitant ne lit jamais. Si le verdict était faux, la personne qui vous a écrit croit que son message est arrivé et attend une réponse qui ne vient jamais.
Un refus de Hive est au contraire l’erreur propre au formulaire : l’erreur d’en-tête que WPForms utilise pour son propre « form has not been submitted », la liste d’erreurs de champ que Forminator utilise pour un champ obligatoire laissé vide. L’expéditeur voit le message sur le formulaire, peut lire pourquoi, et peut réessayer. Aucune entrée n’est écrite, aucune notification ne part, et aucune confirmation n’est affichée. Ce plugin ne perd jamais un message sans au moins le dire à l’expéditeur.
Ce que voit un bot et ce que voit un visiteur
| Visiteur réel | Script qui poste sur l’Endpoint | Bot qui remplit chaque champ | |
|---|---|---|---|
| Charge la page | Oui | Non | Oui |
| Exécute le script | Oui | Non | En général non |
| Champ de preuve | Présent | Absent | Absent ou faux |
| Champ d’ancrage | Vide | Vide ou absent | Rempli |
| Étape supplémentaire pour l’humain | Aucune | ||
| Résultat | Entrée enregistrée | Refusé sur le formulaire | Refusé, adresse bloquée et signalée |
Ce que la vérification ne peut pas faire, c’est distinguer une personne d’un botnet qui pilote un vrai navigateur. Elle distingue un navigateur d’un script. Pour l’adresse derrière le navigateur, Hive exécute une seconde vérification indépendante : la vérification communautaire des menaces refuse un envoi venant d’une adresse à laquelle le site refuserait une connexion, au niveau de protection que la page de connexion applique, et l’expéditeur apprend pourquoi. Cette vérification a besoin du mode Community Network ; la preuve d’exécution fonctionne aussi en mode Local Shield, sans que rien ne quitte le site.
Ce qu’un leurre rempli coûte à l’adresse
Remplir un champ que personne ne peut voir demande une machine, alors Hive n’attend pas une deuxième et une troisième tentative avant d’agir. Un envoi avec un ancrage rempli va tout droit sur l’échelle de blocage et dans le signalement communautaire, comme le filtre de commentaires traite la même preuve depuis la 2.1.52 ; le signalement nomme le formulaire par lequel il est arrivé. Une adresse de votre liste blanche est exemptée, parce que la consultation se trouve dans le répartiteur où chaque capteur finit par arriver, pas dans le compteur qu’un capteur rapide saute.
Un visiteur dont le navigateur n’a simplement jamais exécuté le script n’est pas concerné. Son envoi est refusé avec un message qui en donne la raison, et son adresse n’est jamais comptée, parce qu’une preuve manquante n’est pas la preuve d’une machine.
L’activer en quatre étapes
- Mettez à jour vers Hive 2.1.66 ou plus récent avec une formule Business. Dans une formule inférieure, les commutateurs WPForms et Forminator restent visibles et verrouillés, avec la formule nécessaire écrite à côté.
- Activez le commutateur WPForms ou Forminator sur la page Protection, sous Protection des formulaires. L’activation vide les caches de pages courants, et pendant 24 heures un envoi qui n’a jamais porté la preuve est encore accepté, si bien qu’une page mise en cache sans le champ ne peut exclure personne. Le filtre
reportedip_hive_form_adapters_gracedonne plus de marge sur un site dont le cache vit plus d’une journée. - Lancez l’autotest sous Outils → Diagnostics. La carte liste ce qui est activé, puis effectue trois passages avec le navigateur devant lequel vous êtes assis : comme un visiteur, comme le même visiteur deux fois, et comme un bot. Aucun vrai formulaire n’est envoyé, aucun e-mail ne part et aucune entrée n’est stockée.
- Commencez éventuellement en mode signalement seul, qui journalise chaque verdict et ne refuse rien. Une semaine de journaux montre ce qui aurait été refusé avant que quoi que ce soit le soit.
La vérification par calcul, incluse à partir de Professional et donc dans Business, ferme le seul raccourci que le champ de preuve simple laisse ouvert : lire le nom du champ dans la page et le renvoyer. Le navigateur récupère une petite tâche auprès de votre propre site et la résout en arrière-plan ; la tâche est signée avec le sel du site, valable dix minutes et acceptée une seule fois, et l’expéditeur ne remarque toujours rien. Elle a besoin de HTTPS ; sans lui, la tâche garde sa signature, son expiration et son usage unique mais ne porte aucun calcul.
Quels plugins de formulaires reçoivent la même protection
| Formulaire | Formule | Testé contre |
|---|---|---|
| Formulaires de commentaire, d’inscription et de mot de passe oublié | Free | Cœur WordPress, WooCommerce, Multisite |
| Vos propres formulaires, via l’API de formulaires | Free | Trois appels : field, check, passes |
| Contact Form 7 | Chaque formule | La version publiée sur wordpress.org |
| WPForms et WPForms Lite | Business | WPForms Lite 2.0, chemin de chargement de page et chemin en arrière-plan |
| Forminator | Business | 1.57, formulaires dans la page et formulaires chargés après coup |
| Gravity Forms | Business | 3.1, y compris les formulaires multipages et envoyés en arrière-plan |
| Formidable Forms et Formidable Forms PRO | Business | 6.35 |
| Elementor Forms | Business | Elementor PRO 3.34, le widget de formulaire n’existe que là |
| Ultimate Member | Business | 2.13, formulaires de connexion, d’inscription et de mot de passe |
Chaque plugin a son propre commutateur. La couche entière, le commutateur principal, un second commutateur qui laisse de côté l’inscription et la réinitialisation du mot de passe, et le mode signalement seul sont réunis sur la page Protection. REPORTEDIP_HIVE_DISABLE_FORM_PROOF dans wp-config.php désactive la couche pour le cas où un visiteur ne peut pas envoyer et où vous avez besoin que le site fonctionne avant de déboguer.
Questions fréquentes
WPForms ou Forminator ont-ils encore besoin d’un captcha avec Hive activé ?
Pas contre les scripts et les bots. La preuve d’exécution attrape un envoi qui n’a jamais affiché le formulaire et un bot qui remplit le champ invisible, et la vérification communautaire des menaces refuse une adresse que le réseau connaît déjà. Un captcha n’y ajoute rien, sinon une étape que l’expéditeur doit franchir. Ce qu’aucun champ ne peut faire, c’est distinguer une personne d’un botnet qui pilote un vrai navigateur, et un captcha ne le peut pas non plus.
Fonctionne-t-il à côté d’Akismet, du jeton anti-spam de WPForms ou du honeypot de Forminator ?
Oui. Hive juge l’envoi sur le hook de traitement ou de validation propre au plugin, avant qu’une entrée n’existe. Un envoi refusé n’atteint jamais la liste des entrées, le dossier spam ni une autre vérification anti-spam. Tout ce qui passe poursuit vers les vérifications que vous exécutez déjà.
Que se passe-t-il pour un visiteur dont JavaScript est désactivé ?
Sur les plugins de formulaires, un envoi sans preuve est refusé avec un message qui en donne la raison, parce que sur un formulaire de contact il n’y a pas de file de modération sur laquelle se rabattre. L’adresse n’est ni comptée ni bloquée. Un site avec beaucoup de visiteurs de ce type peut faire tourner la couche en mode signalement seul, ou laisser les commutateurs WPForms et Forminator désactivés et garder les formulaires gratuits couverts.
La vérification ralentit-elle le formulaire ou casse-t-elle le cache de pages ?
Non. L’ancrage est identique à chaque chargement de page et rien de propre à la requête n’atteint le HTML, si bien qu’une page en cache reste valable. Le script remplit un champ au moment de l’envoi et mesure combien de temps le formulaire est resté à l’écran ; le point de départ vient du navigateur, jamais du balisage, si bien qu’une page en cache ne peut pas en porter un périmé. La tâche de calcul voyage dans un POST qu’aucun cache ne stocke.
Est-ce conforme au RGPD ?
La preuve ne collecte rien sur le visiteur au-delà de la présence de deux champs cachés à l’envoi et du nombre de secondes pendant lesquelles le formulaire est resté à l’écran. Pas d’empreinte numérique, pas de requête tierce, pas d’image servie depuis un autre domaine. En mode Local Shield, rien ne quitte le site. La documentation du plugin WordPress contient le résumé complet du traitement des données.
Lectures associées
- Gravity Forms sans captcha : l’adaptateur pour un plugin qui envoie ses formulaires lui-même
- Honeypot de formulaire et preuve d’exécution : les quatre verdicts et comment le formulaire de commentaire les note
- Notes de version de Hive 2.1.66 : la règle unique que tous les formulaires partagent désormais
Consultez la documentation du plugin WordPress pour la référence complète des réglages et la comparaison des formules pour ce que Business inclut. Découvrir ReportedIP Hive →