Closed DavidBruant closed 5 years ago
Une mitigation possible, c'est de mettre en place une limitation de soumission par adresse IP. Mais avant, il faudrait vérifier si tous les messages ont été soumis depuis la même IP.
@JulienParis est-ce qu'on a ces infos dans les logs ou quelque part ?
Une autre solution possible, c'est de mettre un captcha pour les utilisateurs non-connectés genre recaptcha
Ou mettre en place un système de validation d'email
Après un petit tour sur le slack de l'incubateur BetaGouv, voici les idées de solutions possibles :
Avantages, inconvénients et discussion de chaque option
Cette technique a l'avantage de décaler le problème du spam de formulaire au spam d'email Le spam d'email est un problème générique connu pour lequel il existe beaucoup de solutions
Un autre avantage, c'est que la gestion des contacts a lieu via des logiciels de gestion d'emails qui sont légions, plutôt que l'interface d'admin qui risque de demander un effort croissant de développement
On peut garder un formulaire que l'on peut utiliser en JavaScript pour pré-peupler le titre et le corps de l'email, ce qui peut simplifier la gestion et le tri des messages par type
On peut aussi créer différentes adresses emails (contact@
, structure@
, porteurs-projet@
, etc.) pour les messages qui nécessitent des traitements différents
Cette solution propriétaire est fournie par Google. Il n'est pas encore claire ce qui passe par les serveurs de Google, si c'est RGPD-friendly et si le consentement est un vrai consentement.
Côté service publique français, ça va à l'encontre d'objectif de souveraineté numérique
... et suppression de la sémantique des champs
Assez facile à implémenter, un peu de perte de fonctionnalité/accessibilité
Ne garantit pas vraiment que le spam va arrêter, il peut reprendre à tout moment
Une solution équivalente est de gérer la création du formulaire en JavaScript, mais pareil, ça ne marche que jusqu'à ce que les spammers utilisent un navigateur headless qui attend que le JavaScript s'éxecute
Solution assez facile à mettre en place dont l'efficacité a l'air démontrée\ Préserver la sémantique des champs
Les spameurs peuvent passer outre cette protection avec un navigateur headless intelligent (qui détecte si le champ est bien affiché avant de le remplir)\ La barre est tout de même plus haute qu'avec la solutions précédente
dans la catégorie reCaptcha ya aussi les libs python existantes pour en créer à la volée ...
Sinon de manière générale je serai pour garder des formulaires demandant un email aux utilisateurs... L'idée est que ApiViz soit auto-suffisant, sans qu'on ait à se former en plus à un logiciel de gestion d'emails côté admin (néanmoins on peut toujours tester la solution du "mailto" un moment) . Il faut de toute manière penser qu'on va garder un backoffice quoi qu'il en soit, car l'optique c'est bien de viser APIVIZ == CMS... L'idée de "Rajouter un champ vu seulement par les robots" paraît très bien, pe même à coupler avec un recaptcha maison ....
Retour d'expérience de la vie réelle sur la startup d'Etat Pix à propos des captchas :
on rencontre beaucoup de gens qui sont freiné dans le process d’inscription par le captcha :
- pour les élèves / étudiants : quand Pix est introduit en classe, tout le monde tape sur la même IP et donc Google impose rapidement la sélection d’image à toute la classe / collège / établissement scolaire
- pour les grands débutants : ils ne comprennent pas ce qu’ils doivent faire, ou pire ils ont très peur du mot “robot” ! “Comment ça ? Je ne suis pas un robot moi ! c’est quoi ce truc de pirate / big brother ?!”
Discussion prévue avec les parties-prenantes le mardi 18 décembre 2018 pour décider de la solution adoptée
solution retenue pour le moment donc : "Rajouter un champ vu seulement par les robots"
La discussion a eu lieu et nous avons décidé de Rajouter un champ vu seulement par les robots
Reçu aujourd'hui :