Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de DataFirefly Magic Link, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
Pourquoi remplacer le mot de passe ?
Selon les études e-commerce, 30 à 40 % des paniers abandonnés au moment de la connexion le sont à cause d'un mot de passe oublié. Et chaque demande de réinitialisation génère un email, un délai, parfois un ticket support. Le magic link supprime cette friction : le client saisit son email, reçoit un lien, clique, et il est connecté. Plus simple pour lui, moins de support pour vous, et un parcours de commande plus rapide.
Comment fonctionne le module
Sous le formulaire de connexion standard, un second formulaire propose la connexion par email. Le client saisit son adresse, une requête AJAX génère un token aléatoire de 256 bits, en stocke uniquement le hash SHA-256 en base, et envoie un email contenant le token brut. Le client clique sur le lien dans l'email, arrive sur une page de confirmation, valide d'un clic, et il est authentifié dans la session PrestaShop comme avec une connexion classique. Les hooks d'authentification natifs sont déclenchés, donc tous vos autres modules continuent de fonctionner normalement.
Sécurité conçue pour la production
Le token brut n'existe que dans l'email envoyé. En base, seul le hash SHA-256 est stocké. Une fuite de la table ne donne donc aucun lien utilisable. Chaque token est à usage unique et marqué consommé dès qu'il est utilisé. La durée de validité est configurable (15 minutes par défaut, maximum 24 heures). Un rate limiting double surveille le nombre de demandes par adresse IP et par compte client sur une heure glissante, avec valeurs paramétrables. Et la réponse AJAX est volontairement générique pour empêcher un attaquant de distinguer un compte qui existe d'un compte qui n'existe pas.
Le problème des scanners email, et la solution
Outlook avec Safe Links, Gmail avec son aperçu, les antivirus d'entreprise et les proxies de sécurité visitent automatiquement chaque lien dans les emails reçus pour les scanner. Si le module consommait le token au premier GET, ces scanners brûleraient le lien avant même que le client puisse cliquer. Le module utilise donc un flow en deux temps : le GET affiche une page de confirmation autonome avec un bouton, et seul le POST déclenché par le clic réel consomme le token. Les scanners ne soumettent pas de formulaires arbitraires, donc ils ne peuvent pas brûler le lien. C'est le pattern utilisé par Slack, Notion, Vercel et Auth0 pour leurs magic links.
Page de confirmation universelle
La page sur laquelle arrive le client après avoir cliqué le lien est rendue comme un document HTML5 autonome, indépendant du thème PrestaShop. Cela garantit un rendu parfait sur n'importe quel thème — Classic, Hummingbird, Warehouse, MySmartBook ou personnalisé. La page reste sobre, centrée, avec le nom de la boutique en en-tête, un titre de bienvenue personnalisé, un bouton bleu de validation et une note de sécurité. Aucune dépendance CSS externe, aucun framework JavaScript chargé, rendu instantané.
Multilingue automatique
Le module fournit des templates emails HTML et texte brut traduits dans les quatre langues officielles de PrestaShop France : français, anglais, espagnol et allemand. La langue de l'email envoyé correspond automatiquement à la langue du compte client. Les chaînes d'interface (formulaire de demande, page de confirmation, messages d'erreur) sont également traduites via le système de traduction PrestaShop standard, donc personnalisables depuis le back-office si besoin.
Configuration back-office et statistiques
Une page de configuration accessible depuis Gestionnaire de modules expose tous les paramètres : activation, affichage du formulaire sur la page de connexion, durée de validité, plafonds de rate limiting, redirection après connexion. Trois compteurs en temps réel affichent les tokens actifs, les connexions des dernières 24 heures et les liens émis. Un bouton permet de purger manuellement les tokens expirés. La sauvegarde utilise un pattern POST puis redirect puis GET pour éviter les faux positifs des classificateurs de phishing comme Google Safe Browsing.
Il n’y a pas encore d’avis.