PrestaWard Authenticator

Ce qu’il fait

Un mot de passe volé ne devrait pas suffire pour accéder au Back Office. Le module ajoute un second facteur d’authentification sans transmettre les secrets à des API tierces.

Comment ça marche

Le second facteur concerne les codes à usage unique (TOTP) générés par une application d’authentification sur mobile. Si vous l’autorisez pour un profil, les employés associés à ce profil peuvent utiliser à la place des codes à huit chiffres envoyés par e-mail, une méthode moins sûre car toute personne ayant accès à la boîte mail peut se connecter ; le tableau de bord et la page de l’employé le signalent. Cette fonctionnalité est désactivée par défaut. La prise en charge des clés d’accès (passkeys) est incluse, mais désactivée par défaut dans cette version.
Chaque employé configure son propre facteur d’authentification depuis « Mon authentification », à l’aide d’un code QR généré directement dans la boutique. La première inscription est guidée : scanner le code QR, saisir le code, puis accéder à une page finale contenant les codes de récupération. Le bouton permettant d’accéder au Back Office ne s’active que lorsque l’employé a téléchargé, copié ou imprimé ces codes.
Il s’installe en mode Désactivé. En mode Audit uniquement, il enregistre les accès sans bloquer personne, et en mode Forcer, il exige le second facteur d’authentification. Un employé qui ne l’a pas encore configuré valide son mot de passe et ne peut ouvrir que Mon authentification tant que la configuration n’est pas terminée.
La politique est définie pour l’ensemble des boutiques et peut être ajustée par profil et par boutique. Dans le cas d’un système multiboutique, c’est la politique la plus stricte qui s’applique.
Avant de forcer, vous pouvez accorder à un profil une période de grâce de 3 à 14 jours. Les employés qui ne se sont pas encore inscrits accèdent normalement au système ; ils voient sur chaque page du Back Office un avis indiquant la date à partir de laquelle l’authentification en deux étapes deviendra obligatoire, et le tableau de bord affiche le nombre d’employés qui doivent encore s’inscrire. À la fin de la période, Forcer s’applique comme d’habitude.
Les appareils de confiance (30 jours par défaut) évitent de demander le code à chaque connexion depuis un appareil connu. Chaque employé peut les révoquer un par un.
Les tentatives de mot de passe et de code sont limitées (par défaut, 5 tentatives de code toutes les 5 minutes et un blocage de 15 minutes). Un code TOTP ne peut pas être réutilisé. Si PrestaWard Captcha protège l’accès au Back Office et rejette la requête, cet échec est uniquement comptabilisé dans la limite par adresse IP et non dans le verrouillage du compte de l’administrateur visé : un bot sans jeton ne peut plus bloquer un compte avec seulement quelques requêtes.
De temps à autre, la politique d’authentification multifactorielle (MFA) est renouvelée par la signature du service PrestaWard Integrity. Seules les données techniques relatives à l’installation sont transmises à Integrity ; en aucun cas les secrets TOTP, les codes de récupération ou les données des employés ne sont transmis.

Si un employé perd son téléphone portable

Codes de récupération personnels : chaque employé reçoit, par défaut, 10 codes à usage unique lors de la configuration de son facteur d’authentification et doit les conserver en dehors de la boutique.
Récupération facultative par e-mail : lors de la deuxième étape, l’employé peut demander un code par e-mail. Cette fonctionnalité est désactivée par défaut et doit être activée par un super-administrateur.
Réinitialisation depuis l’administration de la MFA, sans accès par console : un super-administrateur peut réinitialiser le second facteur d’un autre employé. Cette opération nécessite le mot de passe ; elle ne peut pas être effectuée sur soi-même et supprime l’authentificateur, les codes de récupération, les appareils de confiance et les sessions ouvertes de l’employé, qui doit se réinscrire lors de sa prochaine connexion. Les autres profils disposant d’un accès en modification à l’administration de la MFA ne peuvent réinitialiser que les employés dont le profil dispose de droits moins étendus, et seul un super-administrateur peut réinitialiser un autre super-administrateur. Chaque réinitialisation, ainsi que chaque tentative rejetée, est consignée dans le journal des accès.
Accès d’urgence via la console, en dernier recours : nécessite un accès au serveur et la clé d’urgence à usage unique générée dans l’interface d’administration de l’authentification multifactorielle (MFA). Permet de réinitialiser les facteurs d’un employé ou de suspendre l’obligation d’authentification multifactorielle pendant une heure si personne ne parvient à se connecter. L’opération est enregistrée et la clé ne peut pas être réutilisée.

