Système de captcha pour le post invité

Darks commented

2020-07-17 23:12:10 +02:00

Owner

Y'en a pas. Du coup les bots peuvent se faire plaisir…

Darks added the

security

enhancement

labels 2020-07-19 21:45:49 +02:00

Darks commented

2020-08-06 11:22:58 +02:00

Author

Owner

Je viens de voir passer un post qui parle d'utiliser un honeypot pour éviter les spams. Leur implémentation est en Flask, disponible sur Github.

Je connaissais l'astuce, à priori ça marche pas mal. Leur code est foireux je trouve, mais avec un validateur custom on peut s'en sortir beaucoup plus facilement.

En tout cas ça peut faire une première protection anti-spam, et si ça marche pas on fera un captcha.

Je viens de voir passer un post qui parle d'utiliser un honeypot pour éviter les spams. Leur implémentation est en Flask, disponible [sur Github](https://github.com/entrepreneur-interet-general/CIS-front/pull/213/files#diff-8d2cd30f51390d50482a562c379fba80R389). Je connaissais l'astuce, à priori ça marche pas mal. Leur code est foireux je trouve, mais avec un validateur custom on peut s'en sortir beaucoup plus facilement. En tout cas ça peut faire une première protection anti-spam, et si ça marche pas on fera un captcha.

Lephenixnoir commented

2021-07-10 09:45:32 +02:00

Owner

Je m'occupe de ça. J'aime bien le principe puisque ça ne gêne pas les utilisateurs humains, je pense que c'est un bon plan.

(Ça n'empêche pas quelqu'un qui programme un bot spécifique pour le site de poser des problèmes. Mais comme on un pseudo-Captcha maison très faible sur la v43, on a déjà ce problème-là et quand même peu de spam ; donc je ne crois pas que ce soit très gênant.)

Un validateur personnalisé ne serait pas du honeypot parce que ça renverrait une erreur durant la soumission par un bot (et attirerait donc l'attention du spammeur). Je pense qu'il faudra donc quand même une ligne de code à chaque utilisation du champ après validation.

Quelque chose que j'ai bien aimé en cherchant des détails sur cette méthode, c'est une partie de cette réponse StackOverflow :

Bots like (really like) saucy input elements like:
<input 
    type="text"
    name="email"
    id="email"
    placeholder="Your email"
    autocomplete="nope"
    tabindex="-1">
They wll be happy to enter some value such as dsaZusil@kddGDHsj.com

Comme on ne demande pas l'email des invités je pense que je vais mettre exactement ça en me débrouillant pour que le champ soit invisible mais pas d'une façon trop évidente (pour emmerder les bots triviaux qui n'utilisent pas un navigateur headless).

Je m'occupe de ça. J'aime bien le principe puisque ça ne gêne pas les utilisateurs humains, je pense que c'est un bon plan. (Ça n'empêche pas quelqu'un qui programme un bot spécifique pour le site de poser des problèmes. Mais comme on un pseudo-Captcha maison très faible sur la v43, on a déjà ce problème-là et quand même peu de spam ; donc je ne crois pas que ce soit très gênant.) Un validateur personnalisé ne serait pas du honeypot parce que ça renverrait une erreur durant la soumission par un bot (et attirerait donc l'attention du spammeur). Je pense qu'il faudra donc quand même une ligne de code à chaque utilisation du champ après validation. Quelque chose que j'ai bien aimé en cherchant des détails sur cette méthode, c'est une partie de [cette réponse StackOverflow](https://stackoverflow.com/a/34623588/4086712) : > Bots like (really like) saucy input elements like: > > ``` > <input > type="text" > name="email" > id="email" > placeholder="Your email" > autocomplete="nope" > tabindex="-1"> > ``` > > They wll be happy to enter some value such as `dsaZusil@kddGDHsj.com` Comme on ne demande pas l'email des invités je pense que je vais mettre exactement ça en me débrouillant pour que le champ soit invisible mais pas d'une façon trop évidente (pour emmerder les bots triviaux qui n'utilisent pas un navigateur headless).

