Lecture 12 minutes

Le Forum PHP 2016 s’est tenu les 27 et 28 octobre 2016 dans le très beau bâtiment du Beffroi de Montrouge et voici donc les notes de certaines des sessions suivies lors de cet événement.

Headers HTTP : Un bouclier pour votre application

L’exécution du profiling dans blackfire s’effectue à travers d’un bouton/snippet. Cet appel n’étant pas sécurisé par défaut il entraine des erreurs du type security policy (cf owasp). C’est cela qui a poussé Romain a s’intéresser à ce sujet et qui nous détaille quelques entêtes possibles :

• X-xss-protection
• X-content-type-option : par défaut les navigateurs ne tiennent pas compte du type de page qui lui est indiqué et ils font de la détection de mime automatique. Pour empêcher cela il faut positionner ce header à nosniff
• X-frame-option : permet de se protéger contre l’embarquement de votre site dans une iframe et éviter ainsi des attaques de type clikjacking
• Strict-transport-security ou hsts : indique au navigateur qu’il ne peut être accédé qu’en https pour son max-age comme un cache. C’est spécifique au domaine/sous domaine. Ainsi si un site inclus une de vos ressources (comme une image, un lien ou une interrogation ajax en http) alors le navigateur le bloque.
• Content-security-policy : permet de limiter les sources utilisables par la page. Par défaut rien n’est autorisé. Cela concerne à la fois les sources liées mais aussi les scripts embarqué. Lorsque un navigateur ne respecte pas cela il peut envoyer un rapport en post à une URL
• Subresource integrity : permet au navigateur de vérifier des parties du code de la page avec des sources de contrôle (checksum). Pour que cela fonctionne il faut les passer en mode CORS via un crossorigin="anonymous".
• Public key pinning: header dans lequel on met la clé d’un certificat pour une URL. Cela force le navigateur à vérifier la clé en plus de la vérification dans le gestionnaire de certificat.

Il faut garder à l’esprit que malgré toutes ces options, une extension de navigateur prend la main avant l’interprétation de la page. Du coup, une extension malveillante peut désactiver toutes ces sécurités.

La présentation: https://speakerdeck.com/romain/headers-http-un-bouclier-sur-votre-application

Industrialisation et automatisation chez M6Web Lille

Cette démarche d’amélioration pas à pas a été présentée dans plusieurs sessions cette année. Les retours d’expérience restant très proche, la différence résidait sur les outils mis en place. Cette session était l’occasion de mettre en avant les outils de M6 Web Lille.

Un constat global a permis d’identifier plusieurs points à améliorer comme le fonctionnement en silo, des processus non existants ou non uniformes entre les silos, pas ou peu de monitoring.

• Etape 1 : Uniformisation des env de dev en passant sur docker.
• Etape 2 : Cycle de vie d’une user story via un outil web nommé targetprocess et utilisation d’un git flow standard avec une nomenclature des branche et commit et enfin du Slack pour les notifications.
• Etape 3 : Mise en place de gitlab-ci qui déclenche l’intégration continue à partir d’un push d’un développeur sur une branche de feature, cela se fait donc avant la merge request vers la branche develop.
• Etape 4 : Du déploiement automatisé vers les différents environnements qui est orchestré par Jenkins via des recettes Capistrano.
• Etape 5 : Le monitoring de la production mis en place via du grafana, statsd, sonar, sentry ou packetbeat pour tracer du trafic au temps de réponse en passant par la récupération de contexte générant des erreurs.

Notre environnement de développement n’est plus un bizutage !

Pascal lors de son arrivée à TEA, The Ebook Alternative a été surpris de ce qu’il considéré comme son bizutage à savoir : « Tu vas prendre 2 semaines pour configurer ton environnement de dev ».

Face à ce constat des actions ont été mises en place :

• Passage sous vagrant avec des configurations uniforme.
• L’utilisation de fichiers .dist était déjà en place pour les configurations spécifiques. L’utilisation de stow en local pour personnaliser le fichier dist au poste de développement où le développeur peut avoir quelque spécificités liées à ses habitudes.
• Utilisations d’autres outils/automatisation pour par exemple récupérer les bases de données de produit et les offusquer, un DNS local, etc.