Exigences

PrestaShop 1.7, 8 ou 9 et la version de PHP requise par votre version de PrestaShop (PHP 7.1 ou supérieur pour PrestaShop 1.7).
Une application d’authentification TOTP sur le téléphone portable de chaque employé, sauf pour les profils auxquels vous autorisez l’utilisation d’un code envoyé par e-mail comme second facteur d’authentification.
Pour la récupération par e-mail, les codes envoyés par e-mail et les alertes, la boutique doit pouvoir envoyer des e-mails.
Pour les clés d’accès (désactivées par défaut), une adresse HTTPS dans le Back Office.
La politique globale, le répertoire des employés, la messagerie et les journaux ne sont accessibles qu’aux super-administrateurs. Les autres employés ne gèrent que leurs propres paramètres.
Panneau de configuration et messages en neuf langues.

Limitations connues

Le gestionnaire de fichiers du cœur de PrestaShop (dossier filemanager de l’administration) n’exécute pas de modules ; il ne peut donc pas exiger le second facteur. Si le second facteur est obligatoire, supprimez cet accès pour les profils qui n’en ont pas besoin ou bloquez-le au niveau du serveur web.
La protection des pages Symfony du Back Office nécessite PrestaShop 1.7.7 ou une version ultérieure. Dans les versions antérieures, seules les pages classiques sont protégées.
Le service web et l’API d’administration de PrestaShop utilisent leurs propres clés et ne relèvent pas du champ d’application du module.

Ce qu’il ne fait pas

Il ne protège pas l’accès de vos clients à la boutique : uniquement le Back Office.
Il n’envoie ni secrets TOTP, ni codes de récupération, ni données relatives aux employés à des services externes.
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.

Compatibilité vérifiée

La version 0.0.16 a passé avec succès les tests en laboratoire sur PrestaShop 1.7, 8 et 9 le 15 octobre 2026, aussi bien sur une installation vierge que lors d’une mise à jour depuis la version 0.0.15. La version 0.0.15 a passé avec succès les tests en laboratoire sur PrestaShop 1.7, 8 et 9 le 13 octobre 2026 : installation vierge et mise à jour depuis la version 0.0.14 et depuis la version 0.0.6, avec conservation de la configuration, des secrets TOTP et des appareils de confiance, et sans erreur bloquante dans les journaux. La version 0.0.13 a été testée 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.

Principales fonctionnalités