Lephenixnoir self-assigned this 2021-07-10 09:45:36 +02:00

Lephenixnoir referenced this issue from a commit

2021-07-10 12:29:53 +02:00

forum: anti-bot fields for guest topics and comments (#51)

Lephenixnoir commented

2021-07-10 12:32:46 +02:00

Owner

En fin de compte j'ai réussi à m'en sortir à moindres frais.

Dans le formulaire :

from app.utils.antibot_field import AntibotField

class MyForm(FlaskForm):
    # ...
    ab = AntiBotField()

Dans le template :

{{ form.ab }}

Et tout le reste est identique.

Attention à ne pas donner de nom explicite genre antibot à la variable, puisque c'est utilisé comme nom de champ dans le HTML généré.

En interne c'est un EmailField qui demande "l'email" avec le type et le label qui vont bien. Si la champ est rempli durant une soumission le form.validate_on_submit() renvoie False et donc (en général, compte tenu de la façon dont on code nos routes) la page avec le formulaire est re-renvoyée.

En fin de compte j'ai réussi à m'en sortir à moindres frais. Dans le formulaire : ```py from app.utils.antibot_field import AntibotField class MyForm(FlaskForm): # ... ab = AntiBotField() ``` Dans le template : ``` {{ form.ab }} ``` Et tout le reste est identique. Attention à ne pas donner de nom explicite genre `antibot` à la variable, puisque c'est utilisé comme nom de champ dans le HTML généré. En interne c'est un `EmailField` qui demande "l'email" avec le type et le label qui vont bien. Si la champ est rempli durant une soumission le `form.validate_on_submit()` renvoie `False` et donc (en général, compte tenu de la façon dont on code nos routes) la page avec le formulaire est re-renvoyée.

Lephenixnoir closed this issue

2021-07-10 12:32:46 +02:00

Eragon commented

2021-10-02 10:54:57 +02:00

Member

Problème sur la prod.
Est-ce que vous avez testé le système ?
Actuelement le champ pour l'e-mail est affiché aux invités, si on le rempli on ne peut pas envoyer le formulaire avec une adresse mail "invalide" mais le post n'est pas pris en compte si y'a une adresse mail.

Il faut cacher le champ email aux utilisateurs.

Si l'utilisateur utilise la touche tab pour se déplacer il n'aura pas de problème mais on doit cacher le champ pour tous ceux qui n'utilisent pas la navigation au clavier (et pour les téléphones)

Problème sur la prod. Est-ce que vous avez testé le système ? Actuelement le champ pour l'e-mail est affiché aux invités, si on le rempli on ne peut pas envoyer le formulaire avec une adresse mail "invalide" mais le post n'est pas pris en compte si y'a une adresse mail. Il faut cacher le champ email aux utilisateurs. Si l'utilisateur utilise la touche tab pour se déplacer il n'aura pas de problème mais on doit cacher le champ pour tous ceux qui n'utilisent pas la navigation au clavier (et pour les téléphones)

Eragon reopened this issue

2021-10-02 10:54:57 +02:00

Lephenixnoir referenced this issue from a commit

2021-10-03 17:34:42 +02:00

forum: fix antibot field being visible (#51)

Lephenixnoir commented

2021-10-03 17:36:16 +02:00

Owner

Ça devrait être bon. La règle CSS qui cache le champ était ignorée au profit d'une règle plus spécifique. Le commitc ci-dessus modifie la règle pour rétablir la priorité.

Le champ étant display: none, peu importe la méthode de navigation il doit être impossible de le focus de façon conventionnelle.

Ça devrait être bon. La règle CSS qui cache le champ était ignorée au profit d'une règle plus spécifique. Le commitc ci-dessus modifie la règle pour rétablir la priorité. Le champ étant `display: none`, peu importe la méthode de navigation il doit être impossible de le focus de façon conventionnelle.

Eragon commented

2021-10-04 19:43:20 +02:00

Member

Je confirme ça marche.

Lephenixnoir closed this issue

2021-10-22 16:53:31 +02:00

Système de captcha pour le post invité #51