Je n'aime pas utiliser les systèmes de Protection de type Captcha
Existe-t-il une autre option Anti-Spam ?
Niveau :
Moyen
Version BF minimale requise :
BreezingForms Lite
Compatibilité Joomla! 4/5 :
✅
Situation
Il est normalement rare que les robots passent outre la protection Anti-Spam du service reCaptcha 2 classique ou invisible de Google, il semble efficace, mais on peut ne pas aimer ce type de protection ou simplement souhaiter le renforcer par une option supplémentaire.
En effet, même s'il protège généralement bien du pourriel, il est aussi assez intrusif et demande parfois l'intervention de l'utilisateur.
Remède
Le champ de formulaire caché, également nommé Honeypot et dont le contenu est testé avant l'envoi du formulaire, est une option intéressante.
Explication : Les robots en quête de formulaires à spammer ne passent pas le visiter depuis un navigateur classique, mais accèdent directement au code source de la page visitée. Le champ, masqué pour les utilisateurs classiques, n'est donc pas masqué pour ce robot qui le remplira d'un contenu. Il suffit alors d'en tester le contenu pour valider ou invalider le formulaire
➝ Le champ est renseigné, on invalide ➝ le champ reste vide, on en déduit que l'utilisateur est un humain, le formulaire sera validé.
Mise en œuvre
- Dans votre formulaire, ajouter un champ de texte. Il ne peut contenir de valeur par défaut dans ses options. Nommez-le et donnez-lui l'étiquette (label) Site Web p.ex.
- Rendez-vous dans les options avancées du formulaire, plus d'options, Onglet Envoyer des pièces → Début de soumission → Personnalisé.
- Saisissez le code suivant :
$this->execPieceByName('ff_InitLib'); if( ff_getSubmit('siteWeb') != '' ) // Teste si le champ nommé siteWeb est resté vide { exit; // sinon on sort du formulaire }
Dans cet exemple, nous testons la valeur du champ siteWeb dans une fonction d'inégalité (!=). Nous pouvons également tester une égalité à l'aide des caractères suivants (==).
Enregistrez ces modifications et sortez des options. Enregistrez votre formulaire et testez-le. Envoyez le formulaire rempli sauf ce champ. Ensuite, envoyez le formulaire en renseignant un contenu dans le champ siteWeb. Regardez la différence…
- Pour terminer, dans les options avancées de ce champ, cochez l'option "non visible en frontend" afin de masquer cet élément et publiez votre formulaire.
Certains robots seraient capables de vider les champs d'un formulaire avant de le ressaisir avec leurs propres informations. Si l'ajout de ce champ ne suffit pas, on peut en ajouter un second, en lui donnant une valeur par défaut dans ses propriétés (champ Valeur) dont on testera le contenu. S'il est différent, on invalide le formulaire.
Exemple :
$this->execPieceByName('ff_InitLib');
if( ff_getSubmit('City') != 'valeur' || ff_getSubmit('siteWeb') != '' )
{
exit;
}
Ci-dessus, nous testons si le champ 1 correspond bien à sa valeur par défaut et si le second champ est vide. Si l'un ou l'autre est invalidé, on sort du formulaire.
Remarque.
Cette méthode à elle seule n'est pas plus efficace qu'une autre de type (re)Captcha, elle peut bloquer un grand nombre de robots spammeurs, cependant, elle ne trompera jamais un spammeur humain qui verrait le formulaire comme n'importe quel visiteur de la page.
Bonjour,
Bravo pour ce site unique à l'attention de ceux qui affectionne BreezingForms !
Avez-vous des statistiques, à savoir, le nombre de pourriels qui ont passé durant une période donnée ?
En fait, on a du mal à se faire une idée sur l'efficacité de la chose, car les bots sont de plus en plus aguerris eux aussi.
Merci d'avance si vous avez un élément de réponse à me fournir.
Bien cordialement.
Bonjour GraphiqueDesign.
Merci pour ce compliment bien agréable.
Je n'ai malheureusement pas de statistiques à ce sujet.
Il faut savoir que cette protection n'est pas (ou plus) protectrice à 100% et qu'elle ne peut tromper qu'un robot, jamais un humain qui passerait son temps à rechercher des formulaires à remplir pour spammer puisqu'il verrait le formulaire comme tout autre utilisateur.
Cette solution est à utiliser en complément d'une ou plusieurs autres, de type filtrage d'IP p. ex.
Bonjour Eddy, une bonne méthode pour la plupart des formulaires, est d'empêcher la saisie d'url dans les champs texte, donc en empêchant "www", "http", "https" avec une alerte, car la plupart des spammeurs envoient des liens. Comment pourrais-je mettre cela en œuvre dans un formulaire BreezingForms ?
Merci ! (et désolée, vous m'avez répondu au sujet du champ Calendrier, je ne retrouve plus la page, je vous remercie donc ici pour votre réponse)
Kami,
Jetez un œil à ce post chez Crosstec.
C'est peut-être la solution recherchée.
Kami,
Pourtant, il s'agit d'une page publique chez Crosstec. 🙄
Vous pouvez télécharger le script de validation ici et l'installer dans votre BreezingForms, il suffit de l'appliquer en script de validation sur votre zone de texte.
Si vous souhaitez être plus stricte, le test PHP est plus sûr. Dans les options avancées, plus d'option, Envoyer des pièces, Début de soumission, insérer le bout de script suivant (si votre script contient déjà la première ligne, il est inutile de l'insérer une seconde fois) :
Pour le script php, y aurait-il moyen de l'étendre à tout champ ou zone de texte ?
merci !!
Kami,
Il ne s'agit pas d'un script de Crosstec mais bien de moi. 😉
Certains robots arrivent à passer les validations JavaScript pas celles écrites en php. Ne l'oubliez pas. 😉
Je vous souhaite une joyeuse fête de Pâques.
Kami,
Bien sûr. Voici un script qui teste les champs du message et de l'e-mail de l'utilisateur.
J'ai utilisé pendant de nombreuses années la méthode du script discuté ci-dessus comme ant-spam. Le résultat était très efficace alors que le recaptcha de Google laissait passer les spams.
Malheureusement depuis le build944, ce script entraîne un error 500 du serveur...
Est-ce que quelqu'un connaît une solution pour résoudre ce problème?
Merci d'avance
Bonjour.
J'utilise encore cette technique avec succès dans tout formulaire de contact.
Avez-vous bien mis la bibliothèque BreezingForms à jour après la mise à jour de composant et probablement suite au passage à PHP8+ comme décrit dans cet article ?