Inscription TOTP avec mot de passe actuel et code QR généré localement.
Secrets chiffrés avec AES-256-GCM et codes de récupération HMAC à usage unique.
Blocage du rejeu TOTP par avancement atomique du compteur.
Protection contre la force brute sur le mot de passe et la MFA, par adresse IP et par identité, avec des limites et des blocages configurables.
IPv4, IPv6, CIDR, proxys de confiance et listes de réseaux, sans permettre qu’une liste sécurisée ne fasse l’omission de l’authentification à deux facteurs (MFA).
Appareils de confiance avec jetons de 256 bits, hachage, expiration et révocation.
Un portail en libre-service par employé, distinct de l’administration globale.
Politiques d’authentification multifactorielle (MFA) par profil et par boutique, avec une solution multiboutique répondant aux exigences les plus strictes.
Annulation configurable des sessions et des appareils après un changement de mot de passe.
Récupération de l’accès à l’aide de codes personnels, d’une clé facultative envoyée par e-mail et, en dernier recours, d’un accès d’urgence via la console à l’aide d’une clé à usage unique.
Code facultatif envoyé par e-mail lors d’un défi MFA, avec date d’expiration, HMAC et limites d’envoi.
Période de grâce par profil avant l’application obligatoire du second facteur d’authentification, avec notification dans le Back Office et suivi des employés en attente d’inscription.
Réinitialisation du second facteur d’authentification d’un employé depuis l’interface d’administration MFA, à l’aide du mot de passe administrateur et avec enregistrement de chaque tentative.
Activité récente dans le tableau de bord : résumé en phrases simples des 30 derniers jours du journal des accès (accès depuis une nouvelle adresse IP ou un nouveau navigateur, tentatives infructueuses répétées, blocages, codes de récupération utilisés et réinitialisations). Utilisez uniquement votre propre journal, sans géolocalisation ni services externes, et n’affichez pas d’adresses complètes : les adresses e-mail sont masquées et les adresses IP ne conservent que leur réseau /24 (IPv4) ou leurs trois premiers groupes (IPv6). Le journal des accès avec chaîne d’intégrité conserve les valeurs exactes.
Inscription guidée du premier facteur d’authentification, avec une page finale contenant les codes de récupération qui oblige l’utilisateur à les télécharger, les copier ou les imprimer avant de poursuivre.
Codes envoyés par e-mail comme second facteur d’authentification facultatif, uniquement pour les profils que vous autorisez : huit chiffres, enregistrés uniquement sous forme de hachage avec clé, valables cinq minutes, à usage unique et avec une limite d’envoi. Les employés confirment leur boîte mail une seule fois. La fonction « Récupération uniquement » fonctionne comme auparavant.
Mon authentification en bref : une barre d’état, une fiche par méthode avec une seule action repliable, les codes de récupération, les appareils de confiance et, à la fin, une « zone de danger » repliable. La suppression de l’authentification multifactorielle (MFA) explique ce qui est supprimé et ce qui est conservé : le mot de passe, un code actuel et une confirmation explicite ; cette mesure ne s’applique qu’à l’employé connecté.
Statistiques des 30 derniers jours avec les tendances quotidiennes (connexions, seconds facteurs de sécurité validés, échecs de mot de passe et de second facteur de sécurité, blocages, récupérations utilisées et nouveaux appareils de confiance), la couverture d’inscription par profil et les méthodes utilisées. Ne consultez que les chiffres relatifs à votre propre journal d’accès : les adresses IP et les e-mails ne sont pas affichés.
Un bot qui ne parvient pas à contourner le PrestaWard Captcha ne peut plus bloquer le compte d’un administrateur : cette défaillance n’est prise en compte que dans le cadre de la limite par adresse IP.
Synchronisation avec Integrity à l’ouverture du panneau, via une requête en arrière-plan qui ne ralentit pas le chargement de la page.
Panneau comportant cinq onglets (Aperçu, Employés et inscription, Politique, Statistiques et journal d’activité, et Configuration) ainsi qu’un onglet Assistance, toujours en dernier : l’onglet Aperçu affiche le mode, la couverture d’inscription, les pannes et les blocages des dernières 24 heures ainsi qu’une ligne d’alerte au maximum ; chaque onglet ne contient que ses propres paramètres.
Journaux chaînés via HMAC, avec conservation, exportation signée, filtres et pagination.
Alertes par e-mail équivalentes dans PrestaShop 1.7, 8 et 9, avec le logo de votre boutique dans l’en-tête et, dans le pied de page, le logo de GO ON Agency accompagné de la mention « PrestaWard by GO ON Agency ».
Barre de filtres commune dans le journal des accès : les sélecteurs sont répartis dans une grille de largeur égale, le champ de recherche et le bouton « Filtrer » se trouvent sur la même ligne et les actions secondaires sont alignées à droite.
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é.
Période de quarantaine minimale sans navigation jusqu’à ce que l’authentification multifactorielle (MFA) soit effectuée.
Enregistrement de l’installation et politique MFA signée via Integrity, sans transmission de secrets TOTP, de codes de récupération ni de données relatives aux employés. Sur l’écran du module, le bouton « Synchroniser » actualise la connexion.
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 ne contient que les versions, les états et les compteurs ; il n’inclut ni chemins d’accès ni identifiants et n’est pas envoyé automatiquement.

