PrestaWard Captcha – GO ON Agency

Ce qu’il fait

Protège la connexion, l’inscription, les commandes, les contacts, la récupération de mot de passe, l’accès au Back Office, les newsletters, les commentaires et les notifications de disponibilité. Le mode Observation permet de vérifier le comportement réel avant d’activer tout blocage.

Lors de la commande, il sécurise la connexion et l’inscription du client qui ont lieu pendant l’achat. Il ne valide ni le paiement ni le bouton de confirmation de la commande.

Chaque formulaire dispose de son propre mode (Désactivé, Observation ou Protection) ; vous pouvez ainsi protéger l’accès au Back Office tout en vous limitant à l’observation du formulaire de contact.

Ce module couvre dix formulaires standard (connexion et inscription, y compris lors du processus d’achat ; contact ; récupération du mot de passe ; accès au Back Office ; newsletters ; commentaires sur les produits et notifications de disponibilité) et vous permet d’ajouter les formulaires propres à votre thème à l’aide d’un sélecteur CSS, sans modifier les modèles. Si Google ou Cloudflare cessent de répondre, ni vos clients ni votre équipe ne se retrouveront bloqués : tant que la panne dure, le module applique des vérifications locales validées sur le serveur.

Comment ça marche

Le module ne dispose pas de son propre CAPTCHA : il utilise Google reCAPTCHA (v2 ou v3) ou Cloudflare Turnstile. Vous pouvez choisir le fournisseur pour chaque surface et pour chaque boutique.
Il détecte les formulaires compatibles dans le navigateur, vous n’avez donc pas besoin de modifier les modèles. La vérification finale s’effectue sur le serveur : elle valide le domaine, l’action, la durée de validité et s’assure que le jeton n’a pas déjà été utilisé.
Il s’installe avec tous les formulaires en mode Désactivé. Chaque formulaire dispose de son propre mode dans chaque boutique : en mode Observation, il enregistre ce qui se serait passé sans bloquer personne ; en mode Protection, il bloque les envois sans vérification valide. Un formulaire ne peut passer en mode Protection qu’après avoir réussi l’autotest en mode Observation.
Les paramètres sont enregistrés par boutique. Pour télécharger le rapport d’assistance, vous devez sélectionner une boutique spécifique.
Si le serveur ne parvient pas à contacter Google ou Cloudflare à plusieurs reprises d’affilée, le module signale que la boutique est en état de dégradation et vous en informe par e-mail.
Solution de secours en cas de défaillance du fournisseur (formulaires clients et accès au Back Office en mode « Protection ») : ce n’est que lorsque le serveur lui-même confirme que le fournisseur est indisponible qu’est acceptée une transmission comportant un horodatage signé par la page, un champ piège vide, quelques secondes après le chargement de la page et un rythme de transmission normal. Chaque utilisation est enregistrée comme « fallback used » dans les statistiques. Cette fonctionnalité est activée par défaut et se désactive à l’aide d’un seul commutateur par boutique. Lors de l’accès au Back Office, elle exige les mêmes signaux vérifiés sur le serveur et ne constitue en aucun cas un moyen de contourner un fournisseur qui a bien répondu : un jeton refusé, ou un envoi sans jeton alors que le fournisseur fonctionne, est rejeté comme d’habitude. En cas de panne, cet accès est plus vulnérable face à un bot ciblé ; il est donc recommandé de maintenir un second facteur avec PrestaWard Authenticator.
Mode local par formulaire (bulletin d’information, contact et notifications de disponibilité) : le formulaire est protégé uniquement par des vérifications locales, avec un horodatage signé, un champ piège, un délai minimum d’envoi (4 secondes) et une limite d’envoi propre (de 1 à 50 toutes les 10 minutes). Il ne charge aucun script d’un fournisseur, n’en appelle aucun et n’a pas besoin de clés. Il conserve son propre mode (Désactivé, Observation ou Protection) et ne passe en mode Protection qu’après avoir réussi l’autotest en mode Observation. Il est moins résistant face aux bots ciblés qu’un fournisseur ; c’est pourquoi le tableau de bord le signale et ne le propose pas pour l’accès, l’inscription, les commandes, la récupération de mot de passe, le Back Office ni les commentaires sur les produits. Une page mise en cache intégralement depuis plus de six heures peut refuser l’envoi : il suffit de la recharger pour résoudre le problème.
Domaines de messagerie bloqués (inscription des clients, y compris lors de l’achat, et newsletter) : une liste que vous rédigez vous-même, à raison d’une règle par ligne, avec un domaine exact ou un caractère générique pour ses sous-domaines (jusqu’à 100 règles). Le domaine de messagerie est comparé à la liste avant de consulter le fournisseur et, en cas de correspondance, il est rejeté avec un message neutre qui ne révèle pas la liste. Dans la rubrique « Observation », seul ce qui aurait été rejeté est enregistré. Ni l’adresse e-mail du visiteur ni son domaine ne sont conservés ou enregistrés : uniquement un compteur et un événement sans données personnelles pour chaque rejet.
Score minimum de reCAPTCHA v3 par formulaire : chaque formulaire peut avoir son propre score, compris entre 0 et 1. Si vous laissez ce champ vide, le score global est utilisé ; rien ne change donc tant que vous n’avez pas défini de valeur. Un formulaire en mode « Protection » doté de son propre score doit voir ce dernier ajusté en mode « Observation » et l’autotest doit être répété avant de repasser en mode « Protection ».
Apparence du widget (onglet « Surfaces ») : thème (clair, foncé ou automatique) et taille (normale ou compacte) pour la case reCAPTCHA v2 et pour Cloudflare Turnstile, y compris dans l’accès au Back Office. Les valeurs par défaut conservent l’apparence actuelle.
Préfiltre sur le serveur (mode Protection) : les bots manifestes sont rejetés avant d’interroger le fournisseur, uniquement sur preuves positives : un champ piège renseigné, un horodatage falsifié, un envoi plus rapide que ce qu’une personne pourrait taper ou un nombre excessif d’envois par formulaire et par visiteur. Un horodatage manquant ou périmé n’est jamais considéré comme un indice. Cette fonctionnalité peut être désactivée par boutique.
Les nouvelles vérifications ne conservent aucune information permettant d’identifier le visiteur : les données sont regroupées dans un compartiment anonyme, créé à l’aide d’un hachage à clé qui change chaque jour, et qui n’existe que dans une table de compteurs purgée au bout de deux jours.
Protection contre les défaillances d’intégration (formulaires clients en mode Protection) : si un formulaire cesse de transmettre le jeton au serveur alors que le prestataire fonctionne (par exemple, suite à une mise à jour du thème, à un script JavaScript personnalisé ou à un problème de cache des pages), ce formulaire est simplement placé en « Observation temporaire » afin de ne pas refuser les clients, et vous recevez un incident signalé dans le module ainsi qu’un e-mail. Il revient automatiquement en mode Protection lorsque le problème disparaît et que les jetons sont correctement vérifiés. L’accès au Back Office n’est jamais affecté.
Les alertes par e-mail signalent les incidents opérationnels et les pics de trafic automatisé. Les destinataires et les seuils sont configurés par boutique.

