Blog

Retour sur le Symfony Live Paris 2022

Publié le 13 mai 2022

Les développeur·euse·s Symfony ont pu enfin se rencontrer physiquement le 7 et 8 avril dernier pour le Symfony Live 2022 à Paris. Cela faisait 2 ans que cela n’était pas arrivé, et c’était donc dans une ambiance joyeuse (et pluvieuse !) que ces deux jours de conférences ont eu lieu à la cité universitaire de Paris.

Bien évidemment, les Tilleuls.coop étaient venus en nombre : nous étions une dizaine de personnes dont 4 conférencier·ère·s et les visiteur·euse·s pouvaient venir nous rencontrer sur notre stand (et gagner des cadeaux grâce à notre jeu Lucky Webby !).

À noter pour cette édition : une track unique et les ¾ des visiteur·euse·s qui venaient pour la première fois à un Symfony Live !

Découvrez dans les lignes qui vont suivre, les retours de nos coopérateur.ice.s sur les différentes conférences auxquelles nous avons assisté, et participé en tant que speakers.

" class="wp-image-5196#

Keynote - Fabien Potencier

Comme à chaque édition, c’est Fabien Potencier, créateur de Symfony, qui démarre les conférences.

Cette fois il s’intéresse à une librairie de templating, liée à Symfony mais en dehors de ses composants : Twig.

Avant de nous présenter le changement majeur qui va toucher cette librairie, et dont il demande aux visiteur·euse·s de deviner lequel en échange d’une entrée gratuite à la Symfony Con (et vous, pouvez-vous le deviner avant la fin de ce petit résumé ?), il commence par nous parler d’un bug. Un bug qui ne concerne pas Twig mais le composant ExpressionLanguage de Symfony.

Ce bug, Fabien est tombé dessus lors de la refacto du site symfony.com, dans un test réalisé avec Blackfire Player. Lors de ce test, un sélecteur CSS est utilisé pour aller chercher un texte et le comparer avec le texte attendu en utilisant l’opérateur matches. Je fais un petit aparté au passage, ce n’est pas une très bonne pratique d’utiliser des sélecteurs CSS dans ce genre de test, allez plutôt chercher directement le texte dans la page, votre test sera bien plus robuste ! Ce test ne fonctionne pas alors que le texte existe, et en creusant un peu, il finit par se rendre compte que cela vient du fait que le texte attendu n’est pas considéré comme une expression régulière valide.

Première solution facile : utiliser une vraie expression régulière. Cela résout le souci certes, mais il a mis du temps à trouver la cause car aucun message d’erreur n’était renvoyé. Il se dit donc que ça serait bien de le corriger dans Symfony (et c’est une très bonne habitude qu’il nous montre ici : pensez à le faire aussi !).

Deuxième solution un peu mieux : le corriger dans Symfony, assez simplement. Mais Nicolas Grekas relit la PR et propose de récupérer le message initial pour l’afficher à l’utilisateur.

Deuxième solution bis : Fabien fait les changements indiqués par Nicolas, que vous pouvez voir dans la PR mergée en 4.4 (les corrections de bugs sont toujours faites dans la version maintenue de Symfony la plus vieille).

Pour l’anecdote, une fois que les nouvelles versions de Symfony sont sorties, cette correction engendre un nouveau bug, corrigé rapidement par un contributeur, merci à la communauté Symfony !

Vous pensez peut-être que ça fait déjà beaucoup d’améliorations et que cette histoire se termine ici. Au contraire, l’histoire devient encore plus intéressante !

Fabien se dit tout d’abord qu’il serait bon d’avoir aussi un contains en plus d’un matches dans le composant ExpressionLanguage. Parfait : cela existe maintenant en PHP nativement et la PR est donc relativement simple.

Mais Fabien le sait aussi par expérience, tous ces changements dans le composant ExpressionLanguage, il va devoir les répercuter dans Twig, car le code fonctionne souvent de manière identique, même si Twig a ses propres spécificités.

Il en profite alors pour demander dans la salle s’il y a des contributeur·rice·s intéressé·e·s à la fois pour la correction du matches et pour indiquer dans la documentation comment faire un contains en Twig (ce qui sera fait dans cette PR).

Peut-être que vous l’avez deviné maintenant, pour résoudre ce problème particulièrement pénible, Fabien annonce que Twig va être intégré à Symfony à partir de sa version 6.2 et qu’il utilisera le composant ExpressionLanguage !

