Protection anti-spam pour Gravity Forms sans captcha
Protéger Gravity Forms du spam sans captcha, c’est vérifier qu’un vrai navigateur a affiché et envoyé le formulaire, au lieu de demander au visiteur de le prouver. ReportedIP Hive le fait pour Gravity Forms avec un seul interrupteur : l’envoi d’un robot est refusé comme erreur de validation au-dessus du formulaire, aucune entrée n’est créée et aucune notification ne part.
Le fonctionnement du honeypot et de la preuve d’exécution est expliqué dans le guide du honeypot de formulaire. Cette page traite de ce qui est propre à Gravity Forms. L’interface de Hive est en anglais, les libellés cités restent donc en anglais.
Pourquoi Gravity Forms a besoin de plus que son propre honeypot
Gravity Forms possède son propre champ honeypot, qui arrête les robots remplissant chaque champ. Il n’arrête pas la seconde sorte de robot, celle qui ne charge jamais la page et envoie une charge copiée directement au site. Ce robot ne voit aucun champ caché et ne peut donc pas en remplir.
Un captcha l’arrêterait, mais il fait travailler la mauvaise personne : l’expéditeur qui veut vous joindre doit résoudre une énigme, tandis qu’une opération de spam déterminée paie un service de résolution. La preuve d’exécution de Hive ne demande rien à l’expéditeur. Elle vérifie que l’envoi vient d’un navigateur qui a chargé le formulaire et exécuté son script.
Ce qu’il advient d’un envoi Gravity Forms
| Envoi provenant de | Résultat |
|---|---|
| Un visiteur dans un navigateur normal | L’entrée est enregistrée, rien ne change pour l’expéditeur. |
| Un robot qui remplit le champ caché | Refusé. L’adresse est bloquée dès la première tentative et signalée en mode Community Network. |
| Un script qui envoie directement au site | Refusé au-dessus du formulaire. L’adresse est journalisée mais pas comptée pour un blocage. |
| Un navigateur sans JavaScript | Refusé avec un message demandant de l’activer. |
Le blocage après un champ caché rempli suppose que le blocage automatique est activé, et les adresses en liste blanche ne sont jamais bloquées. Dans l’Event Log sous ReportedIP Hive > Activity, un robot refusé apparaît comme « Form Spam (threshold reached) » avec la surface gravity_forms.
Pourquoi un envoi refusé est une erreur de validation et non une entrée de spam
Gravity Forms dispose d’un dossier spam, et Hive aurait pu y ranger les envois refusés. Il ne le fait volontairement pas. Une entrée dans le dossier spam est un message dont l’expéditeur a été remercié et que le destinataire ne lit jamais. Si le verdict était faux, la personne qui vous a écrit croit que son message est arrivé.
Hive utilise à la place une erreur de validation au niveau du formulaire, le même mécanisme que Gravity Forms emploie pour ses propres contrôles. L’expéditeur voit le message au-dessus du formulaire, peut en lire la raison et réessayer. Aucune entrée n’est enregistrée, aucun e-mail de notification ne part et aucune page de confirmation ne s’affiche. Ce que Hive refuse ne devient jamais une entrée.
Comment la vérification s’adapte au fonctionnement de Gravity Forms
Formulaires envoyés en arrière-plan
Gravity Forms envoie souvent ses formulaires lui-même, en arrière-plan, sans l’étape d’envoi habituelle du navigateur. Hive intervient au moment où Gravity Forms envoie les données, au même endroit que le captcha invisible de l’extension. Les formulaires en arrière-plan et ceux qui rechargent la page sont couverts de la même façon, et l’erreur s’affiche au-dessus du formulaire dans les deux cas.
Formulaires sur plusieurs pages
Un formulaire en plusieurs pages envoie chaque page comme une requête distincte. Seule la dernière page constitue l’envoi réel, c’est donc la seule vérifiée. Le passage d’une page à l’autre n’est jamais ralenti ni refusé.
Formulaires qui apparaissent plus tard
Un formulaire affiché une seconde fois, après une validation échouée ou dans une fenêtre surgissante, arrive après le chargement de la page. Hive écoute l’événement d’affichage de Gravity Forms et prépare à nouveau le formulaire, un visiteur qui corrige un champ n’est donc pas refusé.
Entrées via l’API de Gravity Forms
Les imports, les flux Zapier et les appels REST passant par l’API de Gravity Forms ne viennent pas d’un navigateur et ne portent donc aucune preuve. Hive les reconnaît et se tient à l’écart, les automatisations continuent donc de fonctionner. Sur les anciennes versions de Gravity Forms, ils sont traités comme le fait le honeypot de Gravity Forms.
L’activer en quatre étapes
- Vérifier la formule. L’adaptateur Gravity Forms fait partie de la formule Business. Dans une formule inférieure, l’interrupteur reste visible et verrouillé, avec la formule requise à côté.
- L’activer. Ouvrez ReportedIP Hive > Protection, carte Form Protection, et activez Protect Gravity Forms forms. Form execution proof doit rester activé lui aussi. Hive vide les caches de pages courants et accepte encore, pendant une période de transition, les envois provenant de pages mises en cache avant l’activation.
- Lancer l’autotest. Sous Tools > Diagnostics (visible en Expert mode), Run the self-test lance trois passages de test depuis votre propre navigateur : comme un visiteur, comme le même visiteur deux fois et comme un robot. Aucun vrai formulaire n’est envoyé et aucun e-mail ne part.
- Surveiller le journal. Les premiers jours, consultez l’Event Log pour repérer les envois refusés. Si vous voulez observer avant de refuser, activez d’abord Report-only mode dans la carte Blocking & Escalation.
À partir de la formule Professional, la Computation check on forms ajoute une petite tâche signée que le navigateur doit résoudre avant l’envoi, ce qui arrête aussi les scripts qui copient les noms de champs depuis la page. Avec Community threat check on forms en mode Community Network, Hive refuse en plus les envois d’adresses signalées par la communauté. Les deux sont expliqués dans le guide du honeypot de formulaire.
Questions sur Gravity Forms sans captcha
Gravity Forms a-t-il encore besoin d’un captcha avec Hive ?
Face aux scripts et aux robots, Gravity Forms n’a plus besoin de captcha une fois l’adaptateur Hive activé. La preuve d’exécution refuse tout ce qui ne vient pas d’un navigateur ayant affiché le formulaire. Elle ne distingue pas une personne d’un botnet qui pilote un vrai navigateur ; pour ce cas, la vérification communautaire examine l’adresse derrière.
Hive fonctionne-t-il avec Akismet et le honeypot de Gravity Forms ?
Hive fonctionne sans conflit avec Akismet et le honeypot de Gravity Forms. Il vérifie l’envoi pendant la validation, avant qu’une entrée n’existe : un envoi refusé par Hive ne devient donc jamais une entrée qu’une autre extension devrait trier. Les envois que Hive laisse passer sont traités comme avant par vos autres outils anti-spam.
Que se passe-t-il pour les visiteurs sans JavaScript ?
Un visiteur dont JavaScript est désactivé ne peut pas fournir la preuve : le formulaire est refusé avec un message l’invitant à activer JavaScript. Son adresse est journalisée mais jamais comptée pour un blocage. Si votre public navigue souvent sans JavaScript, utilisez le mode report-only ou laissez l’interrupteur Gravity Forms désactivé.
À lire ensuite
- Fonctionnement du honeypot de formulaire
- WPForms et Forminator sans captcha
- Les 16 capteurs d’attaque
La documentation de Hive détaille la détection des robots et le spam des formulaires ainsi que le cache et la compatibilité. La documentation de Gravity Forms décrit les réglages anti-spam propres à l’extension. Toutes les formules sont comparées sur la page des tarifs.