Principales fonctionnalités

Mode spécifique à chaque formulaire et boutique : Désactivé, Observation ou Protection.
Tableau de bord des statistiques : envois autorisés et bloqués par formulaire et par jour (7, 14 ou 30 jours), tendance par rapport à la période précédente, utilisations de la sauvegarde, requêtes rejetées avant d’atteindre le fournisseur, nombre d’envois de chaque formulaire vérifiés en local et indicateur d’éventuels faux positifs. Dans la colonne « Observation », une ligne distincte indique le nombre d’envois qui auraient été bloqués. Elle ne contient ni adresses ni e-mails.
Formulaires personnalisés : un formulaire qui n’est pas reconnu automatiquement (commande sur une page, formulaires du thème) peut être attribué, par boutique, à une surface protégée à l’aide d’un sélecteur CSS (jusqu’à dix, facultativement limités à une seule page). Le tableau de bord avertit que la Protection n’est maintenue que si le formulaire envoie ses données vers une page vérifiée par le module.
Google reCAPTCHA v2/v3 et Cloudflare Turnstile, sélectionnables par surface et par boutique, avec un score minimum de reCAPTCHA v3 par formulaire.
Dix formulaires standard et des formulaires personnalisés sans modification des modèles.
Mode local via formulaire, sans clés ni scripts tiers, pour la newsletter, le formulaire de contact et les notifications de disponibilité.
Liste propre des domaines de messagerie bloqués pour l’inscription des clients et la newsletter, appliquée avant de consulter le fournisseur et sans enregistrer d’e-mails ni de domaines.
Solution de secours locale en cas de défaillance du fournisseur, y compris pour l’accès au Back Office, qui continue de rejeter tout ce que le fournisseur a lui-même rejeté.
Thème et taille du widget reCAPTCHA v2 et Cloudflare Turnstile.
Onglet « Surfaces » classé : tableau des formulaires regroupés, sélecteur affichant son texte complet et le bouton « Enregistrer » sur votre site, sans chevauchement avec la carte de pause temporaire.
E-mails de signalement d’incident comportant le logo de votre boutique dans l’en-tête et, en pied de page, le logo de GO ON Agency accompagné de la mention « PrestaWard by GO ON Agency ». Le corps du message présente le formulaire, la cause et le statut avec des textes traduits, et non des codes internes.
Aspect unifié du panneau dans les quatre modules PrestaWard : en-têtes de section, fiches de formulaire aux bordures neutres et blocs repliables communs, statistiques sur une seule ligne et un logo GO ON Agency plus grand dans l’en-tête. Le bouton principal adopte désormais une couleur unie conforme à l’identité visuelle de la marque, sans dégradé.
Panneau à onglets (Résumé, Surfaces, Fournisseur et Statistiques et enregistrement, plus un onglet Assistance, toujours le dernier) : seul l’onglet ouvert est pris en compte ; le Résumé présente l’état en un coup d’œil avec, au maximum, une ligne d’alerte ; et chaque onglet ne conserve que ses propres paramètres.
Validation du domaine, action, expiration et réutilisation du jeton.
Compatibilité avec les flux classiques et Symfony du Back Office.
Données techniques sans adresses e-mail, adresses IP, cookies ni jetons.
Durée de conservation des journaux configurable par boutique : 30 jours par défaut et comprise entre 1 et 365 jours. Le module supprime chaque jour les journaux périmés.
Identifiant du fournisseur chiffré au repos.
Integrity API et heartbeat intégrés. Sur l’écran du module, le bouton « Synchroniser » actualise la connexion avec Integrity.
Synchronisation avec Integrity à l’ouverture du panneau, via une requête en arrière-plan qui ne ralentit pas le chargement de la page, à raison d’au maximum une fois par minute et par boutique.
Panneau d’assistance de GO ON Agency proposant un rapport de diagnostic téléchargeable. Celui-ci est téléchargé par un employé disposant d’une autorisation de modification, après avoir sélectionné une boutique. Il inclut les versions, les états et les compteurs ; il ne contient aucune donnée client et n’est pas envoyé automatiquement.
Panneau de configuration et traductions en neuf langues.