Cela permettra aussi à Twig de bénéficier de tous les avantages de Symfony avec notamment la promesse de rétrocompatibilité et les sorties régulières.

J’ai trouvé cette keynote particulièrement intéressante. En retraçant l’histoire qui a permis finalement d’arriver à la décision d’intégrer Twig à Symfony, Fabien Potencier nous apprend à la fois comment contribuer en allant plus loin que la simple correction d’un bug mais aussi comment le framework Symfony évolue au jour le jour.

#

Comment valider dynamiquement de la donnée - Marion Hurteau

Un talk qui s’adresse à la fois aux novices comme aux vétérans sous forme de piqûre de rappel pour présenter un élément fondamental de Symfony qu’est le composant Validation. 

La première partie présente dans les grandes lignes le fonctionnement du composant et on a pu voir l’étendu des différents validateurs et contraintes existant nativement, chacun accompagné d’un petit bout de code représentant son implémentation. S’en est suivi une présentation plus détaillée de la contrainte UniqueEntity et de l’assertion EnableAutoMapping, que je ne connaissais pas et qui permet de créer automatiquement une validation sur chaque propriété basée sur le mapping Doctrine. Et enfin présenter les différentes façons de mettre en place ces contraintes (sur une classe, une propriété, etc.) J’aurai tout de même appris quelque chose malgré mon utilisation quasi quotidienne des validateurs Symfony.

La seconde partie du talk est dédiée au caractère “dynamique” de la validation de donnée, où Marion nous présente plus en détail le fonctionnement de l’assertion Callback permettant de base la création d’une validation custom via une méthode validate dans l’entité et s’en sert pour choisir quelle validation appliquer en fonction de la valeur d’une propriété de l’entité, ce qui est simple et rapide à mettre en place mais peu flexible et verbeux. Suite à ça la meilleure solution est à alors de créer un validateur custom sur lequel on vient injecter des contraintes externes via une simple configuration dans services.yml grâce aux tags.

Même si le sujet des validateurs est connu des utilisateurs de Symfony, Marion Hurteau de JoliCode a su ajouter un petit élément accrocheur en présentant des exemples de données basés sur le jeu Pokémon, rendant ainsi sa présentation plus conviviale et accessible.

#

Au tour de Mathias Arlaud et Robin Chalas, deux coopérateurs de donner une conférence ! Pour celle-ci, ils ont choisi de le faire en binôme, ce qui rend la présentation vraiment dynamique ! Par dessus des slides très bien réalisées et animées, Robin nous présente le vocabulaire lié à l’architecture Domain Driven Design et à l’architecture Hexagonale. Nous apprécions tout particulièrement l’oignon qui présente les différentes couches. 

Ensuite, place à Mathias qui met en application cette manière d’organiser le code à une API construite par dessus API Platform 3 ! En avant première nous découvrons la nouvelle nomenclature liée au nouveau système de métadonnées qui était présenté à l’API Platform Con de 2021 ! Par dessus un CRUD, ils alimentent le code avec des points d’API métier tout en séparant la couche domaine, de la couche applicative, de celle liée à l’infrastructure.

D’ailleurs, lors de la conférence Grégoire Pineau nous suggère une amélioration qui pourrait encore plus simplifier le découpage de la couche infrastructure de leur architecture. Cette discussion donne lieu à un patch dans API Platform qui remonte le concept de “provider/processor” directement dans la déclaration de l’opération. Découvrez même sur le dépôt GitHub lié à la conférence l’impact de cette modification sur le code présenté par Mathias et Robin : https://github.com/mtarld/apip-ddd.  

Au sujet d’API Platform, la version 2.7 est sortie en alpha et vous pouvez la tester dès à présent en suivant le guide de mise à jour ! Ne manquez pas l’API Platform Con de 2022 en septembre pour encore plus d’expertises et d’échanges autour du développement d’APIs hypermedia ! 

#

Doctrine, objet typé, et colonne JSON - Grégoire Pineau

Grégoire a couvert avec brio un sujet qui nous tient particulièrement à cœur chez Les-Tilleuls.coop : la possibilité de stocker des structures de données dynamiques en base de données à l’aide des colonnes JSON supportées par les SGBD modernes. Ces colonnes particulières ont l’avantage d’être extrêmement performantes (le type JSONB de Postgres à des performances similaires à MongoDB) et facilement requêtables.

