Anti-spam, attribution et analyses

Un formulaire public est un point d'écriture public. Laissé ouvert, il collecte des soumissions de robots, et les soumissions utiles s'y noient. Deux petits blocs traitent cette classe de préoccupations : antiSpam tient le rebut à l'écart, et analytics décide si les soumissions du formulaire alimentent les analyses agrégées. L'attribution — qui a soumis — ne demande aucune configuration.

forms:
  - id: 1
    name: contact
    title: Contact Sales
    submitTo: { table: leads }
    antiSpam:
      honeypot: true
      rateLimit: { perIp: 5, perForm: 500, windowSeconds: 60 }
    analytics:
      enabled: false
    fields:
      - { kind: table-field, column: email, required: true }

Propriétés anti-spam

Toutes les propriétés sont optionnelles, et toutes les valeurs par défaut sont protectrices — un formulaire sans bloc antiSpam est déjà défendu.

Le pot de miel est une saisie masquée au nom conventionnel, portant tous les marqueurs qui en tiennent un humain à l'écart — aria-hidden, tabindex="-1", autocomplete="off", et aucune boîte visible. Une personne ne la voit ni ne l'atteint au clavier ; un robot naïf qui remplit chaque saisie du document la déclenche immédiatement.

À quoi ressemble un refus

Rien de précis n'est communiqué au client — un robot qui apprend pourquoi il a été refusé apprend comment passer. La raison est consignée sur la ligne de registre, là où un modérateur peut l'examiner. Une soumission marquée indésirable n'écrit jamais dans la table liée, ne déclenche jamais l'automatisation submitTo, et ne compte jamais dans availability.maxSubmissions.

L'IP du contributeur n'est stockée que sous forme d'empreinte SHA-256 salée. L'adresse brute n'est jamais persistée.

Attribution du contributeur

Lorsqu'une session est présente, le registre enregistre l'identifiant de l'utilisateur et la colonne « créé par » d'une table liée est renseignée. Voir Contrôle d'accès.

Il n'existe aucune option de configuration pour « une seule soumission par personne ». Pour l'imposer, placez une contrainte d'unicité sur la colonne de la table liée — la base de données est le seul endroit où une règle d'unicité ne peut pas être contournée par une course.

Désactivation des analyses

Par défaut, chaque soumission réussie alimente le flux d'analyses agrégées : c'est ce qui permet à la surface Réponses de l'administration de représenter les soumissions par jour et l'abandon par étape.

Passez-la à false sur les formulaires portant des données qui ne doivent pas apparaître dans des agrégats inter-soumissions — questionnaires de santé, coordonnées de paiement, tout ce qui est sous conservation légale. L'inspection soumission par soumission dans la console d'administration reste inchangée : la désactivation retire le formulaire de l'agrégat, pas de vos enregistrements.

L'agrégation est conditionnée à trois niveaux : un commutateur d'environnement côté opérateur, le bloc analytics de l'application, et ce drapeau par formulaire. Il suffit qu'un seul soit désactivé pour tenir un formulaire à l'écart.

Pages associées

• Disponibilité — le plafond de soumissions dont l'indésirable est exclu.
• Soumissions — le registre où le statut indésirable est consigné.
• Contrôle d'accès — les soumissions authentifiées et leur attribution.
• Analyses — le bloc applicatif sous lequel se range cette désactivation.