Exigences

PrestaShop de la version 1.7.7 à la version 9, avec la version de PHP requise par votre version de PrestaShop.
Clés Google reCAPTCHA ou Cloudflare Turnstile pour chaque boutique sur laquelle vous activez la Protection. Celles-ci sont créées par le commerçant lui-même sur le compte du fournisseur. Les formulaires en mode local ne nécessitent pas de clés.
En mode Protection, le navigateur du visiteur doit pouvoir charger le script du fournisseur. S’il ne se charge pas, le formulaire n’est pas envoyé et le visiteur est invité à réessayer, sauf si le serveur confirme que le fournisseur n’est pas disponible et que la solution de secours locale est appliquée, ou si le formulaire utilise le mode local.

Ce qu’il ne fait pas

Il ne s’agit pas d’un CAPTCHA auto-hébergé : la vérification est effectuée par Google ou Cloudflare, selon leurs propres conditions de confidentialité. Le serveur leur envoie le jeton et l’adresse IP du visiteur afin de le vérifier.
Il ne bloque rien, ni en mode Désactivé, ni en mode Observation.
Le mode local ne remplace pas un hébergeur : il est moins efficace face aux bots ciblés ; il n’est proposé que pour la newsletter, le formulaire de contact et les notifications de disponibilité ; dans ces formulaires, la sauvegarde en cas de panne, la surveillance de l’intégration et le dispositif de sécurité du fournisseur ne s’appliquent pas, car il n’y a pas de fournisseur susceptible de tomber en panne.
Ne comprend pas de listes de domaines de messagerie ni d’adresses tierces : c’est à vous de rédiger et de gérer la liste des domaines bloqués, celle-ci ne se met pas à jour automatiquement.
Il ne protège pas le paiement, les autres formulaires ne figurant pas dans la liste (à l’exception de ceux que vous attribuez vous-même à l’aide d’un sélecteur CSS), ni l’API d’administration de PrestaShop.
Ce produit ne remplace pas un pare-feu d’applications web (WAF).
Le pied de page des e-mails du module ne contient ni liens, ni coordonnées, ni images hébergées en dehors de votre boutique : le logo de GO ON Agency est un fichier provenant du module lui-même et diffusé depuis votre boutique.
Il ne stocke pas de jetons, de secrets, de mots de passe, de cookies, d’adresses e-mail ni d’adresses IP dans ses journaux.

