Project

General

Profile

Development #50108

ajouter un champ honeypot sur /accounts/register

Added by Thomas Noël 9 days ago. Updated about 4 hours ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
13 Jan 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

pour tenter de contrer les robots (bien idiots, mais qui existent)

L'idée est d'ajouter un champ vide, caché par CSS, et de vérifier que ce champ est bien vide lors du POST.


Files

Associated revisions

Revision 961403a6 (diff)
Added by Benjamin Dauvergne about 6 hours ago

use honeypot field to detect robots on registration form (#50108)

History

#4

Updated by Frédéric Péters 8 days ago

ce champ est bien vide lors du POST

Et quel comportement s'il n'est pas vide ?

Je serais instinctivement à dire qu'on passe malgré l'erreur mais que 1/ on ne fait pas l'envoi du mail d'inscription, 2/ sur la page suivante on met un texte d'explication adéquat. Cela dans l'idée 1/ de ne pas distinguer le comportement en réaffichant le formulare en erreur et inciter ainsi le bot à ressaisir une variation, et 2/ qu'il peut exister sur terre une extension qui coche automatiquement les cases de ce qui ressemble à des formulaires d'inscription et qu'il est alors sympa de prévenir l'usager.

#5

Updated by Thomas Noël 8 days ago

Frédéric Péters a écrit :

ce champ est bien vide lors du POST

Et quel comportement s'il n'est pas vide ?

Je serais instinctivement à dire qu'on passe malgré l'erreur mais que 1/ on ne fait pas l'envoi du mail d'inscription, 2/ sur la page suivante on met un texte d'explication adéquat. Cela dans l'idée 1/ de ne pas distinguer le comportement en réaffichant le formulare en erreur et inciter ainsi le bot à ressaisir une variation, et 2/ qu'il peut exister sur terre une extension qui coche automatiquement les cases de ce qui ressemble à des formulaires d'inscription et qu'il est alors sympa de prévenir l'usager.

Bonne idée. Cependant tout est dans le « texte d'explication adéquat ». Quelque chose comme ça :

« Votre demande d'inscription n'a pas êté prise en compte. En effet, votre navigateur a coché une case anti-robot cachée sur le formulaire d'inscription. Peut-être avez-vous installé une extension qui provoque ce comportement, dans ce cas veuillez tenter à nouveau en la désactivant. »

A noter que je me demande si un input vide n'est pas un meilleur piège qu'une case non cochée... je ne sais pas ; la sociologie des robots est une science récente. Et tiens pourquoi pas les deux.

#6

Updated by Thomas Noël 8 days ago

Autre truc : faire attention à l'accessibilité malgré tout, quoiqu'on a déjà testé l'affaire sur w.c.s. où personne ne nous a remonté de soucis jusqu'à présent, afaik.

#7

Updated by Benjamin Dauvergne 8 days ago

  • Assignee set to Benjamin Dauvergne
#8

Updated by Benjamin Dauvergne 8 days ago

#9

Updated by Frédéric Péters 8 days ago

A noter que je me demande si un input vide n'est pas un meilleur piège qu'une case non cochée... je ne sais pas ; la sociologie des robots est une science récente. Et tiens pourquoi pas les deux.

J'ai fait le test avec la case à cocher et ça a visiblement été bien suffisant. (à un point où je me disais que j'allais adopter quelque chose de similaire dans wcs, sur le formulaire de réenvoi du code de suivi, qu'on a apparemment vu utilisé).

Sur le code,

  <label style="display: none"><input type="checkbox" name="robotcheck" value="robotcheck"><span>Robot Check ?</span></label>

Je serais quand même pour mettre un message intelligible dans le <span>, façon "Vérification anti-robot, ne pas cocher".

Et pour le message affiché en cas d'erreur, je rejoins la proposition de Thomas et elle ne me semble pas gérable via django.contrib.messages (gras).

#11

Updated by Benjamin Dauvergne 8 days ago

J'ai ajouté la suppression du flag à chaque POST, que les gens ne se retrouvent pas coincés.

#12

Updated by Benjamin Dauvergne 8 days ago

Désolé pour les tergiversations, finalement avec un Form c'est beaucoup plus simple.

#14

Updated by Frédéric Péters 3 days ago

+this behaviour, in this case disable the extension and try agin.')))

again.

~~

Ça m'affiche le libellé du champ, cf capture.

~~

Et j'écrivais « Je serais instinctivement à dire qu'on passe malgré l'erreur (...) » et le patch non passe par ValidationError; le comportement des reobots face à ça n'a pas été regardé : ne rien faire, réessayer bêtement, réessayer sans cocher la case ? En trainant un peu des pieds je dirais ok mais intégrer l'info dans les logs pour pouvoir faire une analyse a posteriori ?

#15

Updated by Benjamin Dauvergne about 8 hours ago

  • correction du message
  • conservation du comportement normal avec redirection, le message set affiché ans registration_complete.html

PS: correction aussi du libellé qui s'affichait en ajoutant is_hidden = True

#16

Updated by Paul Marillonnet about 7 hours ago

  • Je trouverais plus clair de dire "has been refused" au lieu de "is refused" (on fait état a posteriori d’un résultat de traitement du formulaire).
  • typo s/an hidden/a hidden/
  • s/disable the extension/disable such extensions/ (on ne sait pas dire précisément à l’usager de quelle extension il s’agit alors mieux vaut ne pas semer le doute avec "the extension").
  • dans 0003 pourquoi avoir retiré des tests un assert pourtant utile ?
#17

Updated by Benjamin Dauvergne about 6 hours ago

Branche à jour pour répondre à tes commentaires.

#18

Updated by Paul Marillonnet about 6 hours ago

  • Status changed from Solution proposée to Solution validée

C’est bon pour moi.

#19

Updated by Benjamin Dauvergne about 6 hours ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 961403a666e91ab4f681dd64195875bbc5be047e
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Thu Jan 14 10:30:46 2021 +0100

    use honeypot field to detect robots on registration form (#50108)
#20

Updated by Frédéric Péters about 4 hours ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF