(Contact / #373) anti-spam: raison suspect distincte pour token absent vs token vide #381

Merged

mlvtito merged 1 commit from contact/absent-vs-empty-token into main

2026-11-15 12:06:00 +00:00

hermes_webmaster commented

2026-11-15 12:00:33 +00:00

Collaborator

Suite de #373 (triage de #378) : mesure de la frontière humain sans JS vs bot sans token.

Quoi

Aucun changement de comportement — l'issue continue d'être créée, flaguée [suspect] et labellisée dans tous les cas. Seule la raison de flag distingue désormais deux cas aujourd'hui confondus sous « missing token » :

champ token ABSENT du POST → token field absent (hand-crafted request: browsers always submit every form field, empty included). Un navigateur soumet toujours tous les champs nommés, vides compris : l'absence du champ ne peut pas venir d'un navigateur sur ce formulaire → signature de requête fabriquée à la main (bot aveugle) ;
champ présent mais vide → token empty (JS disabled/blocked, or bot mirroring the form). C'est le cas humain sans JS (ou bot parseur qui copie tous les champs du HTML) ;
le junk sans point reste malformed token.

Pourquoi seulement mesurer : l'objectif validé dans #373 est « ne jamais perdre un vrai message », donc tout est créé et flagué comme aujourd'hui. La distinction permettra de compter, sur les issues [suspect], le ratio réel bots-aveugles / humains-sans-JS — et de décider plus tard, en connaissance de cause, si le sous-cas « absent » peut passer en drop silencieux sans risque pour l'objectif.

Vérifié

php -l OK (PHP 8.5.8)
6 cas end-to-end sur serveur PHP local (endpoint factice qui capture le payload Forgejo) :
- token valide soumis en 0 s → [suspect] « submitted too fast (0s after page load) », labels [contact, spam]
- champ token absent → [suspect] « token field absent… », labels [contact, spam]
- token vide → [suspect] « token empty… », labels [contact, spam]
- token junk → [suspect] « malformed token », labels [contact, spam]
- honeypot rempli + token absent → les deux raisons cumulées
- humain légitime (token âgé de 7 s) → pas de flag, labels [contact] seulement
Tous les cas redirigent vers #contact-success ; payload Forgejo identique à avant (titre, corps, labels), seul le libellé de la raison change.

Suite de #373 (triage de #378) : mesure de la frontière **humain sans JS** vs **bot sans token**. ## Quoi **Aucun changement de comportement** — l'issue continue d'être créée, flaguée `[suspect]` et labellisée dans tous les cas. Seule la **raison de flag** distingue désormais deux cas aujourd'hui confondus sous « missing token » : - **champ `token` ABSENT** du POST → `token field absent (hand-crafted request: browsers always submit every form field, empty included)`. Un navigateur soumet toujours *tous* les champs nommés, vides compris : l'absence du champ ne peut pas venir d'un navigateur sur ce formulaire → signature de requête fabriquée à la main (bot aveugle) ; - **champ présent mais vide** → `token empty (JS disabled/blocked, or bot mirroring the form)`. C'est le cas humain sans JS (ou bot parseur qui copie tous les champs du HTML) ; - le junk sans point reste `malformed token`. Pourquoi seulement mesurer : l'objectif validé dans #373 est « ne jamais perdre un vrai message », donc tout est créé et flagué comme aujourd'hui. La distinction permettra de compter, sur les issues `[suspect]`, le ratio réel **bots-aveugles / humains-sans-JS** — et de décider plus tard, en connaissance de cause, si le sous-cas « absent » peut passer en drop silencieux sans risque pour l'objectif. ## Vérifié - `php -l` OK (PHP 8.5.8) - **6 cas end-to-end** sur serveur PHP local (endpoint factice qui capture le payload Forgejo) : - token valide soumis en 0 s → `[suspect]` « submitted too fast (0s after page load) », labels [contact, spam] - **champ token absent** → `[suspect]` « token field absent… », labels [contact, spam] - **token vide** → `[suspect]` « token empty… », labels [contact, spam] - token junk → `[suspect]` « malformed token », labels [contact, spam] - honeypot rempli + token absent → les deux raisons cumulées - humain légitime (token âgé de 7 s) → **pas de flag**, labels [contact] seulement - Tous les cas redirigent vers `#contact-success` ; payload Forgejo identique à avant (titre, corps, labels), seul le libellé de la raison change.

hermes_webmaster added 1 commit

2026-11-15 12:00:34 +00:00

(Contact / #373 ) anti-spam: distinct suspect reasons for absent vs empty token

/ build (push) Successful in 36s

Details

/ publish (push) Has been skipped

Details

b86161bd4f