Compatibilité vérifiée

La version 0.2.7 a passé avec succès les tests en laboratoire sur PrestaShop 1.7, 8 et 9 le 15 octobre 2026, ainsi qu’avec la version finale : installation vierge et mise à jour depuis la version 0.2.6, et accès au Back Office via un navigateur réel sur les trois versions (fournisseur refusant la connexion, script bloqué et simulation de panne du fournisseur). Dans PrestaShop 9, un captcha rejeté affiche le message « Captcha » suivi de l’avertissement générique que PrestaShop ajoute systématiquement.

Les versions précédentes ont été testées sur PrestaShop 1.7.8.11 avec PHP 7.4, PrestaShop 8.2.7 avec PHP 8.1 et PrestaShop 9.1.4 avec PHP 8.5. La validation porte sur les formulaires du Front Office, la connexion au Back Office et l’ensemble du processus de notification de disponibilité via ps_emailalerts.

Utilisation sécurisée

L’installation ne déclenche aucun blocage. Configurez les clés du fournisseur, vérifiez les formulaires en mode Observation et passez en mode Protection uniquement lorsque le diagnostic est correct.

Journal des modifications

Ce journal des modifications résume, version par version, l’impact pour les boutiques et les équipes de commerce électronique.

0.2.7

Nouveau : mode local par formulaire. La newsletter, le formulaire de contact et les notifications de disponibilité peuvent être protégés uniquement par des contrôles locaux (horodatage signé, champ piège, délai minimum d’envoi de 4 secondes et limite d’envois), sans charger aucun script d’un fournisseur ni nécessiter de clés. Chaque formulaire conserve son mode (Désactivé, Observation ou Protection) et ne passe en mode Protection qu’après avoir réussi l’autotest en mode Observation. Ce mode est moins efficace contre les bots ciblés qu’un fournisseur et n’est jamais proposé pour l’accès, l’inscription, la commande, la récupération de mot de passe, le Back Office ni les commentaires. Les statistiques indiquent le nombre d’envois de chaque formulaire qui ont été vérifiés en local. Une page mise en cache intégralement depuis plus de six heures peut refuser l’envoi ; il suffit de la recharger pour résoudre le problème.
Nouveau : domaines de messagerie bloqués. Une liste que vous rédigez vous-même (une règle par ligne, un domaine exact ou un caractère générique pour ses sous-domaines, jusqu’à 100 règles) s’applique à l’inscription des clients, y compris lors de l’achat, ainsi qu’à la newsletter. La vérification s’effectue avant de consulter le fournisseur et un e-mail correspondant est rejeté avec un message neutre qui ne révèle pas la liste. Dans la rubrique « Observation », seul ce qui aurait été rejeté est enregistré. Ni l’e-mail ni son domaine ne sont conservés : uniquement un compteur et un événement sans données personnelles pour chaque rejet.
Nouveau : score minimum de reCAPTCHA v3 par formulaire. Si vous laissez ce champ vide, le score global est utilisé ; rien ne change donc tant que vous n’avez pas défini de valeur. Une valeur non valide rétablit le score global.
Nouveau : thème (clair, foncé ou automatique) et taille (normale ou compacte) du widget reCAPTCHA v2 et Cloudflare Turnstile, y compris dans l’accès au Back Office. Les valeurs par défaut conservent l’aspect actuel ; reCAPTCHA v3 et v2 invisible n’affichent pas de widget. Dans reCAPTCHA, l’option « automatique » suit la palette de couleurs du visiteur.
L’accès au Back Office utilise la même sauvegarde locale que les formulaires clients, uniquement lorsque le prestataire n’est pas disponible et que le serveur le confirme. Un prestataire ayant répondu « vérification échouée » continue d’être rejeté comme d’habitude. Chaque utilisation est enregistrée comme « fallback used » ; un commutateur par boutique le désactive et la suspension temporaire de l’opérateur est maintenue. L’écran d’accès ne reste jamais bloqué : le script signale l’échec au serveur, puis envoie le formulaire dans tous les cas. En cas de panne, cette protection est moins efficace face à un bot ciblé ; il est donc conseillé de conserver PrestaWard Authenticator comme deuxième barrière de sécurité. La protection contre les défaillances d’intégration n’affecte toujours pas le Back Office.
Le panneau est divisé en onglets (Résumé, Surfaces, Fournisseur et Statistiques et journal) et ne prend en compte que l’onglet ouvert. L’onglet « Résumé » affiche le statut de chaque fournisseur, les vérifications réussies et échouées des dernières 24 heures, le statut effectif de chaque formulaire et, au maximum, une ligne d’alerte renvoyant vers l’onglet où le problème est résolu. Chaque onglet dispose de son propre bouton « Enregistrer » et n’enregistre que les paramètres qu’il affiche. Le panneau d’assistance de GO ON Agency dispose de son propre onglet, « Assistance », toujours situé en dernier, et l’état d’Integrity apparaît à la fin de tous les onglets.
L’onglet « Surfaces » a été repensé : tableau de formulaires regroupé, sélecteur dont le texte n’est plus tronqué (il affichait auparavant « Desa ») et bouton « Enregistrer » situé en dehors de la carte de pause temporaire, sans la recouvrir. Le thème et la taille du widget se règlent dans une section de cet onglet.
Corrige le message « formulaires activés sans avoir réussi leur test » : il s’affichait avec six formulaires alors que tous étaient désactivés. Désormais, seuls les formulaires qui ne sont pas en mode « Désactivé » sont pris en compte.
Dans les nouvelles installations, les alertes par e-mail en cas d’incident sont désactivées jusqu’à ce que vous indiquiez une adresse, ce qui permet d’enregistrer la configuration dès le départ. Les installations mises à jour conservent leurs paramètres.
Les e-mails relatifs aux incidents (ouverts et résolus) affichent le logo de votre boutique dans l’en-tête (avec le nom de la boutique comme texte alternatif) et un pied de page commun comportant le logo de GO ON Agency et la signature « PrestaWard by GO ON Agency », sans aucun lien ni coordonnées. Le logo du pied de page est un fichier provenant du module lui-même et mis à disposition depuis votre boutique.
Corrige le fait que le corps de l’e-mail de signalement affichait des codes internes (par exemple «configuration_test» ou « opened ») : il indique désormais le formulaire, la cause et le statut avec des textes traduits dans les neuf langues.
Corrige un bug qui, en cas d’appel au fournisseur, bloquait un formulaire du Front Office ; les appels au fournisseur depuis le script de la boutique sont désormais protégés de la même manière que ceux effectués pour accéder au Back Office.
Aspect unifié du panneau dans les quatre modules PrestaWard : en-têtes de section, fiches de formulaire aux bordures neutres et blocs repliables communs, statistiques sur une seule ligne et un logo GO ON Agency plus grand dans l’en-tête. Le bouton principal adopte désormais une couleur unie conforme à l’identité visuelle de la marque, sans dégradé.
Corrige le fait que, dans PrestaShop 9, le thème d’administration affichait les onglets soulignés comme des liens et les titres de section en majuscules. Les styles communs neutralisent cet effet uniquement au sein du panneau PrestaWard ; ainsi, PrestaShop 1.7 et 8 s’affichent comme auparavant.
Corrige le fait que, dans PrestaShop 1.7, la feuille de style du module était ignorée lorsqu’elle était enregistrée avec le numéro de version dans l’adresse. Désormais, le fichier est vérifié et enregistré sans paramètres, de sorte que le nouveau thème s’affiche dans les versions 1.7, 8 et 9.
Corrige le fait que, dans PrestaShop 9, la synchronisation avec Integrity vérifiait le jeton de sécurité à l’aide d’une méthode que PrestaShop 9 n’utilise pas et qui pouvait entraîner un rejet. La validation s’effectue désormais via le service de PrestaShop 9 ; dans PrestaShop 1.7 et 8, la vérification reste inchangée.
Lorsque la connexion à Integrity ne peut pas être mise à jour pour le moment, le panneau affiche un seul message : la connexion enregistrée reste valide et une nouvelle tentative sera effectuée automatiquement. Les libellés de tous les onglets sont traduits dans les neuf langues.
Le mode local dispose de sa propre limite d’envoi (de 1 à 50 toutes les 10 minutes). La mise à jour copie la limite actuelle de la sauvegarde ; ainsi, rien ne change après la mise à jour, et la modification de l’une des deux limites n’affecte plus l’autre.
Corrige le fait que, dans PrestaShop 9, un captcha rejeté (par exemple, en raison d’une clé de site non valide dans la section « Protection ») n’affichait que le message générique de PrestaShop concernant l’employé ou le mot de passe. Le module affiche désormais son propre message dans toutes les versions ; PrestaShop 9 continue d’ajouter ensuite sa ligne générique.
Corrige le problème de dégradation de la connexion à Integrity dans le contexte « toutes les boutiques » du Back Office ou lorsqu’une boutique autre que la première servait de test d’inscription. L’identité de l’installation est désormais lue comme une entité unique à partir de la portée globale (ou de la boutique qui la stocke) dans n’importe quel contexte ; la mise à jour transfère vers la portée globale une identité stockée dans une boutique sans la régénérer et, si elle ne peut pas être lue, l’état d’Integrity reste inchangé.
L’en-tête du produit affiche à nouveau le logo de GO ON Agency et la mention « PrestaWard by GO ON Agency », sans liens.
Tant que vous utilisez un fournisseur, son jeton reste obligatoire, exactement comme auparavant. Les surfaces détectées, les paramètres enregistrés et le contrat avec l’API Integrity ne changent pas, et les nouvelles méthodes de rejet ou de validation d’un formulaire (mode local et domaines bloqués) sont désactivées par défaut. La mise à jour ne modifie aucune table : elle ajoute uniquement de nouveaux paramètres dont les valeurs préservent le comportement actuel.