Utilisation sécurisée

Le mode par défaut est Désactivé. Chaque employé configure son compte depuis Mon authentification ; l’administrateur vérifie le déploiement, passe en mode Audit uniquement et active Forcer une fois la récupération validée.

Journal des modifications

0.0.16

Le panneau est organisé en onglets : Résumé (mode, couverture d’inscription, pannes et blocages des dernières 24 heures et, au maximum, une ligne d’alerte), Employés et inscription, Politique, Statistiques et journal d’activité, et Configuration. Le panneau d’assistance dispose de son propre onglet, « Assistance », qui apparaît toujours en dernier ; l’état d’Integrity s’affiche sous tous les onglets et l’en-tête présente le logo de GO ON Agency. Chaque onglet ne conserve que ses propres paramètres.
Corrige le fait qu’une requête qui ne passe pas le PrestaWard Captcha compte désormais pour le blocage du compte administrateur visé. Auparavant, les requêtes sans jeton Captcha étaient comptabilisées comme des échecs de mot de passe et un bot pouvait bloquer un compte en quelques requêtes seulement. Lorsque PrestaWard Captcha protège l’accès au Back Office et rejette la requête, l’échec n’est comptabilisé que dans la limite par adresse IP. Sans PrestaWard Captcha (ou en mode Observation), rien ne change.
Nouveau : codes par e-mail comme second facteur d’authentification facultatif. Dans les paramètres de messagerie, sélectionnez « Second facteur (le plus faible) », puis activez cette option pour chaque profil d’employé. Les employés disposant de ces profils confirment leur boîte mail une seule fois, à l’aide d’un code envoyé par e-mail, puis peuvent se connecter à l’aide de codes par e-mail : huit chiffres, enregistrés uniquement sous forme de hachage crypté, valables cinq minutes, à usage unique et soumis à une limite d’envoi, à l’instar des codes de récupération actuels. Les paramètres et la page dédiée aux employés indiquent clairement que cette méthode est moins sûre qu’une application d’authentification : toute personne capable de lire la boîte aux lettres peut se connecter. La fonction « Récupération uniquement » fonctionne exactement comme auparavant.
Nouveau : inscription guidée du premier facteur. Lorsqu’un employé doit s’inscrire (ou se trouve en période de grâce), « Mon authentification » le guide : scanner le code QR, saisir le code, puis une page finale de confirmation s’affiche avec les codes de récupération (à télécharger, copier ou imprimer). Le bouton « Passer au Back Office » ne fonctionne qu’après avoir téléchargé, copié ou imprimé les codes. Les clés d’accès et les codes par e-mail, s’ils sont activés pour l’employé, sont proposés dans la rubrique « Autres moyens de sécuriser votre compte ».
Mon authentification se résume désormais ainsi : une barre d’état (état, méthodes, codes de récupération et appareils de confiance), une fiche compacte par méthode (application d’authentification, clés d’accès et codes par e-mail) avec une seule action repliée, une fiche de codes de récupération, les appareils de confiance repliés et, à la fin, une « zone de danger » repliée. La section « Supprimer l’authentification multifactorielle » explique désormais ce qui est supprimé et ce qui se passe ensuite, et conserve un bouton rouge, le mot de passe, un code actuel et une confirmation explicite. Elle continue de s’appliquer uniquement à l’employé qui s’est connecté et figure dans le journal des accès avec une chaîne d’intégrité.
Confidentialité : la rubrique « Activité récente » n’affiche plus les adresses complètes. Les adresses e-mail apparaissent sous la forme j***@d***.com et les adresses IP ne conservent que leur réseau /24 (IPv4) ou leurs trois premiers groupes (IPv6), à l’instar de la rubrique « Statistiques ». Le journal des accès avec chaîne d’intégrité conserve les valeurs exactes et reste la source de référence.
Nouveau : Statistiques. Une nouvelle section présente les 30 derniers jours sous forme de petites tendances quotidiennes (connexions, second facteurs de sécurité vérifiés, échecs de mot de passe, échecs du second facteur de sécurité, blocages, récupérations utilisées et nouveaux appareils de confiance), ainsi que le taux d’inscription des employés tenus de s’inscrire (par profil) et les méthodes utilisées. Elle ne prend en compte que les chiffres issus de votre propre journal d’accès et n’affiche ni adresses IP ni adresses e-mail.
Clés d’accès (passkeys : Touch ID, Face ID, Windows Hello et clés de sécurité) comme second facteur d’authentification : le code est inclus, mais ces fonctionnalités sont désactivées par défaut et nécessitent une adresse HTTPS dans le Back Office. Un administrateur les active dans les paramètres, et chaque employé les ajoute dans « Mon authentification » en saisissant son mot de passe et le code actuel.
Corrige le fait que la connexion à Integrity se détériorait dans le Back Office « toutes les boutiques » : l’identité de l’installation n’était enregistrée que pour la première boutique ; la synchronisation en arrière-plan la lisait comme vide, ce qui entraînait une erreur « Invalid RSA public key » et la boutique connectée passait à l’état « inscription en attente ». L’identité est désormais lue comme une entité unique à partir de la portée globale (ou de la boutique qui la stocke) quel que soit le 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 être lue, l’état d’Integrity reste inchangé et la dernière erreur est enregistrée comme une erreur locale.
Corrige le fait que l’installation via la console (prestashop:module install) ne crée les paramètres PWA_* que pour la première boutique, alors que le Back Office « toutes les boutiques » lit les paramètres globaux. L’installation crée désormais les paramètres globaux et la mise à jour copie ceux qui manquent à partir de la première boutique sans écraser aucune valeur existante.
Nouveau : barre de filtres commune dans le journal des accès. Les sélecteurs sont répartis dans une grille de largeur égale, le champ de recherche et le bouton « Filtrer » se trouvent sur la même ligne et les actions secondaires sont alignées à droite.
Les e-mails du module 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 liens ni coordonnées. Le logo du pied de page est un fichier provenant du module lui-même et mis à disposition depuis vos boutiques.
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 réinitialisation du second facteur d’un autre employé et la synchronisation avec Integrity vérifiaient le jeton de sécurité à l’aide d’une méthode que PrestaShop 9 n’utilise pas, ce 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.
La mise à jour crée les paramètres globaux manquants, exécute l’étape de schéma (colonne de profil pour les codes par e-mail et les tables de clés d’accès) et maintient les codes par e-mail et les clés d’accès désactivés jusqu’à ce qu’un administrateur les active. Rien ne change dans une installation existante tant qu’un administrateur n’a pas activé une option.