Là c’était sur la première partie qui a mis 2 ans à se stabiliser.

Puis il y a eu l’avènement docker. Par contre à l’époque la partie docker-compose n’existait pas et fig ne semblait pas correspondre au besoin. La solution retenue a l’époque a été de passer à des scripts bash partagés.
Le passage sous docker a été fait en se basant sur des images publiques cependant le temps d’application des configurations était un peut trop long à chaque mise à jour des stacks. Du coup une registry interne a été mise en place.
La configuration des environnements était dans des recettes chef. Le maintien de ces recettes était laborieux et du coup la solution retenue a été le passage en direct dans les dockerfiles.

Voilà quelques une des étapes suivies avec comme ligne conductrice d’y aller pas à pas en amélioration continue.

La présentation devrait être disponible bientôt, suivez Pascal pour cela : https://twitter.com/pascal_martin

Make is an actual task runner

Le constat de départ est qu’il y a eu une grosse émergence d’outils de type task runner sur ces dernières années et qu’ils sont souvent liés à une techno. Julien Bianchi nous parle ici de make qui est transverse par rapport aux langages de dev et aux plateformes (oui make est dispo sur tout les os).
On a droit donc a des rappels et autres tips dans cette session :

• Chaque instruction a pour première cible sa condition d’exécution par exemple vérifier la présence d’un fichier.
• Une instruction peut être uniquement une liste d’autres instructions du make afin d’éclater les tâches.
• Il est possible d’avoir des arguments et autres configurations en début de fichier.
• Les variables et autres arguments peuvent venir de variables globales

La présentation: https://speakerdeck.com/jubianchi/make-is-an-actual-task-runner

La place de PHP dans l’architecture technique de Radio France (là où on ne tue pas les chatons!)

Afin de gérer et délivrer l’ensemble des contenus de radio France plusieurs patterns ont été mis en place : microservices, CORS et ESB. Pour cela les technos utilisées sont PHP (symfony & drupal), nodeJS et Fabric. Cela nécessite à ce jour environ 500 machines AWS et Google. Côté workflow de développement là aussi on retrouve les outils usuels comme gitlab, Jenkins ou capistrano. Cette architecture a été mise en place depuis mi-2015 car avant cela le SI était 100% sur Drupal. Pour cette transformation un brainstorming a eu lieu et a généré un manifeste avec 6 règles : indépendant, simple, rapide, évolutif et time to market.
Pour cela les choix techniques ont été :

• Sortir du full drupal
• Passage en API pour segmenter les briques
• Garder du PHP majoritairement par rapport aux compétences présentes
• Pour l’écoute des événements d’autres langages ont été utilisés comme nodeJS ou GO
• Pour la partie ESB du rabitMQ a été mis en place

Migrer d’une architecture custom à Symfony : la refonte de PrestaShop

Suite a un accouchement un peu douloureux du passage en MVC et de la refonte graphique en version 1.5/1.6, divers chantiers/outils ont été mis en place pour améliorer l’application. On parle de semver, psr2, composer ou encore webpack. Puis au niveau architecture des patterns apparaissent comme les adaptateurs ou autre repository dans la version 1.6.
Puis est venu la réflexion de comment vaincre l’historique et la dette technique associée. Le souhait a été donc de passer d’un framework propriétaire à un framework connu, avec une communauté et supporté par une société. Ainsi l’équipe technique recentre son attention sur l’implémentation des règles métiers propres à PrestaShop.
L’idée directrice est que tout au long de la migration, le code legacy peut avoir des dépendances au code Symfony directement mais en aucun cas l’inverse ne doit se faire. Si le code Symfony doit échanger avec des parties encore legacy il faut obligatoirement passer par l’adapter mis en place afin de pouvoir les débrancher au fil de l’avancement de la migration.
Des adaptateurs ont été mis en place en premier sur la gestion des produits et des traductions. Une des prochaines grandes étapes sera la migration des hook de PrestaShop en événements Symfony. Ça serait génial d’avoir aussi un retour sur tout le travail mis en place autour du changement de la gestion de la communauté et de la communication autour de cette migration.