0.2.6

Chaque formulaire dispose de son propre mode dans chaque boutique (Désactivé, Observation ou Protection), plutôt que d’un mode unique pour l’ensemble de la boutique avec des commutateurs. Vous pouvez ainsi protéger l’accès au Back Office et vous contenter d’observer le formulaire de contact. Un formulaire ne passe en mode Protection qu’après avoir réussi l’autotest en mode Observation, et la mise à jour conserve le comportement actuel de chaque boutique.
Protection en cas de défaillance du fournisseur (formulaires clients en mode Protection) : si le serveur confirme que reCAPTCHA ou Turnstile ne peuvent pas être utilisés, le formulaire n’est accepté que s’il comporte un horodatage signé, un champ piège invisible vide, quelques secondes écoulées depuis le chargement de la page et un rythme normal d’envoi. Chaque utilisation est enregistrée dans les statistiques. Cette fonctionnalité est activée par défaut, elle peut être désactivée par boutique et l’accès au Back Office ne l’utilise jamais.
Modification à prendre en compte : lorsque cette Protection est activée, un disjoncteur ouvert ne laisse plus passer toutes les expéditions, mais applique ces mêmes vérifications locales. Désactivez-la pour conserver le comportement précédent.
Préfiltre sur le serveur (mode Protection) : rejette les bots manifestes avant d’interroger le fournisseur, uniquement sur preuves positives (champ piège renseigné, horodatage falsifié, envoi plus rapide que ce qu’une personne pourrait taper ou plus de 30 envois par formulaire et par visiteur toutes les 10 minutes). Il peut être désactivé par boutique.
Les nouvelles vérifications ne conservent aucune donnée identifiable : les visiteurs sont regroupés dans un ensemble anonyme avec une clé qui change chaque jour, uniquement dans un compteur qui est vidé au bout de deux jours.
Nouveau tableau de bord des statistiques : envois autorisés et bloqués par formulaire et par jour (7, 14 ou 30 jours), tendance par rapport à la période précédente, activations de la Protection en cas de panne du fournisseur, requêtes rejetées avant d’atteindre le fournisseur, un indicateur de faux positifs potentiels et, en mode Observation, les envois qui auraient été bloqués. Il ne contient ni adresses ni e-mails.
Formulaires personnalisés : un formulaire qui n’est pas reconnu automatiquement (commande sur une seule page, formulaires du thème) peut être attribué, par boutique, à une surface protégée à l’aide d’un sélecteur CSS (jusqu’à dix). Le tableau de bord avertit que la Protection n’est effective que si le formulaire envoie ses données vers une page vérifiée par le module.
Garde-fou contre les défaillances d’intégration (formulaires clients en mode Protection) : si un formulaire cesse d’envoyer le jeton au serveur alors que le fournisseur fonctionne (en raison d’une mise à jour du thème, d’un code JavaScript propre ou du cache de la page), ce formulaire passe automatiquement en Observation temporaire et vous recevez un incident ainsi qu’un e-mail. Il revient en mode Protection après 15 minutes sans incident et trois jetons vérifiés. L’accès au Back Office n’est jamais affecté et les bots manifestes continuent d’être rejetés.
La mise à jour crée une petite table de compteur et de nouveaux paramètres avec des valeurs sûres, et conserve les paramètres et événements existants.
Le panneau d’assistance et de diagnostic est placé juste avant la section Integrity, comme dans les autres modules PrestaWard, et dans le contexte « toutes les boutiques », il ne disparaît plus : cela indique qu’il faut sélectionner une boutique.
Se synchronise avec Integrity à chaque ouverture du tableau de bord, via une requête en arrière-plan qui ne ralentit jamais le chargement de la page, à raison d’au maximum une fois par minute et par boutique.