0.0.15

Nouveau : réinitialisation du second facteur d’un employé depuis l’administration MFA. Si un employé perd son téléphone portable et ses codes de récupération, l’administrateur n’a plus besoin d’accéder à la console. La réinitialisation supprime l’authentificateur et les codes de récupération de l’employé, désactive ses appareils de confiance et ferme ses sessions ouvertes ; l’employé doit alors se reconnecter lors de sa prochaine connexion. Cette opération nécessite le mot de passe de l’administrateur ; elle ne peut pas être effectuée sur soi-même et un super-administrateur ne peut être réinitialisé que par un autre super-administrateur. Chaque réinitialisation, ainsi que chaque tentative rejetée, est consignée dans le journal des accès, et vous pouvez en informer l’employé par e-mail.
Nouveau : période de grâce avant l’application forcée. Dans les politiques de profil, vous pouvez accorder à un profil une période de grâce de 3 à 14 jours avant que la fonction Forcer ne bloque les employés qui ne se sont pas encore enregistrés. Ils se connectent normalement et voient sur chaque page du Back Office un avis indiquant la date à partir de laquelle l’authentification en deux étapes sera obligatoire ; ceux qui se sont déjà enregistrés continuent de demander leur code. Le tableau de bord affiche le délai applicable à chaque profil et le nombre d’employés qui doivent encore s’inscrire. Les profils sans période de grâce fonctionnent comme dans les versions précédentes.
Nouveau : la rubrique « Activité récente » du tableau de bord résume en phrases simples les 30 derniers jours du journal des accès : connexions depuis une adresse IP ou un navigateur que cet employé n’avait jamais utilisé auparavant, tentatives infructueuses répétées, blocages, codes de récupération utilisés et réinitialisations effectuées par l’administrateur. Utilisez uniquement votre propre journal, sans géolocalisation ni services externes.
L’utilisation d’un code de récupération personnel ou envoyé par e-mail est désormais consignée dans le journal des accès sous la mention « Code de récupération utilisé ».
La mise à jour ajoute deux colonnes aux politiques de profil (sans période de grâce par défaut) et enregistre le hook qui affiche l’avertissement relatif à la période de grâce.
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.
Les feuilles de style sont chargées avec la version du module, de sorte que le nouveau design s’affiche après la mise à jour sans qu’il soit nécessaire de vider le cache du navigateur.
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.0.14