Pourquoi strlen(‘‘) != 1

Tout d’abord Damien nous présente joyeusement l’historique de l’encodage informatique depuis UTF-8 à Unicode. Puis on passe sur les différences entre les fonctions standards et leurs équivalences multibytes (mb_str*). Le charset par défaut a changé depuis PHP5.6 mais reste configurable au besoin. Une autre astuce pour traiter l’encodage est d’utiliser la classe Normalizer::normelize. Dans d’autres langages comme le JavaScript la longueur est comptée en UTF-16. Puis vient la partie MySql où Damien rappelle que le charset UTF-8 n’est pas correct vu qu’il stocke les données sur 3 bits et non 4, il est donc préférable d’utiliser utf8mb4.

De nombreux autres petits détails dans le genre sont fournis par Damien qui fait de cette session l’une des meilleures présentations du Forum 2016.

La présentation : https://jolicode.github.io/unicode-conf/

Boost up your code with Specifications

La modélisation d’entité fait que nous définissons habituellement les classes à l’image de leur représentation de l’ORM utilisé dans le projet.
En passant par une approche de type spécification, l’idée est d’aller interroger les données au travers de critères métier comme par exemple isYounger IsAwesome où chaque critère contient la traduction du critère métier en critère technique. RulerZ permet de faire cela de manière totalement agnostique par rapport aux choix techniques faits étant donné que cela va traduire la règle métier en SQL, doctrine, elasticsearsh, etc.

N’hésitez donc pas à aller voir du côté de RulerZ pour en savoir plus. Une petite pensée au membre de la communauté AFUP Lyonnaise Kevin Gomez qui a initié cette librairie !

Independence day

Frédéric Bouchery porte à notre attention (à très juste titre) les risques d’utilisation abusive de dépendance à des packages externes parfois très minime. Un des exemples cités est le Leftpad-gate arrivé au printemps dernier dans le monde JS où de très nombreux outils ont été non installables pour une dépendance externe référençant 11 lignes de code faisant un leftpad. Dans le même esprit l’utilisation de SemVer qui se veut une très bonne pratique en termes de structuration par contre lorsque vous avez des dépendances qui ont elles-mêmes des dépendances incompatibles entre elles. Un très bon exemple est le nombre de librairies dépendantes de Guzzle et plus particulièrement des versions spécifiques de Guzzle car il y a eu de nombreuses refontes d’architectures de cette librairie. Le fil conducteur est donc surtout d’avoir ces risques en tête lors de vos choix de dépendances et de les assumer. La conclusion de Frédéric est donc parfaite en cela: Prenez de l’indépendance par rapport à vos dépendances externes.

Middlewares : un vieux concept au cœur des nouvelles architectures

Commençons par la définition : un middleware est quelque chose qui prend une requête et qui renvoie une réponse. Une première approche des middlewares en PHP a été initiée par stackphp et l’utilisation du design pattern décorateur. Arrive alors en 2015 la PSR-7 et qui se repose lui sur une fonctionnalité standard les PHP callables. Pour la mise en place d’un middleware suivant cette définition il faut donc utiliser simplement une convention de nommage. Il s’agit là donc d’une convention de codage pour mettre en place un middleware prenant une requête en argument et renvoyant une réponse tout en chaînant (comme un pipe sous linux) les appels vers d’autres middlewares. Des frameworks se reposent maintenant sur ce type d’architecture comme le Zend Expressive/ZF3 ou Slim. L’architecture de type middleware permet donc de mettre en avant de manière claire si l’architecture a une certaine complexité.

Pour retrouver les slides de la présentation il faut suivre Mathieu: https://twitter.com/matthieunapoli

Les présentations seront prochainement présentes sur le site de l’AFUP c’est d’ailleurs aussi l’occasion pour remercier toute l’organisation de ce bel événement.