👤 Contao email login : connexion des membres à partir des emails

J'ai déjà parlé de Contao, ce CMS/CMF open source qui déboite, dans un précédent article "Contao Content Visibility : masquer des contenus dans le back-office, par groupe d'utilisateurs". Cette fois, on attaque les critères de connexion des utilisateurs !

Il embarque un système d'utilisateurs frontend (à différencier des utilisateurs du backoffice) avec tout ce que ça implique derrière : inscription, connexion/deconnexion, mot de passe oublié, etc. Le problème que je me suis trainé pendant des années est que toute identification d'utilisateur se fait sur un champ username. Sauf que cela implique pour l'utilisateur de se souvenir et de son login et de son adresse email.

Pendant des années, j'ai utilisé un vieux trucs pour de vieilles versions : contao-email-login de 1up-lab. Mais il ne couvre pas les versions récentes du CMS. Quant à Contao lui-même, je n'ai pas trouvé de paramètre natif pour ça dans la 5.7. Si j'ai raté quelque chose d'évident, dites-le moi en commentaire, je mettrai à jour 😭

La solution ultime (non)

En attendant, j'ai donc crée le mien : contao-email-login-bundle. Compatible Contao 5.7.

La question principale quand on attaque ce genre de truc, c'est de savoir où on met les mains. L'option "propre sur le papier" aurait été de décorer le user provider Symfony pour faire la résolution email > membre à l'authentification. Sauf que toucher à la couche sécurité, c'est le genre de choix qu'on regrette à la première mise à jour majeure du framework. J'ai préféré quelque chose de beaucoup plus bête : recopier l'email dans le champ username à chaque enregistrement ou modification. Contao continue de chercher ses membres par username, il trouve juste une adresse email à la place d'un pseudo. Pas d'override sur la sécurité, le "remember me" et la 2FA fonctionnent comme avant, et si demain Contao change son système d'authentification ça ne cassera pas ce bundle.

Le truc merdique

Le seul détail un peu piégeux c'est le flag BINARY sur la colonne username en base, qui rendait la comparaison SQL sensible à la casse - quelqu'un qui tapait Jean@Exemple.fr au lieu de jean@exemple.fr se prenait un refus de connexion. La migration le supprime et les identifiants sont normalisés en minuscules à l'écriture. Rien de glorieux, mais sans ça l'outil était inutilisable en pratique.

Support de Notification Center

Par ailleurs, il y a une superbe extension qui est pas mal utilisée : Notification Center. Ce truc surcharge presque tous les modules natifs qui gèrent de près ou de loin des formulaires et/ou des emails. J'ai donc adapté mon "Contao email login" en conséquence, en lui apportant une compatibilité. Car en grod, il y a une petite subtilité autour du Notification Center : son module d'inscription est un type de fragment distinct, pas une extension du module natif, donc l'override classique via $GLOBALS['FE_MOD'] ne lui fait rien. J'ai dû gérer ça séparément, avec une dépendance optionnelle - si le Notification Center n'est pas installé, le bundle s'en fiche et tourne sur le module natif seul.

Let's go

Le tout est déjà en prod sur un projet réel, disponible sur Packagist via composer require greeneffect/contao-email-login-bundle. Trois commandes, quelques minutes de config du module d'inscription dans le back-office, et c'est plié. Le README documente les cas un peu tordus - membres existants, changement d'email en cours de vie, ce que ça implique sur la session.

👉 GreenEffect/contao-email-login-bundle sur GitHub
👉 GreenEffect/contao-email-login-bundle sur Packagist