Au cours de son talk, Grégoire a présenté l’intérêt de cette approche, puis comment il l'a implémentée en créant un type Doctrine sur mesure qui utilise composant Serializer de Symfony.

Comme à son habitude, Grégoire est pédagogue et sa présentation est didactique : pas à pas, il explique son implémentation.

L’objectif est d’être en mesure de stocker sous forme d’un document JSON des collections d’objets PHP dont chaque élément peut avoir un type (et donc une structure) différente. Il faut ensuite, au moment du requêtage, que Doctrine soit capable de recréer les objets PHP avec leur type d’origine. L’utilisation d’un simple `json_decode`, qui crée des objets “anonymes” de type stdClass, n’est donc pas une option viable.

Pour ce faire, Grégoire utilise donc le Serializer Symfony. Un identifiant associé au nom de la classe PHP de l’objet est ajouté dans le document JSON stocké en base afin de pouvoir recréer l’objet du bon type au moment du requêtage.

Le résultat final de l’implémentation de Grégoire ressemble à ma bibliothèque Doctrine JSON ODM (dont la version 1.2 est sortie en janvier). L’approche de Grégoire contient cependant une amélioration importante qui permet de contourner une limitation de ma bibliothèque touchant les documents imbriqués (avec un léger surcoût en matière de performance). Peut-être une Pull Request à venir ?!

#

Connaissez-vous vraiment JWT ? - Karim Pinchon

Karim nous a fait une présentation très intéressante sur le standard Json Web Token.

Il a démarré avec quelques rappels en matière de sécurité et de cryptographie basique, en commençant par nous expliquer que la signature, le hachage ou encore le chiffrement de données sont des opérations cryptographiques mais que l'encodage n'en est pas une.

S'en est suivi un passage en revue des différentes spécifications qui composent la famille JOSE (JWK, JWS, JWE et JWT) en expliquant ce que chacune d'elle permet de faire, qu'elles peuvent toutes être utilisées indépendamment, répondent à différents besoin, et qu’elles sont notamment implémentées par des protocoles d'authentification et d'autorisation tels que OAuth2 et OpenID Connect.
Ensuite, il nous a présenté quelques vulnérabilités plus ou moins connues qui ont pu être détectées dans les implémentations libres de la spécification au fil des années, illustrées très clairement grâce un petit projet de reproduction (et même un peu de live coding !).

Pour finir, il nous a présenté les alternatives existantes au format JWT dont Paseto, Biscuit, Macaroons et Branca.
J'ai apprécié ce talk qui visait à la fois à démystifier ce standard très présent dans nos applications ainsi qu'à fournir un état des lieux de celui-ci et de nous faire découvrir ses concurrents potentiels.

#

Vous avez dit Symfony 6.1 ? - Nicolas Grekas

Nicolas Grekas nous a présenté une rétrospective des 12 derniers mois de Symfony, ainsi que les nouveautés de la version 6.1, déjà quasi bouclée, qui sortira en mai prochain.

Il nous a présenté les processus en jeu dans les mises à jour et corrections des bugs découverts. En effet, dès lors qu’un bug est découvert, la correction contribuée doit être répercutée sur toutes les versions encore maintenues.

Il nous a également rappelé quelles sont les bonnes pratiques à avoir lorsque l’on maintient une application utilisant le framework, qui peuvent nous simplifier le travail : faire un `composer up symfony/*` une fois par mois afin de bénéficier des bug fixes, et passer à la version mineure suivante dans le `composer.json` tous les 6 mois, puis corriger les dépréciations petit à petit ; le tout afin de pouvoir évoluer au fil des versions de manière fluide.

Enfin, la nouveauté la plus notable est celle du support de PHP 8.1, qui passe par l’amélioration du typage. Le composant ExpressionLanguage a notamment été amélioré grâce aux nouvelles fonctions ainsi que l’opérateur null safe, et le composant HtmlSanitizer fait son apparition.

Parmi les nombreuses nouvelles features, on retrouve entre autres la possibilité de copier une requête en tant que cURL, contribuée par notre collaborateur Jérôme Tanghe, ou encore le profilage du sérialiser, par Mathias Arlaud.

Pour finir, il nous a parlé de la « coopétition » qui permet à Symfony d’évoluer : la manière dont l’équipe de la core team et les développeur⋅ses construisent le framework grâce à leur idées ou leurs désaccords, de manière à arriver à une approche novatrice.