0.2.5

Corrige le service de connexion au Back Office dans PrestaShop 1.7. Dans PrestaShop 9, la vérification se limite au formulaire de connexion du Back Office et n’affecte pas l’API d’administration.
Cesse de réessayer l’inscription à Integrity lorsque la clé d’enregistrement de la boutique change et affiche un message d’avertissement clair.
Renouvelle la politique Integrity signée avant son expiration et conserve la politique en vigueur en cas d’échec du renouvellement.
Corrige la clé de politique incluse afin qu’elle fonctionne sous PHP 7.1 et 7.2.
Ajoute le panneau d’assistance de GO ON Agency en neuf langues, avec un rapport de diagnostic téléchargeable qui ne contient pas de données clients et n’est pas envoyé automatiquement. Seul un employé disposant d’une autorisation de modification et ayant sélectionné une boutique peut le télécharger.
La durée de conservation des journaux techniques est désormais réellement appliquée (30 jours par défaut, configurable par boutique) : jusqu’à présent, ils étaient conservés indéfiniment. Chaque boutique supprime quotidiennement les journaux périmés, sans que cela n’affecte les incidents.
Déclare la compatibilité à partir de PrestaShop 1.7.7.0, la version la plus ancienne testée.

0.2.4

Corrige l’envoi du formulaire de connexion de l’administration via Turnstile après résolution du CAPTCHA, tout en conservant le bouton qui a déclenché l’envoi.
Corrige le test d’inscription dans PrestaShop 9 et améliore le diagnostic et les nouvelles tentatives d’Integrity.

