Une case en façade. Plusieurs vérifications derrière.

La version courte

Gaitcha est un captcha comportemental auto-hébergé. Le client JavaScript collecte un petit journal d’interactions. Le serveur PHP valide un jeton signé et évalue ce journal. Une preuve de travail optionnelle impose un calcul avant l’émission du jeton.

Aucune API de captcha externe ne prend la décision. La bibliothèque est indépendante du framework ; Gaitcha for WordPress apporte les intégrations au CMS et aux constructeurs de formulaires.

Du geste à la décision

1. Un emplacement apparaît. Il réserve la place du widget sans exposer de jeton ni de nom de champ aléatoire.
2. Une interaction lance l’initialisation. Souris, tactile, focus ou clavier déclenchent la requête vers le serveur du site.
3. La preuve de travail est calculée, si activée. Un Web Worker résout un challenge SHA-256 signé. Un calcul par tranches sur le thread principal prend le relais si le worker ne peut pas fonctionner.
4. Le serveur émet les données du widget. Elles contiennent un nom de champ aléatoire et un jeton HMAC signé, avec une expiration.
5. Le visiteur coche la case. Le journal est figé et sérialisé, y compris pour les formulaires AJAX.
6. Le serveur valide l’envoi. Le contrôle du jeton et le score comportemental déterminent l’acceptation. La coche visuelle n’est pas un verdict serveur.

Trois profils d’interaction

Souris : changements de trajectoire, variation de vitesse, inversions de direction, ralentissement et décalage du clic. Des contrôles examinent aussi les événements qui ressemblent à une simulation.

Clavier : navigation par tabulation, délai entre focus et activation, durée d’appui et variation du timing. Teste le vrai parcours clavier de ton intégration.

Tactile : mouvement, décalage du toucher et, si l’appareil les expose, variation de pression et de rayon de contact.

Le profil principal dépend de l’événement de validation. Un profil secondaire peut aussi être évalué s’il contient des données exploitables. Certains signaux incohérents provoquent un rejet immédiat.

Pourquoi une preuve de travail ?

La preuve de travail demande au client de résoudre un challenge signé avant d’obtenir un jeton. Cela ajoute un coût de calcul aux requêtes automatisées répétées. Le client JavaScript fourni s’occupe du calcul en arrière-plan.

La difficulté par défaut est de 18 bits. Le temps de résolution dépend du navigateur et de l’appareil. Teste les appareils lents avant d’augmenter la difficulté.

Associe la preuve de travail à l’anti-rejeu et à un stockage de jetons. Sinon, une solution reste réutilisable jusqu’à l’expiration du challenge.

Les réglages qui comptent

Les jetons durent 120 secondes par défaut, et le seuil de score vaut 0,5. Le client peut renouveler les jetons. Le cache ne doit jamais partager une réponse d’initialisation entre visiteurs.

Limites et accessibilité

Les données d’interaction côté client peuvent être fabriquées : une automatisation conçue pour Gaitcha peut donc passer la vérification. La preuve de travail ajoute un coût de calcul ; elle ne prouve pas que le visiteur est humain. Utilise Gaitcha avec une limitation de débit et la validation habituelle de ton application.

Avant la mise en ligne, teste tes formulaires au clavier, sur mobile et avec les technologies d’assistance. Prévois une nouvelle tentative et un moyen de te contacter si la vérification échoue.

JavaScript est nécessaire par défaut. no_js_fallback: 'allow' accepte les soumissions sans jeton, y compris automatisées. Garde 'reject' si chaque envoi doit passer la vérification.

Consulte le guide PHP, les explications sur la confidentialité et le code du core.