Mise à jour de sécurité recommandée : renforce l’authentification à l’aide du second facteur dans le Back Office, de sorte que les pages et actions protégées ne soient accessibles qu’après avoir validé cette authentification.
Étend la vérification MFA aux chemins d’accès du Back Office de PrestaShop 1.7.7 à 9 qui n’utilisent pas le modèle classique, tels que les exportations et les requêtes AJAX.
Limite le nombre de tentatives pour toutes les vérifications de code de « Mon authentification », y compris par employé depuis différentes adresses IP, et exige une session vérifiée pour les modifications sensibles du compte.
Corrige une boucle de redirections dans PrestaShop 9 lors de l’ouverture de « Mon authentification » alors que le second facteur est en attente.
Les employés dont les profils ont été créés après l’installation peuvent désormais accéder à « Mon authentification ».
Corrige l’installation et les nouvelles tentatives d’Integrity sous PHP 7.1 et 7.2.
Renouvelle la politique MFA signée avant son expiration et signale dans le tableau de bord si elle a expiré.
Ajoute un accès d’urgence via la console, à usage unique, permettant de suspendre temporairement l’obligation d’authentification à deux facteurs (MFA) si personne ne parvient à se connecter. Il s’agit d’un dernier recours : cela nécessite un accès au serveur et la clé d’urgence ; la suspension dure une heure et est consignée. Les employés continuent de récupérer leur accès à l’aide de leurs codes personnels ou grâce à la procédure de récupération facultative par e-mail.
Traduit tous les événements du journal d’accès dans les neuf langues.

0.0.13

Corrige la compilation du conteneur du Back Office dans les versions héritées sans request_stack.
Conserve l’authentification à deux facteurs (MFA) et la limitation du nombre de tentatives dans PrestaShop 9 ; si le contexte requis fait défaut, refusez l’accès.
Ajoute un rapport de diagnostic manuel limité : téléchargez-le et joignez-le à votre demande d’assistance en précisant le problème et les étapes permettant de le reproduire. Il n’envoie pas de données automatiquement.
Interface complète en neuf langues, avec des textes et des aides traduits.

0.0.12

Corrige le contrôleur de test d’inscription dans PrestaShop 9 et affiche la cause réelle en cas d’échec d’Integrity.
Met à jour le design général du Back Office et supprime le vérificateur de mises à jour intégré à l’édition Addons.

0.0.11