0.2.3

Version non publiée, remplacée par la version 0.2.4.

0.2.2

Empêche les autres gestionnaires JavaScript du thème de lancer l’envoi tant que le CAPTCHA est encore en attente.
Élimine les états de chargement interminables et les requêtes effectuées avant de disposer d’un jeton valide.
Affiche le CAPTCHA à l’ouverture des formulaires de connexion ou d’inscription qui étaient masqués lors du chargement de la page.

0.2.1

Rétablit l’affichage du CAPTCHA avant la première tentative de connexion dans le Front Office et le Back Office.
Empêche le cache d’afficher un CAPTCHA obsolète ou incorrect après la mise à jour du module.
Remplace la fenêtre contextuelle par un avertissement accessible, visible et adapté aux appareils mobiles.
Maintient les échecs du Back Office sur leur page de connexion avec un seul message d’erreur, sans page blanche.

0.2.0

Ajoute Cloudflare Turnstile avec des identifiants chiffrés et une sélection indépendante par surface.
Associe chaque jeton à son action protégée et renouvelle le défi en cas d’envois répétés.
Améliore la détection des formulaires de connexion, d’inscription, de récupération de mot de passe, de commande, de newsletters et de notifications.
Intègre une suspension opérationnelle temporaire, limitée et auditée, sans assouplir la politique Integrity signée.
Mise à jour du panneau de configuration, de son design adaptatif et des traductions dans les neuf langues.
Renforce la persistance « fail-closed » de la dernière politique Integrity vérifiée.

0.1.2

Il distingue les pics de trafic automatisés des défaillances opérationnelles et évite les alertes en double.
Ferme automatiquement les incidents liés au trafic automatisé après une période d’inactivité.

0.1.1

Vérifications de disponibilité par surface avant de pouvoir activer la Protection.
État de fonctionnement, historique des incidents, filtres, pagination et nettoyage.
Télémétrie de santé ciblée et intégration avec le « heartbeat » d’Integrity.

0.1.0

Première version candidate publique.
Protection indépendante par surface et par boutique.
Intégration avec reCAPTCHA v2 et v3.
Inscription, politique signée et heartbeat de PrestaWard Integrity.
Vérification des mises à jour et expérience visuelle commune de l’écosystème.
Compatibilité multi-versions et catalogue complet en neuf langues.

Licence et assistance

PrestaWard Captcha est distribué sous la licence Academic Free License 3.0 (AFL-3.0). Vous pouvez l’utiliser, l’étudier, le modifier et le redistribuer conformément à ses conditions.

Assistance : hola@go-onagency.es.