Sylius 2 : que changer aux firewalls et utilisateurs ?

Pour passer à Sylius 2, il faut adapter le fichier security.yaml et les entités utilisateur : les firewalls de l'API sont renommés (new_api_admin_user devient api_admin, new_api_shop_user devient api_shop), chaque firewall reçoit une chaîne de user checkers, le salt et l'encodeur disparaissent au profit des hacheurs de mots de passe de Symfony, et les champs locked, expiresAt et credentialsExpireAt sont retirés. Bien fait, c'est invisible pour vos clients. Mal fait, ils ne peuvent plus se connecter.

Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. La sécurité est la partie de la migration où je ne fais aucune confiance aux suppositions : tout se vérifie avec de vrais comptes, anciens et récents.

Que dit la documentation officielle sur les firewalls ?

Le guide UPGRADE-2.0 de Sylius montre les changements sous forme de différences sur config/packages/security.yaml. Les firewalls admin et shop gardent leur nom. Les firewalls de l'API sont renommés en api_admin et api_shop. Et chacun des quatre reçoit une ligne user_checker qui pointe vers le service security.user_checker.chain. suivi du nom du firewall.

Les paramètres qui servent à construire les motifs et les routes de l'API suivent le même mouvement, décrit dans le guide UPGRADE-API-2.0 : sylius.security.new_api_route devient sylius.security.api_route, et de même pour les variantes admin, shop et compte client. Le préfixe de la route sylius_api doit donc être mis à jour. Enfin, le bundle de compatibilité de sécurité de SyliusLabs est retiré de config/bundles.php.

Pourquoi une chaîne de user checkers sur chaque firewall ?

Un user checker est un service que Symfony appelle pendant la connexion pour vérifier l'état du compte, avant et après le contrôle du mot de passe. La documentation de Symfony sur les user checkers décrit le mécanisme. Sylius 2 s'appuie sur une chaîne par firewall, ce qui permet d'empiler plusieurs vérifications.

Ce point continue d'évoluer dans la branche 2.x. Le fichier UPGRADE-2.3 indique que le checker sylius.user_checker.enabled n'est plus attaché au firewall shop : il est remplacé par deux checkers, l'un qui laisse passer un compte en attente de vérification pour valider son mot de passe, l'autre qui affiche ensuite le message « adresse non vérifiée ». Si votre projet avait décoré ou remplacé le premier pour la boutique, la personnalisation doit être déplacée vers sylius.user_checker.verification_aware_enabled.

Que deviennent les mots de passe et le salt ?

Sylius 2 retire l'encodeur et le salt des entités utilisateur. C'est désormais le hacheur configuré dans la sécurité de Symfony qui s'applique, avec par exemple Sylius\Component\User\Model\UserInterface: argon2i sous password_hashers. Le guide demande aussi de retirer les lignes encoder de la configuration sylius_user. Côté base, les migrations de Sylius 2 suppriment les colonnes salt et encoder_name des tables d'administrateurs et de clients.

Le guide donne un contrôle précis à faire en production : regarder les mots de passe hachés. Dans un projet Symfony récent, le nom de l'algorithme est stocké avec le hash. Si certains comptes anciens ne l'ont pas, il faut configurer l'option migrate_from, décrite dans la documentation de Symfony sur les mots de passe, pour que ces comptes restent vérifiables et soient rehachés à la connexion suivante. Si votre application n'a jamais changé de configuration d'algorithme, ce n'est pas nécessaire. Je le vérifie toujours sur une copie de la base, avec des comptes créés à différentes époques de la boutique.

Le maintien des comptes et de l'historique côté client est traité dans l'article sur les comptes clients et l'historique de commandes.

Quels changements sur les entités et services utilisateur ?

Le modèle utilisateur perd les champs locked, expiresAt et credentialsExpireAt, avec leurs méthodes et leurs colonnes. Cela concerne les clients, les administrateurs et tout type d'utilisateur maison qui étend le modèle de Sylius. Une boutique B2B qui bloquait des comptes avec locked doit reprendre cette règle autrement, par exemple avec le champ enabled ou un user checker dédié.

Plusieurs services disparaissent aussi. Le service sylius.security.user_login et l'interface UserLoginInterface, souvent utilisés pour connecter un client juste après son inscription, sont supprimés : Symfony propose une connexion programmatique dans son composant de sécurité. Le hacheur de mots de passe propre à Sylius est retiré au profit de celui de Symfony. La réinitialisation de mot de passe par code PIN est supprimée. Et le service d'usurpation de compte client utilisé par l'administration change d'identifiant.

Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, contient des analyseurs pour les firewalls renommés, l'ancienne configuration des encodeurs et les champs utilisateur supprimés, avec des corrections automatiques pour les renommages de firewalls et le passage aux hacheurs. Ce qui touche à vos règles métier, comme un compte bloqué, se décide à la main. C'est l'un des points que je chiffre dans le diagnostic de migration Sylius 2.

Comment tester la sécurité avant la bascule ?

Je rejoue sur une copie de la production une série de connexions : un client ancien, un client récent, un client dont l'adresse n'est pas vérifiée, un compte désactivé, un administrateur, la fonction « se souvenir de moi », le mot de passe oublié, et la connexion à l'API si un outil externe l'utilise. Chaque parcours doit donner le même résultat qu'en 1.14. Je vérifie aussi que les règles access_control protègent toujours l'administration et l'API, car un motif de firewall modifié peut ouvrir une route sans que rien ne plante.

Ce que je vous propose

Un client qui ne peut plus se connecter, c'est une commande perdue et souvent un client perdu. Avant le 31 décembre 2026, fin du support de sécurité de Sylius 1.14, je vous propose de lancer l'analyse sur votre projet, de contrôler la configuration de sécurité et les hashes de vos comptes, et de vous remettre un diagnostic offert avec une estimation en jours.