Correctif de sécurité : il bloque les tentatives automatiques de réinscription lorsque la clé d’enregistrement de la boutique change et affiche un message d’avertissement clair dans le Back Office.

0.0.10

Heartbeat automatique sans cron grâce à une sonde locale non bloquante et à une communication authentifiée de serveur à serveur via l’Integrity API.
Identifiants scellés par boutique, politique d’authentification multifactorielle (MFA) signée et dernier état valide sans appels à distance lors de la connexion.
Verrouillage atomique, intervalle de six heures et délai d’attente après les échecs pour éviter les doublons.
Cycle de vie et mise à jour validés sur PrestaShop 1.7, 8 et 9.

0.0.9

Connexion sécurisée à Integrity par boutique, identifiant scellé et synchronisation depuis le Back Office.
La politique à distance signée ne peut que renforcer la politique MFA locale et n’intervient jamais dans la procédure de connexion.
Configuration réorganisée en quatre onglets : MFA et notifications, Politiques de profils d’employés, Tentatives et blocages, et Réseau et IP.
Les politiques par profil et par boutique sont désormais regroupées dans une section distincte afin de les séparer de la politique globale.
La source redondante des mises à jour est supprimée de la configuration : le canal officiel est désormais défini par le module.
Chaque champ de configuration comporte un lien vers son explication dans le guide d’aide.

0.0.8

Époque de sécurité par employé pour invalider les sessions, les défis et les appareils antérieurs.
Invalidation configurable après toute modification du mot de passe, uniquement en cas de récupération ou de modification administrative, ou jamais.
Politiques « Hériter », « Obligatoire », « Facultatif » et Désactivé par profil et par boutique.
Les super-administrateurs sont toujours soumis au mode Forcer, avec résolution multiboutique, conformément à la politique la plus stricte.
Clé d’urgence à usage unique et récupération exclusivement via la console, sans contournement web permanent.
Récupération facultative par e-mail lors d’un défi MFA, avec un code à huit chiffres, un HMAC, une durée de validité de cinq minutes et une limitation du nombre d’envois.
Journaux chaînés via HMAC, diagnostic d’intégrité, durée de conservation de 30 à 730 jours et exportation JSON signée.
Migration idempotente 0.0.8 et mise à jour validée depuis la version 0.0.7 sur PrestaShop 1.7, 8 et 9.

0.0.7

« Posture de sécurité » divisée en « MFA et alertes », « Tentatives et blocages » et « Réseau et IP », avec enregistrement atomique.
Navigation accessible au clavier entre les onglets, persistance de la sélection et ouverture automatique du panneau en cas d’erreurs de validation.
Pagination réelle des enregistrements dans la base de données avec 25, 50 ou 100 lignes par page.
Filtres des enregistrements par plage de dates, employé ou e-mail, événement, résultat et adresse IP.
En-tête de la rubrique « Mon authentification » repensé avec un meilleur contraste, une meilleure hiérarchie, une adaptation aux appareils mobiles et des accès d’entreprise.
Le test d’e-mail vérifie le transport et les destinataires sans exiger que les alertes opérationnelles soient activées.
Diagnostic visible du transport PrestaShop, distinguant les serveurs de capture et le serveur SMTP réel.
Diagnostic des erreurs compatible avec les fichiers SwiftMessage et MailerMessage de PrestaShop 1.7, 8 et 9.
Suppression du préfixe « boutique » en double dans les objets et renforcement du lien alternatif vers le Back Office.
Envoi d’entreprise validé via Exchange Online dans les trois versions prises en charge.
Panneau de mises à jour harmonisé avec Snapshot via PrestaWard Update Manifest v1, état, niveau de criticité et SHA-256.
Migration idempotente 0.0.7 et mise à jour validée depuis la version 0.0.6 sur PrestaShop 1.7, 8 et 9.

0.0.6

