Voici le résumé des conférences données le deuxième jour de ce séminaire Symfoniste, qui évangélise de plus en plus d’adeptes (moi en particulier 🙂 ) …
- PSR-6 & Symfony Cache : de la perf en standard (Nicolas Grekas) : Cette conf intéressante nous explique l’intérêt de PHP-FIG, où sont soumis et approuvés des standards de code PHP, préfixés PSR (Quand je code moi par exemple, je respecte au maximum la norme PSR-3, validée par mes outils d’intégration continue.). Pour PSR-6 (Caching Interface), le premier draft a été soumis en septembre 2013, le final en décembre 2015. Il définit deux objectifs : ouvrir des besoins de base nécessaires à la mise en cache, et permettre de faire mieux. Il « succède » un peu à Doctrine Cache. On retrouve cette PSR dans : psr/cache-implementation sur Packagist (Composer), Statsh PHP, PHP Cache et Symfony Cache. Symfony Cache n’est pas l’implémentation la plus puissante, elle est strict PSR-6, et suite les processus et standards de qualité Symfony. Il y a juste le minimum pour faire ce qu’il faut et aller vite.
- Aller plus loin avec Doctrine2 (André Tapia) : Dans Doctrine, on a des fonctions assez méconnues (IfNull comme en SQL IF NULL), il existe également des DoctrineExtensions pour méthodes personnalisées, et des LifeCycleCallbacks (prePersist/postPersist, preUpdate/postUpdate, loadClassMetadata etc …). On peut faire également appel à des requêtes « partial », qui permettent d’obtenir un objet, pas un tableau (Query::HYDRATE_OBJECT, Query::HYDRATE_ARRAY, Query::HYDRATE_SCALAR, Query::SINGLE_SCALAR).
- Refondre un moteur de règles avec l’expression langage de symfony2 (Abbas Hussein) : Pour la refonte, imposer un moteur de règle pour pouvoir : analyser des centaines de dates, déclencher un traitement statique, ou scorer une transaction (livraison : Go ou NoGO ?). Le but est de permettre de coder plus vite. A celà s’imposent des problématiques techniques : la fameuse datte technique, il faut construire à chaque fois le même projet, ou utiliser des petits projets OpenSource. Parmi eux, des problèmes métiers : les régles demandées par le métier sont de plus en plus complexes et les métiers écrivaient du JSON dans la BDD ! La meilleure des solutions doit donc : répondre aux besoins, être validée par les métiers, et extensible.
- Sécurité et HTTP (Romain Neutron) : Voici quelques HTTP-Headers plutôt utiles en matière de protection :
- X-XSS-Protection : protéger contre les attaques de type « Boutin ». Activé = 1. mode=block.
- X-Content-Type-Options : prévient le comportement d’un navigateur. Supporté par ie et chrome. « nosniff » seule valeur supportée (désactiver).
- X-Frame-Options : gestion du framing du site web.
- Strict-Transport-Security : RFC-7697 Force le HTTPS. Supporté par Crome, IE11, Safari et Firefox. Bloque l’accès si certificat invalide fourni. Valide à la première connection, mais peut être préloadé.
- Content-Security-Policy : vient du web 2.0. Prévient les XSS. Déclare des directives sur ce qui peut être exécuté sur le site web.Directives : default-src, script-src, style-src, object-src, img-src, media-src, frame-src, font-src, connect-src. Attention : certains scripts jQuery ne vont plus marcher si derective unsafe-eval et unsafe-inline !
Ma conclusion sur l’évènementiel le Symfony Live regroupe des thématiques plutôt variées (Sécurité, Cloud, Doctrine) … L’investissement est rentable, les stands attractifs. Mon seul regret est de ne pas avoir participé au Symfony Con qui se déroulait à Paris en décembre dernier, pour les dix ans de Symfony. Je pense bien renouveller l’expérience l’année prochaine, surtout si je gagne des concours qui me ramèneront plein de goodies (Casquette, Tshirt, ElePHPant Symfony, bonbons, macarons, et livre sur Blackfire.io dédicacé par Fabien Potencier).
Du coup j’ai gagné un badge, hop :