#

Pour sa première lors d’un Symfony Live, notre co-gérante Marion Agé n’a pas opté pour la solution de facilité. C’est au redouté composant Security de Symfony qu’elle s’est attaquée !

Marion a commencé par nous présenter en détails le fonctionnement de ce composant majeur du framework. Après avoir rappelé les bases, elle a détaillé la refonte profonde du système d’authentification qui a été réalisée au cours du développement de Symfony 5.1.

Elle nous a ensuite présenté comment utiliser les fonctionnalités plus avancées permettant d’authentifier puis d’autoriser des utilisateurs, détaillant les nombreuses possibilités offertes nativement par Symfony.

Clou du spectacle, Marion a présenté comment elle a bâti un système de permissions entièrement configurables par l’utilisateur final à l’aide des briques fournies par le composant Security.

Ce système repose sur un mécanisme de règles permettant d’associer des listes de permissions à des ressources. Ces règles sont stockées en base de données, et donc potentiellement administrables via une API web ou interface graphique dédiée.

Cerise sur le gâteau, Marion a présenté un mécanisme d’alerte en temps réel qu’elle a bâti en utilisant ce système de permission. Marion nous a montré comment utiliser le composant Notifier pour les utilisateurs finaux dès qu’une ressource qu’ils ont le droit de consulter ou d’éditer est modifiée !

#

Un SSO avec Keycloak et Symfony - Laurent VOULLEMIER

Keycloak (https://www.keycloak.org/) est une solution permettant de gérer notamment l'authentification des utilisateurs et les contrôles d'accès (autorisation). Il gère le Single-Sign On (SSO), c'est-à-dire la possibilité de se connecter une seule fois pour un ensemble d'applications.

Laurent nous a d'abord présenté rapidement la surcouche OpenID Connect du protocole OAuth 2.0, sur lequel Keycloak peut se baser pour se comporter en serveur d'authentification.

Après la présentation de nombreuses fonctionnalités de Keycloak (protocoles, 2FA, login flows, etc.), Laurent a ensuite lancé une (longue !) vidéo de démo montrant le fonctionnement de Keycloak, qu'il a connecté sur la démo de Symfony.

Bien que cette démo soit intéressante, le fait que les explications soient préenregistrées m'a perturbé et cela rendait la conférence moins dynamique. Peut-être qu'il serait mieux de parler pendant la vidéo la prochaine fois, Laurent !

Laurent nous a ensuite détaillé son implémentation dans Symfony, en se basant sur le nouveau système d'authentification. Cette conférence faisait donc un bon complément à celle de notre coopératrice Marion.

J'ai trouvé cette partie intéressante pour comprendre comment le composant Security de Symfony et Keycloak / OIDC fonctionnent. Malgré cela, j'ai trouvé que cela nécessitait beaucoup de code et de configuration et donc beaucoup de failles de sécurité potentielles, ce que Laurent nous confirmait en nous disant par exemple de ne pas oublier de faire des vérifications de sécurité à certains endroits.

Peut-être cela indique-t-il qu’il manque de l’outillage dans Symfony (https://github.com/symfony/symfony/issues/45844), ou qu’une lib ou bundle open source doit être utilisé ou créé afin de ne pas avoir à écrire ce code dangereux.

Cela permettra de profiter de l’intelligence collective avant de renforcer la robustesse de cette implémentation et de permettre à des développeur·euse·s moins expérimenté·e·s de mettre en place ce genre de système sans compromettre leur application.

Retrouvez ici  les slides et vidéos de toutes les conférences de cette édition du Symfony Live Paris 2022 !

Pendant cet événement, notre coopérateur Kévin Dunglas en a profité pour faire une belle annonce : la 2e édition de notre API Platform Conférence, qui aura lieu les 15 et 16 septembre 2022 à Lille, et en ligne ! N’hésitez pas à jeter un oeil sur l’article à ce sujet !  Une belle line-up au programme ! Plusieurs de nos coopérateur.ice.s seront speakers, et nous recevrons aussi de chouettes invités qui interviendront sur divers sujets. Il paraît même qu’un talk sera dédié à Solid, par l’un des auteurs du protocole... Deux jours riches et intenses nous attendent sous le beau soleil lillois au cœur d' Euratechnologies, incubateur et accélérateur de start-ups !