Protection transactionnelle contre la force brute sur le mot de passe et la MFA, par adresse IP et par identité.
Compatibilité avec IPv4, IPv6, CIDR, les proxys de confiance, la liste blanche et la liste noire.
Avis de blocage limités afin d’empêcher les tempêtes de e-mails provoquées.
Mise en quarantaine du serveur sans menu, sans raccourcis ni contenu du Back Office.
« Mon authentification » repensée en quatre étapes, avec des libellés accessibles, une récupération exportable et une révocation individuelle.
E-mails équivalents et traduits dans PrestaShop 1.7, 8 et 9, avec le résultat par destinataire.
Testeur renforcé : HTTPS d’entreprise, sans redirections, TLS, limite de corps et manifeste v1 strict.
Migration 0.0.6, mise à jour depuis la version 0.0.5 et tableaux de compatibilité complets pour les trois versions prises en charge.

0.0.5

Accès par étapes : PrestaShop valide d’abord le mot de passe, puis demande le code TOTP ou la procédure de récupération.
Session authentifiée en quarantaine, associée à l’employé et limitée à « Mon authentification » jusqu’à ce que l’authentification multifactorielle (MFA) soit effectuée.
Blocage de l’accès latéral via des contrôleurs directs et des requêtes AJAX/XHR.
Inscription obligatoire pour les employés et les super-administrateurs dont le TOTP n’est pas confirmé.
Les appareils de confiance ont été corrigés dans PrestaShop 9 et sont désormais associés à l’employé et au navigateur.
Second facteur repensé en espagnol avec le système visuel PrestaWard.
Guide détaillé avec des captures d’écran réelles du second facteur dans PrestaShop 1.7, 8 et 9.
Matrice complète et épurée : e-mail, TOTP, anti-replay, récupération, confiance et quarantaine.

0.0.4

Inscription obligatoire dans « Mon authentification » pour les comptes sans TOTP lorsque le mode est réglé sur Forcer.
Deuxième étape d’accès affichée uniquement après vérification du mot de passe.
Les super-administrateurs sont inclus dans le même processus d’authentification personnelle.
Formulaire d’authentification multifactorielle (MFA) repensé et traduit en espagnol.
Erreur 500 de l’e-mail de test corrigée.
Libre-service MFA distinct pour chaque employé.
Politique, inventaire, messagerie et journaux réservés au super-administrateur.
Autorisations modernes et héritées reconstruites de manière idempotente.
Diagnostic précis des destinataires, de la configuration SMTP et du transport.
Adresse IP réelle unifiée dans les journaux, la limitation de débit, les e-mails et les appareils de confiance.
Événements et textes du Back Office traduits en espagnol.
En-têtes et mise en page conformes à la famille PrestaWard.
Assistance d’entreprise rétablie sur hola@go-onagency.es.
Mise à jour 0.0.4 et matrice nettoyée sur PrestaShop 1.7, 8 et 9.

0.0.3

Géométrie visuelle unifiée avec PrestaWard Snapshot.
Appareils de confiance révocables avec des jetons aléatoires de 256 bits stockés sous forme de hachage.
Les cookies « Secure », « HttpOnly » et « SameSite=Lax » sont limités au Back Office.
Alertes équivalentes dans les intégrations héritées et Symfony.
Identité visuelle, liens vers les produits, guide, assistance et e-mail de test.
Validation de la limite de requêtes dans PrestaShop 1.7, 8 et 9.

0.0.2

Inscription TOTP protégée par mot de passe et code QR local.
Codes de récupération à usage unique stockés sous forme de HMAC.
Protection atomique contre le rejeu TOTP.
Limitation de débit par compte et par adresse IP.
Intégrations spécifiques pour la connexion héritée et PrestaShop 9 Symfony.
Rotation de l’authentificateur et désactivation de l’authentification multifactorielle (MFA) protégées par mot de passe et facteur d’authentification.

0.0.1

Scaffold sécurisé désactivé par défaut.
Tables MFA, TOTP, tableau de bord, audit, journaux, alertes et traductions initiales.