DEV Community: Guillaume Sainthillier

UX Icons JS : les icônes de Symfony UX, enfin en JavaScript, React et Vue

Guillaume Sainthillier — Tue, 20 Oct 2026 18:53:14 +0000

Si vous avez un projet Symfony récent, il y a de bonnes chances que vos icônes passent par Symfony UX Icons. Et c'est vrai que c'est agréable : une ligne de Twig, n'importe laquelle des plus de 200 000 icônes d'Iconify, un ux:icons:lock avant de déployer, et c'est réglé.

{{ ux_icon('lucide:trash-2', { class: 'text-danger', 'aria-label': 'Supprimer' }) }}

Tout va bien. Jusqu'au jour où cette même poubelle doit apparaître dans un contrôleur Stimulus. Ou dans le composant React de la page d'à côté. Là, Twig ne peut plus rien pour vous, et on finit tous par écrire ce genre de joyeuseté :

// assets/controllers/delete_controller.js
const TRASH_ICON = `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="1em" height="1em" fill="currentColor" aria-hidden="true"><path fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 11v6m4-6v6m5-11v14a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2V6M3 6h18M8 6V4a2 2 0 0 1 2-2h4a2 2 0 0 1 2 2v2"/></svg>`

this.buttonTarget.innerHTML = TRASH_ICON

Un SVG copié-collé depuis le navigateur, des attributs recopiés à la main depuis ux_icons.yaml (ou pas), et un innerHTML qui fera tiquer votre Content Security Policy. Côté React, c'est lucide-react qui s'invite dans le package.json : une deuxième source d'icônes, avec ses propres versions et ses propres attributs par défaut. Et le jour où vous changez default_icon_attributes, vos icônes Twig changent. Pas les autres. Le fameux "je synchroniserai plus tard".

L'histoire d'une PR refusée

Mon premier réflexe a été de proposer la fonctionnalité directement à Symfony UX : symfony/ux#4072. L'idée : sur le warmup du cache, UX Icons exporte les icônes locales dans un module JavaScript, avec les attributs que ux_icon() leur donne. Un petit package npm les affiche ensuite en JavaScript, React et Vue.

La PR a été fermée. Et pour être honnête, les arguments se tiennent : les bundlers savent déjà importer des .svg (avec SVGR ou vite-svg-loader), et l'ajout de React et Vue en dépendances de toutes les applications qui utilisent UX Icons, ce n'était pas un bon deal.

🤓 « Mais alors, SVGR fait déjà le job, non ? »

Pas tout à fait. SVGR n'a pas vu de release depuis août 2023, et vite-svg-loader ne connaît que Vite et Vue. Surtout, aucun des deux ne couvre le JavaScript vanilla d'un contrôleur Stimulus. Et aucun ne lit votre config ux_icons : vos icônes JS n'auront jamais les mêmes attributs que vos icônes Twig.

Le code était écrit, testé, et il me servait. Je l'ai donc sorti en bundle à part, qui se branche sur un UX Icons non modifié. Open source, évidemment : je vous présente UX Icons JS Bundle. Et React, Preact et Vue y sont des dépendances optionnelles : vous n'installez que ce dont vous vous servez.

Une icône, quatre façons de l'afficher

Le bundle dumpe vos icônes dans var/icons/index.js, un export nommé par icône. Vous importez celle dont vous avez besoin, comme n'importe quel module :

// En JavaScript vanilla, par exemple dans un contrôleur Stimulus
import { createIconElement } from '@silarhi/ux-icons-js'
import { LucideTrash2Icon } from '../../var/icons/index.js'

this.buttonTarget.append(createIconElement(LucideTrash2Icon, { class: 'text-danger', 'aria-label': 'Supprimer' }))

// En React (ou '@silarhi/ux-icons-js/preact' pour Preact, '@silarhi/ux-icons-js/vue' pour Vue)
import { UXIcon } from '@silarhi/ux-icons-js/react'
import { LucideTrash2Icon } from '../var/icons/index.js'

<UXIcon icon={LucideTrash2Icon} className="text-danger" aria-label="Supprimer" />

Et voilà ce que vous obtenez : exactement le HTML de ux_icon(). Pas "à peu près le même". Le même, caractère pour caractère, avec vos default_icon_attributes, les icon_attributes de vos icon sets, vos alias et vos suffixes. Le tout sans un seul innerHTML.

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/icons

En résumé, avant / après :

	Sans UX Icons JS	Avec UX Icons JS
Source des icônes	SVG copiés-collés, ou une lib par framework	Vos icônes UX Icons, et rien d'autre
Attributs	Recopiés à la main depuis `ux_icons.yaml`	Lus depuis la config, comme `ux_icon()`
JavaScript vanilla	`innerHTML` et une chaîne de caractères	`createIconElement()`, sans parser de HTML
React / Preact / Vue	`lucide-react`, `@heroicons/vue`…	Un composant `UXIcon`
Taille du bundle	Ça dépend de la lib	Seules les icônes importées
Nom d'icône venant d'une API	Tout embarquer, ou un `switch` géant	`loadIcon()` : un chunk par icône
Nouvelle icône	Télécharger, copier, coller	Écrire l'import, `ux:icons:lock`

C'est parti

Deux packages, publiés depuis le même tag git : le bundle Symfony qui dumpe les icônes, et le package npm qui les affiche.

composer require silarhi/ux-icons-js-bundle
pnpm add @silarhi/ux-icons-js

Si Flex ne l'a pas fait pour vous, enregistrez le bundle après UXIconsBundle, dont il réutilise la configuration :

// config/bundles.php
return [
    // ...
    Symfony\UX\Icons\UXIconsBundle::class => ['all' => true],
    Silarhi\UxIconsJsBundle\SilarhiUxIconsJsBundle::class => ['all' => true],
];

Et c'est tout pour la configuration. Les icônes sont dumpées au prochain warmup du cache, ou à la main pour voir ce qui se passe :

$ php bin/console ux-icons-js:dump -v
 * lucide:trash-2
 * user

 [OK] Dumped 2 icon(s).

Le dossier var/icons/ est généré : il n'a rien à faire dans git. Si var/ est déjà dans votre .gitignore (c'est le cas par défaut), vous n'avez rien à faire. Avec AssetMapper, le bundle mappe le dossier tout seul, il ne reste qu'à lui donner un nom dans importmap.php. Tout est détaillé dans la doc.

Une exception : si votre front se build sans PHP (une CI JavaScript, un stage Node dans votre Dockerfile), il ne trouvera pas var/icons/. Vous pouvez alors dumper les icônes dans assets/ et les committer, comme le fait la démo :

# config/packages/silarhi_ux_icons_js.yaml
silarhi_ux_icons_js:
    # Dans git : le front se build et se type-check sans PHP (CI, Docker)
    dump_directory: '%kernel.project_dir%/assets/js/icons'

when@prod:
    silarhi_ux_icons_js:
        # L'image embarque les assets déjà buildés : son warmup ne doit pas écrire dans assets/
        dump_directory: '%kernel.project_dir%/var/icons'
        dump_typescript: false

La contrepartie : le dump est refait à chaque reconstruction du cache, à vous de committer les changements après avoir ajouté une icône ou modifié les attributs de ux_icons.

Le plus dur est fait ! TOP.

Les détails qui m'ont donné du fil à retordre

Comme souvent, le gros du travail n'est pas là où on l'attend.

Le même HTML, vraiment

Promettre "le même HTML que ux_icon()", c'est facile. Le tenir, c'est une autre histoire. Les attributs passés à ux_icon() suivent les règles de la fonction html_attr() de Twig, et elles ont leurs subtilités :

renderIcon(LucideHeartIcon) // … aria-hidden="true">
renderIcon(LucideHeartIcon, { 'aria-label': 'Favori' }) // … aria-label="Favori">
renderIcon(LucideHeartIcon, { class: ['btn-icon', isActive && 'active'] }) // … class="btn-icon" si isActive est false
renderIcon(LucideHeartIcon, { height: null }) // plus de height du tout
renderIcon(LucideHeartIcon, { 'data-config': { id: 1 } }) // … data-config="{&quot;id&quot;:1}">

aria-hidden="true" est ajouté sauf si l'icône a une alternative textuelle, null supprime un attribut (même configuré), les tableaux deviennent des listes de classes, les objets des data-* en JSON… Le côté JavaScript reproduit tout ça, jusqu'à la position des attributs : un attribut redéfini garde sa place dans la balise <svg>, comme en PHP. C'est d'ailleurs un bug que j'avais laissé passer dans la PR, et que le bundle corrige.

Pour être sûr de ne pas se raconter d'histoires, les tests comparent la sortie de renderIcon() à celle de ux_icon(), octet par octet. La démo le fait aussi, en direct dans votre navigateur.

Un export par icône, pour le tree-shaking

Chaque icône est un export nommé : le nom de l'icône en PascalCase, suivi de Icon. Votre bundler ne garde que celles que vous importez, et les autres restent au placard.

Icône	Export
`user`	`UserIcon`
`lucide:trash-2`	`LucideTrash2Icon`
`fa7-brands:x-twitter`	`Fa7BrandsXTwitterIcon`
`500`	`_500Icon`

Petite subtilité : deux icônes peuvent donner le même nom d'export (sub:check et un alias sub-check donnent tous les deux SubCheckIcon). Plutôt que d'en écraser une en silence, le dump échoue et vous donne les deux noms. Une icône qui change toute seule en prod, c'est le genre de bug qu'on met une après-midi à comprendre.

Pour TypeScript, un index.d.ts est dumpé à côté, avec le nom littéral de chaque icône.

Et quand le nom de l'icône vient d'une API ?

C'est LE cas qui m'a fait sortir une version 0.2.0 dans la foulée. Un import nommé, c'est très bien quand vous connaissez l'icône en écrivant le code. Mais quand votre API renvoie { "icon": "lucide:server" }, vous ne la connaissez qu'au runtime. Et embarquer toutes les icônes "au cas où", c'est exactement ce qu'on voulait éviter.

Le bundle dumpe donc aussi un loaders.js, qui associe chaque nom d'icône au module de cette icône seule :

import { createIconElement, loadIcon } from '@silarhi/ux-icons-js'
import { loaders } from '../var/icons/loaders.js'

const data = await (await fetch('/api/status')).json()

const icon = await loadIcon(loaders, data.icon) // null pour un nom inconnu
if (icon) {
    badge.append(createIconElement(icon, { class: 'text-success' }))
}

Votre bundler découpe chaque icône dans son propre chunk : importer loaders ne télécharge aucune icône, et loadIcon() ne télécharge que celle demandée. Une seule fois, même si dix composants la demandent en même temps. En React et Vue, c'est le composant UXLazyIcon, avec un fallback pendant le chargement :

import { UXLazyIcon } from '@silarhi/ux-icons-js/react'
import { loaders } from '../var/icons/loaders.js'

<UXLazyIcon name={service.icon} loaders={loaders} fallback={<span className="placeholder" />} />

Et le loaders.d.ts exporte l'union des noms dumpés, IconName, pour typer vos réponses d'API ou vos props : une faute de frappe dans un nom d'icône ne passe plus la compilation.

`ux:icons:lock`, côté JavaScript

Avec UX Icons, le workflow classique est d'écrire ux_icon('lucide:mail') dans un template, puis de lancer ux:icons:lock : la commande trouve l'icône dans vos templates et la télécharge depuis Iconify. Je voulais exactement la même chose en JavaScript :

// assets/controllers/mail_controller.js
import { LucideMailIcon } from '../../var/icons/index.js'

$ php bin/console ux:icons:lock
 ✓ Imported lucide:mail (License: ISC). Render with: {{ ux_icon('lucide:mail') }}
 JavaScript: import { LucideMailIcon }
 // Dumped 3 icon(s) for JavaScript.

Vous écrivez l'import d'une icône qui n'existe pas encore, vous lancez la commande, et elle existe. Le bundle scanne vos fichiers .js, .jsx, .ts, .tsx, .vue et .svelte à la recherche des imports nommés depuis un module dont le chemin contient icons, et retrouve le nom de l'icône depuis le nom de l'export. Pas toujours une seule : LucideTrash2Icon peut venir de lucide:trash-2 ou de lucide:trash2. Tous les candidats sont proposés à ux:icons:lock, qui ignore ceux qu'Iconify ne connaît pas.

Et Preact ?

Dernière arrivée, en 0.3.0 : Preact. Avec preact/compat, le composant React fonctionnait déjà, mais autant se passer de la couche de compatibilité : @silarhi/ux-icons-js/preact fournit UXIcon et UXLazyIcon pour Preact 10 et 11, dans le navigateur comme avec preact-render-to-string, où il rend lui aussi le HTML de ux_icon().

import { UXIcon } from '@silarhi/ux-icons-js/preact'
import { LucideTrash2Icon } from '../var/icons/index.js'

<UXIcon icon={LucideTrash2Icon} class="text-danger" stroke-width="1.5" aria-label="Supprimer" />

Seule différence avec React : Preact prend les noms d'attributs HTML. On écrit donc class et stroke-width, pas className et strokeWidth (className reste accepté, et remplace la classe dumpée comme le fait class).

PHP 8.2 et Symfony 6.4

La PR visait la dernière version de UX Icons, donc PHP 8.4. Le bundle, lui, descend jusqu'à PHP 8.2, Symfony 6.4 et symfony/ux-icons 2.36.1 : parce que dans la vraie vie, les projets ne sont pas tous à jour (les miens non plus 🤫). Il y a juste deux limites sur UX Icons 2.x, ux:icons:lock n'y scanne pas le JavaScript, et les booléens n'y sont pas rendus pareil. Tout est dans les notes de compatibilité.

Ça donne quoi au final ?

La démo de cet article : 👉 https://labs.silarhi.fr/icons

Vous y trouverez la même icône rendue par Twig, par JavaScript et par React (avec la comparaison octet par octet), un bouton "copier" en Stimulus qui change d'icône sans innerHTML, une notation en étoiles en React, et un tableau de statut dont les icônes viennent d'une API : ouvrez l'onglet réseau, chaque icône arrive dans son propre petit chunk. Le code est sur silarhi/symfony-docker-ci, le projet qui me sert depuis des années pour les démos de ce blog.

Pour les curieux, sous le capot :

PHP 8.2+, Symfony 6.4, 7.x et 8.x, symfony/ux-icons 2.36.1+ ou 3.5+
React 18 / 19, Preact 10 / 11 et Vue 3 en dépendances optionnelles
Webpack Encore, Vite, AssetMapper : n'importe quel bundler fait l'affaire
Le corps du SVG est dumpé sous forme d'arbre, React, Preact et Vue le rendent en éléments : zéro dangerouslySetInnerHTML, zéro v-html
100 % du code couvert par les tests, et chaque combinaison de versions testée par la CI

Voilà ! Vos icônes n'ont plus d'excuse pour exister en deux exemplaires. N'hésitez pas à laisser un commentaire si vous l'utilisez, ou si quelque chose coince. Et si le bundle vous fait gagner du temps, une petite ⭐ sur GitHub fait toujours plaisir.

Pour aller plus loin

L'authentification à double facteur avec Symfony (2FA)

Guillaume Sainthillier — Mon, 05 Oct 2026 09:09:33 +0000

L’authentification à double facteur permet d’ajouter une sécurité supplémentaire à votre système de connexion. En plus d’un mot de passe, vous devrez fournir un code de vérification généré via une app de type Authenticator installée sur votre smartphone. On reviendra sur les termes et détails plus tard dans l'article.

Démo

Pour illustrer mes propos, voici le type de résultat que l'on peut obtenir grâce à cette librairie.

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/login

Installation

Pour commencer, il nous faut installer deux librairies. Dans un premier temps, pour la gestion du 2FA, nous allons utiliser Google2FA et pour la génération du QR Code pendant le setup, nous utiliserons BaconQrCode. Pour cela, nous allons utiliser composer :

composer require pragmarx/google2fa bacon/bacon-qr-code

Mise en place

Afin d'utiliser ces librairies, nous allons créer le controller SecurityController. Dans ce controller, nous retrouvons la méthode qui permet l'authentification sur votre site, c'est Symfony qui se charge de vous le donner à l'aide de la commande bin/console make:auth.

Allons plus loin et ajoutons 2 méthodes :

La première qui va génerer et afficher le QR Code.
La seconde qui va faire appel à un Authenticator afin de vérifier le code soumis.

Pour scanner le QR Code vous aurez besoin d'une application mobile. Plusieurs sont disponibles, comme Authy, Google Authenticator, Microsoft Authenticator, etc. Toutes ces applications implémentent le même protocole et utilisent un QR code pour la mise en place du 2FA pour vote site.

Controller

<?php

//src/Controller/SecurityController.php

namespace App\Controller;

use BaconQrCode\Renderer\Image\ImagickImageBackEnd;
use BaconQrCode\Renderer\ImageRenderer;
use BaconQrCode\Renderer\RendererStyle\RendererStyle;
use BaconQrCode\Writer;
use PragmaRX\Google2FA\Google2FA;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Authentication\AuthenticationUtils;

class SecurityController extends AbstractController
{
    public const QR_CODE_KEY = '_qr_code_secret';

    #[Route(path: '/login', name: 'app_login')]
    public function login(AuthenticationUtils $authenticationUtils): Response
    {
        // get the login error if there is one
        $error = $authenticationUtils->getLastAuthenticationError();
        // last username entered by the user
        $lastUsername = $authenticationUtils->getLastUsername();

        return $this->render('security/login.html.twig', ['last_username' => $lastUsername, 'error' => $error]);
    }

    #[Route(path: '/setup-2FA', name: 'app_security_setup_fa')]
    public function setup(Request $request, AuthenticationUtils $authenticationUtils): Response
    {
        $session = $request->getSession();
        $error = $authenticationUtils->getLastAuthenticationError();

        $google2fa = new Google2FA();
        if (!$session->has(self::QR_CODE_KEY)) {
            $secretKey = $google2fa->generateSecretKey();
            $session->set(self::QR_CODE_KEY, $secretKey);
        } else {
            $secretKey = $session->get(self::QR_CODE_KEY);
        }
        //Generate QR CODE based on secretKey
        $qrCodeUrl = $google2fa->getQRCodeUrl(
            '2FA DEMO (Silarhi)',
            'hello@silarhi.fr',
            $secretKey
        );
        $writer = new Writer(
            new ImageRenderer(
                new RendererStyle(400),
                new ImagickImageBackEnd()
            )
        );
        $qrCodeImage = base64_encode($writer->writeString($qrCodeUrl));

        return $this->render('security/setup-2fa.html.twig', [
            'qrCodeImage' => $qrCodeImage,
            'secretKey' => $secretKey,
            'error' => $error,
        ]);
    }

    #[Route(path: '/2FA-protected', name: 'app_security_authentification_protected')]
    public function authentificationProtected(): Response
    {
        return $this->render('security/protected.html.twig');
    }
}

Ici, dans la méthode setup, on stocke la génération d'une clé secrète dans la session utilisateur, car nous en aurons besoin dans l'Authenticator Symfony.

Suite à cela, on génère l'image du QR Code associé, que l'on donne en paramètre à la vue twig pour l'afficher. On prévoit ensuite de créer un input pour venir vérifier le code qui sera généré par l'application d'authentification choisie par l'utilisateur. On délègue ensuite à la classe TwoFactorsAuthenticator la responsabilité de vérifier le code qui vient d'être saisi !

security.yaml

Nous allons principalement ajouter 2 authenticators : 1 pour gérer l'authentification de base (formulaire de login classique), l'autre qui s'activera lorsque l'utilisateur aura saisi le code du QR code.

# config/packages/security.yaml

security:
    # https://symfony.com/doc/current/security.html#registering-the-user-hashing-passwords
    password_hashers:
        Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'plaintext'
    # https://symfony.com/doc/current/security.html#loading-the-user-the-user-provider
    providers:
        users_in_memory:
            memory:
                users:
                    test: { password: 'test', roles: [ 'ROLE_USER' ] }

    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js|assets)/
            security: false
        main:
            lazy: true
            provider: users_in_memory
            logout:
                path: /logout
            entry_point: App\Security\LoginFormAuthenticator
            custom_authenticator:
                - App\Security\LoginFormAuthenticator
                - App\Security\TwoFactorsAuthenticator

    # Easy way to control access for large sections of your site
    # Note: Only the *first* access control that matches will be used
    access_control:
        - { path: ^/setup-2FA, roles: ROLE_USER }

L'authenticator

Afin de vérifier si l'utilisateur a rentré le code de vérification, nous utilisons la méthode valideAuthentification, la route de cette méthode va être ajouté dans la constante LOGIN_ROUTE de la classe TwoFactorsAuthenticator que nous allons créer tout de suite.

<?php

//src/Security/TwoFactorsAuthenticator.php

namespace App\Security;

use App\Controller\SecurityController;
use App\EventSubscriber\DoubleAuthentificationSubscriber;
use PragmaRX\Google2FA\Google2FA;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;
use Symfony\Component\Security\Core\Authentication\Token\NullToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Exception\CustomUserMessageAuthenticationException;
use Symfony\Component\Security\Core\Exception\UserNotFoundException;
use Symfony\Component\Security\Http\Authenticator\AbstractLoginFormAuthenticator;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;
use Symfony\Component\Security\Http\Authenticator\Passport\Passport;
use Symfony\Component\Security\Http\Authenticator\Passport\SelfValidatingPassport;
use Symfony\Component\Security\Http\Authenticator\Token\PostAuthenticationToken;
use Symfony\Component\Security\Http\Util\TargetPathTrait;

class TwoFactorsAuthenticator extends AbstractLoginFormAuthenticator
{
    use TargetPathTrait;

    public const LOGIN_ROUTE = 'app_security_setup_fa';

    public function __construct(private TokenStorageInterface $tokenStorage, private UrlGeneratorInterface $urlGenerator)
    {
    }

    public function supports(Request $request): bool
    {
        return parent::supports($request)
            && $request->getSession()->has(SecurityController::QR_CODE_KEY);
    }

    public function authenticate(Request $request): Passport
    {
        //Get user from login form
        $existingToken = $this->tokenStorage->getToken();
        if (null === $existingToken || $existingToken instanceof NullToken) {
            throw new UserNotFoundException();
        }

        $user = $existingToken->getUser();
        $qrCode = $request->getPayload()->getString('qrCode');
        $secretKey = $request->getSession()->get(SecurityController::QR_CODE_KEY);

        $google2fa = new Google2FA();
        $google2fa->setSecret($secretKey);

        if (true !== $google2fa->verifyKey($google2fa->getSecret(), $qrCode)) {
            throw new CustomUserMessageAuthenticationException('This code is not valid');
        }

        $email = $user->getUserIdentifier();

        return new SelfValidatingPassport(
            new UserBadge($email)
        );
    }

    public function createToken(Passport $passport, string $firewallName): TokenInterface
    {
        $currentToken = parent::createToken($passport, $firewallName);

        $roles = array_merge($currentToken->getRoleNames(), [DoubleAuthentificationSubscriber::ROLE_2FA_SUCCEED]);

        return new PostAuthenticationToken(
            $currentToken->getUser(),
            $firewallName,
            $roles
        );
    }

    protected function getLoginUrl(Request $request): string
    {
        return $this->urlGenerator->generate(self::LOGIN_ROUTE);
    }

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, string $firewallName): ?Response
    {
        if ($targetPath = $this->getTargetPath($request->getSession(), $firewallName)) {
            $this->removeTargetPath($request->getSession(), $firewallName);

            return new RedirectResponse($targetPath);
        }

        return new RedirectResponse($this->urlGenerator->generate('app_security_authentification_protected'));
    }
}

Dans cette classe, nous récupérons les données postées du formulaire (donc le code de validation), dans la méthode authenticate, on récupère la clé secrète stockée en session pour vérifier si tout correspond. Si tel est le cas, alors on lui attribut le rôle de 2FA_SUCCEED qui appartient à la classe DoubleAuthentificationSubscriber

Le Subscriber

<?php

//src/EventSubscriber/DoubleAuthentificationSubscriber.php

namespace App\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\KernelEvents;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Http\Authenticator\Token\PostAuthenticationToken;

class DoubleAuthentificationSubscriber implements EventSubscriberInterface
{
    public const ROLE_2FA_SUCCEED = 'ROLE_2FA_SUCCEED';
    public const FIREWALL_NAME = 'main';

    public function __construct(private RouterInterface $router, private TokenStorageInterface $tokenStorage)
    {
    }

    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::REQUEST => ['onKernelRequest', -10],
        ];
    }

    public function onKernelRequest(RequestEvent $event): void
    {
        if (!$event->isMainRequest()) {
            return;
        }

        $route = $event->getRequest()->attributes->get('_route');
        if (!\in_array($route, ['app_security_authentification_protected'], true)) {
            return;
        }

        $currentToken = $this->tokenStorage->getToken();
        if (!$currentToken instanceof PostAuthenticationToken) {
            $response = new RedirectResponse($this->router->generate('app_login'));
            $event->setResponse($response);

            return;
        }

        if (null === $currentToken->getUser() || self::FIREWALL_NAME !== $currentToken->getFirewallName()) {
            return;
        }

        if ($this->hasRole($currentToken, self::ROLE_2FA_SUCCEED)) {
            return;
        }

        $response = new RedirectResponse($this->router->generate('app_security_setup_fa'));
        $event->setResponse($response);
    }

    private function hasRole(TokenInterface $token, string $role): bool
    {
        return \in_array($role, $token->getRoleNames(), true);
    }
}

Cet EventSubscriber s'éxécute à chaque fois qu'une page est chargée, il va venir vérifier plusieurs éléments, comme la route qui est demandée ou encore, ce qui nous interesse, si l'utilisateur a le rôle 2FA_SUCCEED.

L'ajout du rôle est important, il permet à l'utilisateur de ne pas contourner la page où l'on vérifie le code de vérification. Car si le rôle n'est pas attribué, alors il sera redirigé vers le formulaire qui permet d'entrer le code de vérification.

Pour aller plus loin

Gérez vos sites de production avec Traefik, Docker & Let's Encrypt

Guillaume Sainthillier — Mon, 05 Oct 2026 09:07:06 +0000

Vous avez une vieille app legacy en PHP 5 sur votre serveur de production qui vous empêche de déployer votre belle app Symfony 5 ? Vous montez un nouveau serveur de production et vous vous demandez comment gérer facilement des stacks différentes et l'ajout de nouveaux sites ? Vous voulez faire la fête comme cet ananas sur la cover ? Docker est peut-être la solution. En le combinant avec Traefik, vous avez une solution simple et rapide pour gérer vos apps de production et même le renouvellement automatique de vos certificats SSL avec Let's Encrypt.

Pré-requis : Je pars du principe que vous avez un minimum de notions avec Docker et docker-compose (au moins des notions de Dockerfile et de routage de ports entre le conteneur et le host). Je pars aussi du principe que vous êtes quelqu'un de bien et que votre serveur de production est sous Linux.

Traefik, c'est quoi ?

Crédits : https://traefik.io/

En fait, Traefik va jouer le rôle de reverse proxy. C'est à dire qu'il va être le récepteur frontal de toutes les requêtes HTTP qui vont venir des Internets et va les rediriger vers les bonnes instances de vos conteneurs Docker. Et c'est bien normal de mettre en place un reverse proxy quand vous avez plus d'une app Docker à exposer : vous ne pouvez pas toutes les faire écouter sur le port 80 ou 443. Vous voulez aussi un joli nom de domaine associé à votre instance Docker.

Installation de Traefik

La première étape est bien sûr d'installer Docker. Une fois chose faite, on va gérer tout le reste avec Docker Compose, désormais un plugin de Docker : la commande devient docker compose, sans tiret. L'installation est assez simple selon la documentation de Docker :

sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker compose version

On va commencer par créer un network qui sera partagé entre tous les conteneurs de nos applications. Je l'ai appelé "web" parce que j'aime être original mais aussi parce que c'est dur de trouver des noms, comme le rappelle ce brave Phil :

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

docker network create web

On crée ensuite notre fichier docker-compose.yml (j'ai pris pour habitude de mettre la configuration des conteneurs directement dans un dossier /apps à la racine du serveur de production, mais vous pouvez bien sûr changer l'emplacement selon vos habitudes) :

# /apps/traefik/docker-compose.yml
services:
  reverse-proxy:
    image: traefik:v3
    container_name: traefik
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - $PWD/traefik.toml:/etc/traefik/traefik.toml
      - $PWD/acme.json:/acme.json
    restart: always
    networks:
      - web
networks:
  web:
    external: true

Les directives vont créer une instance à partir de l'image officielle de Traefik. On veut qu'il réponde à la fois pour HTTP et HTTPS parce qu'en 2025, y'a plus d'excuses pour ne pas proposer par défaut des apps sécurisées.

Le conteneur est intégré au sein du network "web" que l'on vient de créer juste avant (c'est pourquoi on le tag comme external car il est géré en dehors de docker-compose).

🤓 « C'est quoi ce port 8080 d'ouvert ? »

Bien vu. Traefik dispose aussi d'une petite interface d'administration pour les services qu'il gère. Nous verrons en fin d'article comment sécuriser ce dashboard.

Pour l'explication des volumes utilisés, il y a 3 raisons.

La première : on utilise Traefik avec Docker. Traefik peut également fonctionner avec d'autres providers (Kubernetes pour les chauds, Consul, une configuration par fichiers, etc), mais dans notre cas on va directement se brancher sur le socket interne de l'engine Docker pour être notifié à chaque création / destruction de conteneurs. Ça va être super pratique pour monter un nouveau site en moins de 5 secondes.

La deuxième : il nous faut modifier la configuration par défaut de Traefik pour qu'elle colle parfaitement à nos besoins. C'est pourquoi j'ai créé un mapping pour le fichier traefik.toml, que je vais détailler juste après.

Dernière raison : Let's Encrypt génère des "challenges" pour les domaines qu'il a réussi à authentifier. C'est pourquoi il nous faut conserver le résultat de ces challenges en dehors de la portée éphémère d'un conteneur Docker.

Configuration de Traefik

Pour gérer HTTPS une fois pour toutes avec Let's Encrypt, on va modifier légèrement la configuration de base de Traefik. Ça se traduit par la création d'un fichier traefik.toml :

# /apps/traefik/traefik.toml
[api]
  dashboard = true
  insecure = true

[entryPoints]
  [entryPoints.web]
    address = ":80"
    [entryPoints.web.http]
      [entryPoints.web.http.redirections]
        [entryPoints.web.http.redirections.entryPoint]
          to = "websecure"
          scheme = "https"
          permanent = true

  [entryPoints.websecure]
    address = ":443"
      [entryPoints.websecure.http.tls]
        certResolver = "default"

[providers]
  [providers.docker]
    watch = true
    exposedByDefault = false
    network = "web"

[certificatesResolvers]
  [certificatesResolvers.default]
    [certificatesResolvers.default.acme]
      email = "contact@superman.com"
      storage = "acme.json"
    [certificatesResolvers.default.acme.tlsChallenge]

Attention, ne recopiez pas cette configuration sans d'abord comprendre ces lignes ! Personnellement, je ne suis pas fan du format TOML mais le contenu reste plutôt simple à lire.

Dans ce setup tout le trafic HTTP est automatiquement redirigé vers HTTPS. Si vous avez encore des apps que vous ne pouvez pas simplement passer en HTTPS (apps legacy, url claquée en dur dans le programme, etc), vous pouvez faire sauter les lignes sous [entryPoints.web.http]. Vous pouvez également commenter temporairement la ligne permanent = true le temps de faire vos tests si vous n'êtes pas trop sûr.e de ce que vous faites !

Traefik va gérer automatiquement pour nous la communication avec les serveurs de Let's encrypt et le renouvellement des certificats. C'est principalement les lignes sous [certificatesResolvers] qui s'occupent de ce job.

La section [providers] indique à Traefik d'aller écouter le socket Docker.

Allez, il nous faut encore créer le fichier acme.json avant de pouvoir admirer le résultat :

touch /apps/traefik/acme.json
chmod 600 /apps/traefik/acme.json

Le plus dur est fait ! Il ne nous reste plus qu'à builder et démarrer notre conteneur :

docker compose up -d

Si tout s'est bien passé, rendez-vous sur votresupersite.fr:8080. Vous tombez alors sur l'interface d'admin de Traefik. L'infrastructure de base est mise en place. YAY.

L'ajout des apps Docker dans Traefik

Traefik utilise avec les labels de Docker que l'on positionne dans le fichier docker-compose.yml de notre app pour lui indiquer comment gérer le trafic de cette instance.

Du concret

Parce qu'un exemple vaut 1000 lignes d'explications, je vais prendre l'exemple de la configuration de ce blog (qui tourne avec Ghost 6) et qui tient en moins de 30 lignes :

# /apps/blog.silarhi.fr/docker-compose.yml
services:
  app:
    image: ghost:6-alpine
    container_name: blog
    environment:
        url: https://blog.silarhi.fr
        database__client: mysql
        database__connection__host: mysql
        database__connection__user: root
        database__connection__password: supermotdepasse
        database__connection__database: blog
    volumes:
        - content:/var/lib/ghost/content
    networks:
        - web
    labels:
        - "traefik.enable=true"
        - "traefik.http.routers.blog.rule=Host(`blog.silarhi.fr`)"
        - "traefik.http.routers.blog.entrypoints=websecure"
    restart: always

volumes:
  content:

networks:
  web:
    external: true

Les informations vraiment importantes ici sont celles des labels (le reste étant standard).

Depuis Ghost 5, MySQL est obligatoire en production : les variables database__* pointent vers l'instance MySQL mutualisée que l'on va créer juste après (le service mysql, sur le même network web).

Le premier label traefik.enable=true indique à Traefik qu'il doit gérer ce conteneur. Cette ligne est à ajouter si vous avez laissé la configuration exposedByDefault = false dans votre fichier TOML. Dans le cas contraire, vous n'avez pas à vous en occuper.

Le label traefik.http.routers.blog.rule=Host('blog.silarhi.fr') permet de créer un routeur Traefik (que j'ai appelé blog) qui redirige vers CE conteneur TOUT le trafic qu'il reçoit venant des milliards de visiteurs quotidiens de blog.silarhi.fr.

Le dernier label traefik.http.routers.blog.entrypoints=websecure indique que ce conteneur sera disponible sur le port HTTPS (étant donné que Traefik redirige déjà le traffic HTTP vers HTTPS).

🤓 « Et si j'ai une base de données ? »

Facile ! Là encore tout se passe grâce à Docker. Vous pouvez choisir d'utiliser une instance de base de données par app ou bien de mutualiser l'instance pour toutes vos apps. Personnellement, j'ai fais le choix de mutualiser l'instance de MySQL étant donné que j'utilise exclusivement ce SGBD et la même version d'une app à l'autre.

# /apps/database/docker-compose.yml
services:
  mysql:
    image: mysql:8
    container_name: mysql
    environment:
        MYSQL_ROOT_PASSWORD: supermotdepasse
    volumes:
        - data:/var/lib/mysql
    networks:
        - web
    restart: always

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: phpmyadmin
    environment:
        MYSQL_ROOT_PASSWORD: supermotdepasse
        PMA_HOST: mysql
        UPLOAD_LIMIT: 128M
    labels:
        - "traefik.enable=true"
        - "traefik.http.routers.phpmyadmin.rule=Host(`pma.monsupersite.fr`)"
        - "traefik.http.routers.phpmyadmin.entrypoints=websecure"
    restart: always
    volumes:
        - /sessions
    networks:
        - web

volumes:
  data:

networks:
  web:
    external: true

En prime, je vous ai ajouté un conteneur phpMyAdmin (même si c'est vivement déconseillé pour la production). Pour la partie MySQL, on utilise là encore l'image officielle basée sur la version 8.4.

Il ne faut pas ajouter le label traefik.enable=true dans la configuration MySQL ! Le but étant d'exclure ce conteneur de la gestion de Traefik. En effet, on ne veut pas que MySQL soit accessible depuis l'extérieur, on va donc le laisser tranquillement dans son network local "web".

Modifier les informations de connexion à la base de données

La petite modification à faire dans le code de vos apps est de modifier les informations de connexion à la base. Vous devez remplacer en effet 127.0.0.1 par mysql (ou le nom que vous avez donné à votre service dans le fichier docker-compose.yml de MySQL). Eh oui, les conteneurs Docker sont isolés les uns des autres, par conséquence 127.0.0.1 fait référence au localhost du conteneur et non plus à celui du host.

Aller plus loin avec Traefik

Pour celles et ceux qui veulent pousser un peu l'utilisation de Traefik, on va voir ensemble quelques patterns communs que vous pourrez utiliser et reproduire.

Sécuriser le dashboard Traefik

Avec la configuration utilisée plus haut, on a autorisé l'accès publique au dashboard de Traefik sur le port 8080. Voyons un peu comment améliorer tout ça !

On va d'abord commencer par enlever le mode insecure et modifier la configuration :

# /apps/traefik/traefik.toml
[api]
  dashboard = true
- insecure = true

# /apps/traefik/docker-compose.yml 
 services:
   reverse-proxy:
     image: traefik:v3
     container_name: traefik
     ports:
       - "80:80"
       - "443:443"
-      - "8080:8080"
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock
       - $PWD/traefik.toml:/etc/traefik/traefik.toml
       - $PWD/acme.json:/acme.json
     restart: always
+    labels:
+      - "traefik.enable=true"
+      - "traefik.http.routers.api.rule=Host(`monsupersite.fr`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))"
+      - "traefik.http.routers.api.service=api@internal"
+      - "traefik.http.routers.api.entrypoints=websecure"
     networks:
       - web
 networks:
   web:
     external: true

Relancez le conteneur Traefik (docker compose up -d) et vous devriez pouvoir accéder à https://monsupersite.fr/dashboard/. On progresse, mais le dashboard est toujours accessible publiquement, ce qui n'est pas terrible.

Les middlewares à la rescousse

On va sécuriser l'accès au dashboard en utilisant un middleware. Vous avez déjà du entendre ce nom, c'est un pattern qui revient souvent en programmation. Dans notre cas on va placer une logique qui s'execute entre le routeur du dashboard Traefik (api) et le service associé (api@internal).

Il y a plusieurs manières d'ajouter des middlewares. Pour ma part, je suis partisan de la configuration via les labels de Docker, directement dans le docker-compose.yml de Traefik.

Forcer l'authentification avec `auth`

# /apps/traefik/docker-compose.yml
services:
  reverse-proxy:
    image: traefik:v3
    container_name: traefik
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - $PWD/traefik.toml:/etc/traefik/traefik.toml
      - $PWD/acme.json:/acme.json
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`monsupersite.fr`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))"
      - "traefik.http.routers.api.service=api@internal"
      - "traefik.http.routers.api.entrypoints=websecure"
+     - "traefik.http.routers.api.middlewares=auth"
+     - "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$6ydic0em$ZAhWtxDpkgZhpBOGT7ibu."
    networks:
      - web
networks:
  web:
    external: true

Avec cette configuration, vous avez protégé l'accès au dashboard avec l'équivalent d'un fichier htpasswd. Veillez à bien doubler les $ dans la chaîne de caractère du mot de passe !

Rediriger www vers non-www avec `redirectregex`

Vous l'avez compris, on va à nouveau ajouter un middleware dans le docker-compose.yml de Traefik !

# /apps/traefik/docker-compose.yml
services:
  reverse-proxy:
    image: traefik:v3
    container_name: traefik
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - $PWD/traefik.toml:/etc/traefik/traefik.toml
      - $PWD/acme.json:/acme.json
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`silarhi.fr`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))"
      - "traefik.http.routers.api.service=api@internal"
      - "traefik.http.routers.api.entrypoints=websecure"
      - "traefik.http.routers.api.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$6ydic0em$ZAhWtxDpkgZhpBOGT7ibu."
+     - "traefik.http.middlewares.strip-www.redirectregex.regex=^https?://(www\\.)(.+)"
+     - "traefik.http.middlewares.strip-www.redirectregex.replacement=https://$${2}"
+     - "traefik.http.middlewares.strip-www.redirectregex.permanent=true"
    networks:
      - web
networks:
  web:
    external: true

On va maintenant appeler le middleware dans notre site (j'ai repris l'exemple du blog) et ajouter la gestion du www (depuis Traefik v3, une règle Host ne prend plus qu'un seul domaine : on en combine deux avec ||) :

# /apps/blog.silarhi.fr/docker-compose.yml
services:
  app:
    image: ghost:6-alpine
    container_name: blog
    environment:
        url: https://blog.silarhi.fr
        database__client: mysql
        database__connection__host: mysql
        database__connection__user: root
        database__connection__password: supermotdepasse
        database__connection__database: blog
    volumes:
        - content:/var/lib/ghost/content
    networks:
        - web
    labels:
         - "traefik.enable=true"
-        - "traefik.http.routers.blog.rule=Host(`blog.silarhi.fr`)"
+        - "traefik.http.routers.blog.rule=Host(`blog.silarhi.fr`) || Host(`www.blog.silarhi.fr`)"
         - "traefik.http.routers.blog.entrypoints=websecure"
+        - "traefik.http.routers.blog.middlewares=strip-www"
    restart: always

volumes:
  content:

networks:
  web:
    external: true

Gérer des sous-repertoires avec `stripprefix`

Tout à l'heure, je vous ai montré comment exposer un conteneur phpMyAdmin avec un sous-domaine particulier. On va voir ici comment se passer de la création d'un sous-domaine en le placant plutôt dans un sous repertoire (en plus de le sécuriser avec une authentification !).

# /apps/database/docker-compose.yml

services:
  mysql:
    image: mysql:8
    container_name: mysql
    environment:
        MYSQL_ROOT_PASSWORD: supermotdepasse
    volumes:
        - data:/var/lib/mysql
    networks:
        - web
    restart: always

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: phpmyadmin
    environment:
        MYSQL_ROOT_PASSWORD: supermotdepasse
        PMA_HOST: mysql
+       PMA_ABSOLUTE_URI: "https://monsupersite.fr/_phpmyadmin/"
        UPLOAD_LIMIT: 128M
     labels:
         - "traefik.enable=true"
-        - "traefik.http.routers.phpmyadmin.rule=Host(`pma.monsupersite.fr`)"
+        - "traefik.http.routers.phpmyadmin.rule=Host(`monsupersite.fr`) && PathPrefix(`/_phpmyadmin/`)"
         - "traefik.http.routers.phpmyadmin.entrypoints=websecure"
+        - "traefik.http.routers.phpmyadmin.middlewares=phpmyadmin,auth"
+        - "traefik.http.middlewares.phpmyadmin.stripprefix.prefixes=/_phpmyadmin"
    restart: always
    volumes:
        - /sessions
    networks:
        - web

volumes:
  data:

networks:
  web:
    external: true

Vous êtes maintenant un pro de Docker et Traefik ! N'hésitez pas à me faire part de vos retours / succès / échecs dans les commentaires.

Ressources

Le déploiement continu en production pour Symfony 8 avec Docker et CircleCI

Guillaume Sainthillier — Mon, 05 Oct 2026 09:06:23 +0000

Vous avez une super app Symfony qui tourne (pas encore ?) avec Docker et vous voulez déclencher automatiquement sa mise en production lorsque vous faites un push dans une branche de votre repo. Respirez un grand coup, détendez-vous, vous êtes au bon endroit.

Avant de commencer, vérifions les bases. Simple, basique. Basique, simple.

Le déploiement continu, c'est quoi ?

Accueillez à nouveau le mot CD dans votre vocabulaire. Pas pour désigner le CD du groupe de rock de votre enfance, non, les choses ont bien changé. On parle ici de Continuous Deployment, l'automatisation du déploiement de vos apps sur vos serveurs de production en appuyant sur un gros bouton rouge.

Elle est pas belle la vie ?

Le cas d'étude

Sans plus attendre, on va s'intéresser à la stack technique suivante : Docker, Symfony 8, PHP 8.5, Tabler (Bootstrap 5), React et TypeScript. Pour pimenter un peu le tout, j'ai utilisé Vite avec Symfony Reprise pour me rapprocher d'un cas concret. J'ai donc des dépendances JS et SCSS à installer avec pnpm, à compiler, à minifier, etc.

La magnifique démo de cet article : 👉https://labs.silarhi.fr/

L'idée est qu'à chaque push sur une branche git (main en l'occurrence), le serveur de CD va build la nouvelle version de l'image Docker qui correspond à notre app, le déployer sur le Hub Docker et appeler un script de déploiement sur notre serveur via SSH. En gros, le workflow ressemble à ça :

Crédits : OpenClassrooms x Paint

Sans plus attendre, voyons à quoi ressemble le Dockerfile de production et/ou staging de notre app :

#syntax=docker/dockerfile:1.28-labs
# Dockerfile

# Versions
FROM silarhi/php-apache:8.5-frankenphp-alpine AS php_upstream
FROM node:24-alpine AS node_upstream

# Node base with pnpm (it switches itself to the version pinned in package.json "packageManager")
FROM node_upstream AS node_base
RUN npm install --global pnpm@12

# Base with extensions
FROM php_upstream AS php_base
RUN install-php-extensions exif gd imagick

# Composer deps (cached)
FROM php_base AS php_builder
WORKDIR /app
COPY --link composer.json composer.lock symfony.lock ./
RUN --mount=type=cache,target=/root/.composer \
    APP_ENV=prod composer install --no-interaction --no-dev --no-scripts --prefer-dist

# Node deps (cached separately from build)
FROM node_base AS node_deps
WORKDIR /app
COPY --from=php_builder --link /app/vendor ./vendor
COPY --link package.json pnpm-lock.yaml pnpm-workspace.yaml ./
RUN --mount=type=cache,target=/pnpm/store \
    pnpm install --frozen-lockfile --store-dir /pnpm/store

# Asset build
FROM node_base AS node_builder
WORKDIR /app
COPY --from=node_deps --link /app/node_modules ./node_modules
COPY --from=node_deps --link /app/vendor ./vendor
COPY --link package.json pnpm-lock.yaml pnpm-workspace.yaml vite.config.ts ./
COPY --link assets ./assets
# PurgeCSS keeps the selectors used in the Twig templates
COPY --link templates ./templates
RUN mkdir -p public && pnpm build

# Final
FROM php_base
EXPOSE 80
WORKDIR /app

ARG APP_VERSION=dev
ARG GIT_COMMIT=master
ENV APP_VERSION="${APP_VERSION}"
ENV GIT_COMMIT="${GIT_COMMIT}"

COPY --from=php_builder --link /app/vendor ./vendor
COPY --from=node_builder --link /app/public/build /app/public/build
COPY --link --exclude=assets --exclude=docker . .
# ux_icon() reads the SVG files at runtime (and on cache warmup)
COPY --link assets/icons ./assets/icons

# Config
COPY --link docker/php.ini $PHP_INI_DIR/conf.d/app.ini

RUN mkdir -p var var/storage && \
    composer dump-autoload --optimize --classmap-authoritative --no-dev --no-interaction && \
    APP_ENV=prod bin/console cache:clear --no-warmup && \
    APP_ENV=prod bin/console cache:warmup && \
    APP_ENV=prod bin/console ux:icons:warm-cache && \
    # We don't use DotEnv component as docker-compose will provide real environment variables
    echo "<?php return [];" > .env.local.php && \
    chown -R www-data:www-data var && \
    rm -rf /root/.cache

Avec ce Dockerfile multi-stage, on a un container tout chaud prêt pour la production : les dépendances Composer et pnpm sont installées dans des stages dédiés (et mises en cache par BuildKit), les fichiers JS et CSS sont compilés et minifiés par Vite, et le cache Symfony (icônes comprises) est déjà généré. Le tout tourne sur FrankenPHP, prêt à être délivré à vos millions de visiteurs par votre nouveau Raspberry Pi flambant neuf.

L'objectif est maintenant de réussir à build cette image automatiquement lors d'un nouveau push dans git, et à déployer l'app dans la foulée.

Dans le vif du sujet de la CD

Il existe pléthore d'outils pour arriver à nos fins :

Aujourd'hui, on va aborder CircleCI. N'hésitez pas à laisser un commentaire si vous voulez un tuto avec un autre outil de CI !

La CD avec CircleCI

CircleCI a l'avantage d'être gratuit dans son offre de base. On peut faire pas mal de choses avec cet outil, mais on va se concentrer sur les 4 opérations clés de notre flow :

Redescendre du code dans une VM éphémère
Build l'image Docker
Push l'image sur le Docker Hub
Appeler un script shell de déploiement sur le serveur de production

Pour ça, on va créer un fichier .circleci/config.yml à la racine du projet :

# .circleci/config.yml
version: 2.1

orbs:
    docker: circleci/docker@4.0.1

jobs:
    build:
        docker:
            - image: cimg/base:2026.10
              environment:
                  IMAGE_NAME: silarhi/symfony-docker-ci
        steps:
            - checkout # Étape 1
            - setup_remote_docker:
                  docker_layer_caching: true

            # Étapes 2 & 3
            - docker/check:
                  docker_password: DOCKER_PWD
            - docker/build:
                  image: $IMAGE_NAME
                  tag: 1.$CIRCLE_BUILD_NUM,latest
                  # --pull : sans lui, docker_layer_caching réutiliserait une vieille image silarhi/php-apache
                  extra_build_args: --pull --build-arg APP_VERSION=1.$CIRCLE_BUILD_NUM --build-arg GIT_COMMIT=${CIRCLE_SHA1:0:7}
            - docker/push:
                  image: $IMAGE_NAME
                  tag: 1.$CIRCLE_BUILD_NUM
            - when:
                  condition:
                      equal: [main, << pipeline.git.branch >>]
                  steps:
                      - docker/push:
                            image: $IMAGE_NAME
                            tag: latest
                            step_name: Docker push latest
    deploy: # Étape 4
        machine:
            image: ubuntu-2404:current
        steps:
            - add_ssh_keys:
                  fingerprints:
                      - 'de:c3:47:8e:28:31:55:01:9d:f7:08:f9:df:8e:79:e0'
            - run:
                  name: 'Deploy image to production'
                  command: |
                      ssh ${PRODUCTION_SERVER_USER}@${PRODUCTION_SERVER_IP} "cd ${PRODUCTION_SERVER_PATH} && ./deploy.sh"

# On exécute ces étapes lors d'un commit sur la branche main uniquement
workflows:
    build-and-deploy:
        jobs:
            - build
            - deploy:
                  requires:
                      - build
                  filters:
                      branches:
                          only: main

Ne fuyez pas en voyant ce fichier, on va le détailler un peu :

version: 2.1 permet d'utiliser les orbs, des paquets de configuration réutilisables. Ici, l'orb officiel circleci/docker fournit des commandes toutes prêtes pour build et push nos images.
À chaque push, un container Docker est créé par CircleCI. On spécifie l'image qu'on veut utiliser avec la directive image: cimg/base:2026.10. CircleCI nous laisse le choix d'utiliser des images déjà toutes prêtes conçues spécialement pour la CI/CD, autant les utiliser.
Étape 1 : checkout. Il faut bien sûr redescendre le code de GitHub dans le container si on veut l'utiliser après. setup_remote_docker nous donne ensuite un moteur Docker distant, avec le cache des layers activé (docker_layer_caching) pour accélérer les builds suivants.
Étapes 2 & 3 : docker/check se connecte au Docker Hub, docker/build construit l'image et docker/push la pousse sur le registre. Le tag 1.<numéro de build> est toujours poussé, le tag latest uniquement sur la branche main grâce à la condition when. Il y a cependant 2 choses à remarquer :
- L'utilisation de extra_build_args pour passer des options à docker build. --pull force le téléchargement de la dernière image de base : sans lui, le cache des layers de CircleCI garderait indéfiniment une vieille version de silarhi/php-apache. Les --build-arg, eux, sont complètement optionnels : c'est juste pour vous montrer qu'on peut utiliser le numéro de commit dans notre app Symfony via une variable d'environnement. Ça peut être utile par exemple si vous utilisez les releases de Sentry pour tracker quels commits sont particulièrement générateurs de problèmes.
- L'utilisation de variables non déclarées telles que PRODUCTION_SERVER_IP ou DOCKER_PWD. En fait, pour des raisons de sécurité, CircleCI permet de définir des variables d'environnement secrètes qui ne seront pas affichées dans les logs de CircleCI. Vous pouvez les définir dans l'interface de CircleCI :

Les variables d'environnement dans CircleCI

Étape 4 :
1. fingerprints permet d'utiliser la clé privée de votre serveur de production dans le container éphémère pour pouvoir se connecter par SSH sans utiliser de password. Veillez à bien sécuriser vos accès à CircleCI, car celui-ci devient désormais un élément critique de votre infra. Celui qui a accès à votre CircleCI peut avoir accès à votre serveur de production.
2. On exécute le script de déploiement sur le serveur de prod via la commande cd ${PRODUCTION_SERVER_PATH} && ./deploy.sh

Le script de déploiement

#!/bin/bash
set -e

#Download new image version
docker compose pull

#Set maintenance mode to perform critical operations (database, upgrades, ...)
APP_MAINTENANCE=1 docker compose up -d
#i.e: docker compose exec -T app bin/console doctrine:migration:migrate -n
sleep 10; #for demo purpose

#back to prod
docker compose up -d

L'hébergement sur la production

# /apps/labs.silarhi.fr/ci/docker-compose.yml
services:
  app:
    image: silarhi/symfony-docker-ci:latest
    container_name: lab_ci_app
    volumes:
      - storage:/app/var/storage
    environment:
      - APP_MAINTENANCE
    env_file:
      - app.env
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.labs-ci.rule=Host(`labs.silarhi.fr`)"
      - "traefik.http.routers.labs-ci.entrypoints=websecure"
      - "traefik.http.routers.labs-ci.tls=true"
    restart: unless-stopped
    networks:
      - web

volumes:
  storage:
networks:
  web:
    external: true

🤓 « C'est quoi ces labels bizarres ?! »

J'utilise Traefik pour gérer les instances de Docker sur la production. Si ça vous intéresse, n'hésitez pas à jeter un oeil à l'article que j'ai écrit à ce sujet.

La gestion de la mise à jour

Durant le déploiement, on définit une variable d'environnement APP_MAINTENANCE. Un petit tweak sur le contrôleur frontal de Symfony (public/index.php) permet de renvoyer une page de maintenance (avec un code HTTP 503) durant la mise en prod, et le tour est joué.

// public/index.php
use App\Kernel;
use Symfony\Component\HttpFoundation\Response;

require_once \dirname(__DIR__) . '/vendor/autoload_runtime.php';

return static function (array $context) {
    if ($context['APP_MAINTENANCE'] ?? false) {
        $html = file_get_contents(__DIR__ . '/../maintenance.html');

        return new Response($html, Response::HTTP_SERVICE_UNAVAILABLE);
    }

    return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};

Voilà ! Votre app est désormais fin prête à être déployée automatiquement pour votre plus grand bonheur. N'hésitez pas à laisser un commentaire si vous utilisez un autre workflow pour vos déploiements !

Pour aller plus loin

PicassoBundle : le composant image qui manquait à Symfony

Guillaume Sainthillier — Fri, 02 Oct 2026 22:11:38 +0000

Il y a quelques années, je vous parlais de la gestion des miniatures avec Glide. L'article tient toujours la route, mais le Web a bougé depuis. AVIF est arrivé. Les Core Web Vitals comptent pour le référencement, et le LCP vous tape sur les doigts dès qu'une image de 3 Mo traîne en haut de page. Côté React, Next.js a popularisé son composant <Image>, qui fait à peu près tout le boulot à votre place.

Pendant ce temps, côté Symfony, on écrit toujours ce genre de joyeuseté à la main quand on veut bien faire les choses :

<picture>
    <source
        type="image/avif"
        srcset="/images/hero-640.avif 640w, /images/hero-1080.avif 1080w, /images/hero-1920.avif 1920w"
        sizes="100vw"
    />
    <source
        type="image/webp"
        srcset="/images/hero-640.webp 640w, /images/hero-1080.webp 1080w, /images/hero-1920.webp 1920w"
        sizes="100vw"
    />
    <img
        src="/images/hero-1080.jpg"
        srcset="/images/hero-640.jpg 640w, /images/hero-1080.jpg 1080w, /images/hero-1920.jpg 1920w"
        sizes="100vw"
        width="1920"
        height="1080"
        loading="lazy"
        alt="Hero"
    />
</picture>

Et encore, là on a fait l'effort ! Dans la vraie vie de la vraie prod avec de vrais humains dessus, on ne fait (presque) jamais tout ça. Un <img> tout seul, pas de dimensions (bonjour le CLS), pas d'AVIF ni de WebP parce que "c'est déjà bien d'avoir un JPG". Et un Lighthouse à 60 qui vous rappelle gentiment que vous pourriez faire mieux. Le fameux "je le ferai plus tard", sauf que plus tard n'arrive jamais : il y a une feature à livrer la semaine prochaine.

Bref, à force de recopier ce bloc de projet en projet, j'ai fini par en faire un bundle. Open source, évidemment : je vous présente PicassoBundle.

En une ligne de Twig

Voilà ce que vous écrivez dans votre template :

<twig:Picasso:Image
    src="hero.jpg"
    width="1920"
    height="1080"
    sizes="100vw"
    alt="Hero"
/>

Et voilà ce que vous obtenez : le gros bloc HTML du début de l'article, sans en écrire une ligne. Avec en prime les bonnes valeurs de loading, les dimensions détectées depuis le fichier source si vous ne les passez pas, et des URLs signées pour éviter qu'un petit malin vous spamme de transformations en 9000x9000 pixels.

L'idée est piquée sans complexe à next/image côté React : un seul composant, et c'est lui qui se tape le boulot.

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/picasso

🤓 « Encore un bundle image ?! »

Bien vu. Mais regardez ce qui existe : Glide transforme les images et s'arrête là. LiipImagineBundle est puissant, mais il ne génère pas le HTML à votre place. Et on a tous un bundle maison qui traîne dans un placard. Il manquait la brique du dessus : celle qui va de l'image source jusqu'au HTML final, en passant par les formats modernes et les placeholders.

En résumé, avant / après :

	Sans PicassoBundle	Avec PicassoBundle
Formats	Les `<source>` AVIF/WebP/JPEG à la main	Automatique depuis la config
Srcset responsive	Fabriqué à la main par breakpoint	Généré depuis l'attribut `sizes`
Placeholders flous	DIY ou on zappe	Intégrés (LQIP, BlurHash, ou maison)
Dimensions	En dur ou oubliées	Détectées depuis l'image
LCP	`loading` et `fetchpriority` à la main	Un seul prop `priority`
Sources d'images	Filesystem uniquement	Filesystem, Flysystem, Vich, URL
CDN	À construire soi-même	Imgix intégré, ou votre CDN maison

C'est parti

Rien d'exotique, c'est un bundle Symfony classique :

composer require silarhi/picasso-bundle

Il vous faut ensuite au moins un transformer, c'est-à-dire ce qui va générer les variantes de vos images. Deux sont fournis :

# Option A : Glide (transformation locale avec GD ou Imagick)
composer require league/glide

# Option B : Imgix (transformation par le CDN)
# Rien à installer, juste l'URL de base à configurer

Si vous hébergez tout vous-même, Glide est le choix le plus simple. Si vous avez déjà un compte Imgix, branchez-le et profitez de leur cache. Cloudinary, ImageKit ou votre CDN maison ? Rien ne vous en empêche, il suffit d'écrire votre propre transformer.

La configuration minimale, avec un loader qui lit les images dans public/uploads et Glide qui signe les URLs :

# config/packages/picasso.yaml
picasso:
    loaders:
        filesystem:
            path: '%kernel.project_dir%/public/uploads'
    transformers:
        glide:
            sign_key: '%env(PICASSO_SIGN_KEY)%'

Avec un seul loader et un seul transformer, pas besoin de default_loader ni de default_transformer : le bundle les devine tout seul.

Pour que Glide serve les images transformées, il faut aussi importer ses routes :

# config/routes/picasso.yaml
picasso:
    resource: '@PicassoBundle/config/routes.php'

Le plus dur est fait ! Le premier exemple vu plus haut génère maintenant :

un <picture> avec une source AVIF et une source WebP
un <img> de secours en JPEG, avec son srcset calculé depuis les breakpoints
loading="lazy", sauf si vous lui passez priority
les dimensions, détectées depuis le fichier si vous ne les fournissez pas

Le tout sans écrire une ligne de HTML. TOP.

Les détails qui m'ont donné du fil à retordre

Sur ce genre de composant, l'essentiel du temps part dans les détails. En voici quelques-uns.

La détection des dimensions

Les attributs width et height d'un <img> ne servent pas à dimensionner l'image (ça, c'est le rôle du CSS). Ils disent au navigateur quelle forme a l'image avant qu'elle soit chargée, pour qu'il lui réserve la bonne place. Sans eux, la page "saute" quand l'image arrive : c'est le CLS (Cumulative Layout Shift), l'un des trois Core Web Vitals.

Le problème, c'est que personne ne renseigne les dimensions à la main sur chaque image. Et le ticket "corriger le CLS" traîne dans le backlog depuis des mois.

PicassoBundle peut lire les dimensions directement depuis l'image, avec l'option resolve_metadata. Elle est activée par défaut pour le loader filesystem (lire un fichier local ne coûte rien), mais pas pour les loaders distants : inutile de taper le réseau à chaque génération de page. Vous pouvez la forcer au cas par cas, ou fournir les dimensions en dur si vous les connaissez déjà :

{# Hauteur calculée depuis le ratio de l'image source #}
<twig:Picasso:Image src="photo.jpg" width="800" sizes="100vw" alt="Photo" />

{# Dimensions source fournies en dur, l'image n'est pas lue #}
<twig:Picasso:Image
    src="photo.jpg"
    :sourceWidth="4000"
    :sourceHeight="3000"
    width="800"
    height="600"
    alt="Photo"
/>

Petite subtilité : width et height ne sont rendus que si les deux sont connus. Si vous n'en fournissez qu'un et que le bundle ne trouve pas l'autre, aucun n'est posé sur le <img>. Une mauvaise dimension, c'est un CLS garanti. Autant ne rien mettre.

Les images prioritaires et le LCP

Pour une image en haut de page, typiquement une bannière, il faut dire au navigateur "celle-là, charge-la tout de suite". Sinon elle attend gentiment son tour derrière les vingt autres images de la page, et votre LCP (Largest Contentful Paint) fait pleurer Google.

Ici, ça tient en un prop :

<twig:Picasso:Image
    src="hero-banner.jpg"
    width="1920"
    height="1080"
    sizes="100vw"
    :priority="true"
    alt="Hero banner"
/>

priority pose loading="eager" et fetchpriority="high", et désactive le placeholder sur cette image. Une image prioritaire doit s'afficher le plus vite possible : afficher une version floue pendant une demi-seconde, c'est exactement l'inverse de ce qu'on veut.

Les placeholders

Les placeholders, c'est le chargement progressif des connexions 56k, version 2026. Pendant que l'image se charge, on affiche une version minuscule et floutée qui donne une idée de ce qui arrive. Medium et Unsplash le font, et la page paraît plus rapide même quand les Core Web Vitals ne bougent pas.

Ils ne sont pas activés par défaut. Le plus simple est le placeholder "transformer" (aussi appelé LQIP, pour Low Quality Image Placeholder) : une version en 10x10 pixels de l'image, floutée, générée par votre transformer. Aucune dépendance en plus :

# config/packages/picasso.yaml
picasso:
    default_placeholder: blur
    placeholders:
        blur:
            type: transformer
            size: 10
            blur: 5
            quality: 30

Si vous préférez un rendu en dégradé, il y a aussi un placeholder BlurHash (il demande kornrunner/blurhash et imagine/imagine). Et pour ThumbHash, une couleur dominante ou n'importe quoi qui génère une data URI, vous écrivez le vôtre avec l'attribut #[AsPlaceholder].

Dans tous les cas, le placeholder est inliné en background-image sur le <img> et retiré une fois l'image chargée. Il ne joue pas sur le CLS (ça, c'est le rôle de width et height) : il occupe juste la place en attendant la vraie image.

Des loaders pour la vraie vie

Un bundle qui ne lit que dans public/uploads, ça ne tient pas longtemps sur un vrai projet. Les loaders fournis :

Filesystem, le classique, un dossier local par loader
Flysystem, donc S3, GCS, Azure, FTP et tout ce qui ressemble à du stockage objet
VichUploaderBundle, parce que dès qu'un projet Symfony a des uploads, c'est quasi toujours Vich derrière
URL, pour des images hébergées ailleurs dont vous voulez quand même un srcset

Avec Vich, le loader porte le nom du mapping, et vous lui passez l'entité :

# config/packages/picasso.yaml
picasso:
    loaders:
        product_image: { type: vich }

<twig:Picasso:Image
    loader="product_image"
    :context="{ entity: product }"
    width="400"
    height="300"
    alt="Photo produit"
/>

Le bundle retrouve tout seul le fichier depuis le mapping. Et si votre source d'images est trop exotique pour tout ça, vous écrivez votre loader avec l'attribut #[AsImageLoader].

Et pour les frontends headless ?

Si votre Symfony sert une API JSON à du React, du Vue ou une app mobile, ImageHelperInterface::imageData() renvoie tout ce que génère le composant : URLs par format, srcset, placeholder, dimensions. Le front n'a plus qu'à reconstruire son <picture>. Et pour une simple URL (balise Open Graph, background CSS, email), il y a la fonction Twig picasso_image_url(). Les détails sont dans le README.

La purge du cache

Votre client change sa photo de profil (ça arrive toujours) : il faut invalider toutes les variantes générées depuis l'ancienne. Les deux transformers fournis savent le faire. Glide nettoie son cache local, Imgix appelle son API de purge (avec une clé d'API dans la config). Côté code :

// src/Service/ImageManager.php
use Silarhi\PicassoBundle\Service\ImagePipeline;

class ImageManager
{
    public function __construct(private ImagePipeline $pipeline) {}

    public function deleteImage(string $path): void
    {
        $this->pipeline->purge($path);
    }
}

Ça a l'air anecdotique. Jusqu'au jour où votre client vous appelle parce que sa nouvelle photo ne s'affiche pas en prod. Cache invalidation, toujours elle : Phil Karlton vous avait prévenu.

Ça donne quoi au final ?

La démo de cet article : 👉 https://labs.silarhi.fr/picasso

Vous y trouverez une grille responsive avec sizes, les différents modes de fit sur la même image, une bannière en priority, et quelques réglages par image (qualité, placeholder désactivé…). Le tout servi par Glide avec des URLs signées. Le code est sur silarhi/symfony-docker-ci, le projet qui me sert depuis des années pour les démos de ce blog.

La page historique qui utilise Glide directement est toujours là : https://labs.silarhi.fr/images. Comparez la quantité de Twig nécessaire entre les deux (spoiler : ce n'est pas vraiment la même).

Pour les curieux, sous le capot :

PHP 8.2+, Symfony 6.4, 7.x et 8.x
Loaders, transformers et placeholders déclarés avec des attributs PHP (#[AsImageLoader], #[AsImageTransformer], #[AsPlaceholder]) : zéro XML, zéro YAML de service, tout est autowiré
Un cache PSR-6 pour les dimensions détectées et les BlurHash
Compatible FrankenPHP en mode worker

Voilà ! Vos images n'ont plus d'excuse pour plomber votre LCP. N'hésitez pas à laisser un commentaire si vous l'utilisez, ou si quelque chose coince. Et si le bundle vous fait gagner du temps, une petite ⭐ sur GitHub fait toujours plaisir.

Pour aller plus loin

Gérer ses miniatures avec Symfony et Glide

Guillaume Sainthillier — Sat, 13 Jun 2020 12:15:26 +0000

🎉 Cet article a été cité dans le Week of Symfony #702 🎉

Aujourd'hui j'ai envie de vous parler d'un pattern récurrent dans un projet Web : la gestion des images et surtout des miniatures associées.

Aujourd'hui encore, le poids des images dans une page Web est toujours un facteur clé dans l'optimisation du poids des pages. Combien d'entre-nous continue encore de servir aux internautes mobiles des images de 1200px de long ?

On va donc voir comment mettre en place dans un projet Symfony la librairie PHP Glide qui met à disposition une API pour gérer la manipulation d'image.

Démo

Avant de partir dans les explications, je vais déjà tenter de vous attendrir avec le type de rendu final que l'on peut obtenir avec cette librairie :

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/images

Installation

Sans plus attendre on va commencer par installer tout doucement la librairie et créer un service Symfony pour gérer tout ça. Le package league/glide-symfony possède un adapter pour Symfony qui intègre la gestion des Response mais ne fournit pas de service par défaut.

composer require league/glide league/glide-symfony

Configuration

On va modifier un peu la configuration actuelle pour ajouter le service Symfony et préparer l'API.

# config/services.yaml
parameters:
    app.public_dir: '%kernel.project_dir%/public'
    app.image_cache_dir: '%kernel.project_dir%/var/storage/cache'

services:
    _defaults:
        #...
        bind:
            $secret: '%kernel.secret%'

    League\Glide\Server:
        factory: ['League\Glide\ServerFactory', create]
        arguments:
            source: '%app.public_dir%'
            cache: '%app.image_cache_dir%'

Mise en place

L'idée est ensuite de créer un Controller pour générer à la volée les miniatures (c'est notre "API"). On passera dans la requête le chemin relatif de l'image à utiliser ainsi que des pour indiquer la longueur / largeur désirée de la miniature, la couleur de fond, etc ...

Note sur la sécurité : Pour empêcher des utilisateurs malveillants de demander à générer sur votre serveur des centaines de miniatures aux dimensions non voulues (Imaginez votre serveur devant répondre à 10 000 requêtes de miniatures au format 50000x50000), nous allons également ajouter un hash de signature qui sera unique pour les dimensions données et que le Controller devra valider pour générer la miniature.

Le controller

<?php
//src/Controller/AssetsController.php

namespace App\Controller;

use League\Glide\Filesystem\FileNotFoundException;
use League\Glide\Responses\SymfonyResponseFactory;
use League\Glide\Server;
use League\Glide\Signatures\SignatureException;
use League\Glide\Signatures\SignatureFactory;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class AssetsController extends AbstractController
{
    #[Route(path: '/assets/{path<(.+)>}', name: 'asset_url', methods: ['GET'])]
    public function asset(string $path, string $secret, Request $request, Server $glide): Response
    {
        $parameters = $request->query->all();

        if ([] !== $parameters) {
            try {
                SignatureFactory::create($secret)->validateRequest($path, $parameters);
            } catch (SignatureException $e) {
                throw $this->createNotFoundException('', $e);
            }
        }

        $glide->setResponseFactory(new SymfonyResponseFactory($request));

        try {
            $response = $glide->getImageResponse($path, $parameters);
        } catch (\InvalidArgumentException|FileNotFoundException $e) {
            throw $this->createNotFoundException('', $e);
        }

        return $response;
    }
}

L'extension Twig

<?php
// src/Twig/AssetExtension.php

namespace App\Twig;

use League\Glide\Signatures\SignatureFactory;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;
use Twig\Attribute\AsTwigFunction;

class AssetExtension
{
    public function __construct(private readonly UrlGeneratorInterface $router, private readonly string $secret)
    {
    }

    #[AsTwigFunction(name: 'app_asset', isSafe: ['html'])]
    public function appAsset(string $path, array $parameters = [], int $referenceType = UrlGeneratorInterface::ABSOLUTE_PATH): string
    {
        $parameters['fm'] = 'pjpg';

        if (str_ends_with($path, 'png')) {
            $parameters['fm'] = 'png';
        }

        $parameters['s'] = SignatureFactory::create($this->secret)->generateSignature($path, $parameters);
        $parameters['path'] = ltrim($path, '/');

        return $this->router->generate('asset_url', $parameters, $referenceType);
    }
}

Plus besoin d'étendre AbstractExtension : depuis Symfony 7.3 (et Twig 3.21), l'attribut #[AsTwigFunction] déclare la fonction Twig directement sur la méthode. Avec ces 2 nouveaux fichiers, vous avez un système tout prêt de génération de miniatures sécurisé pour votre belle application !

Utilisation

Il ne vous reste plus qu'à utiliser votre fonction twig dans vos templates. La version minimale pourrait ressembler à ceci :

{# templates/images.html.twig #}
<img class="img-fluid"
     src="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200}) }}"
     width="400"
     height="200"
     alt="Ma super image de 400x200"
     title="Ma super image de 400x200"
/>

Ce qui produit l'URL suivante :

/assets/images/mon-image.jpg?w=400&h=200&fm=pjpg&s=d6ba0d9ef7622516b83fa3402527affe

Ce qui revient à demander au serveur :

Génère-moi la miniature du fichier /images/mon-image.jpg (si elle n'est pas déjà générée) d'une longueur de 400px (paramètre w), d'une hauteur de 200px (paramètre h), au format JPG Progressive (paramètre fm). Pour te prouver que je suis de bonne foi, je te donne le hash de vérification de ces 4 paramètres (paramètre s). Merci bisous.

Gestion des écrans retina

La gestion des écrans retina devient beaucoup plus simple vu qu'il n'y a plus qu'à passer les bons paramètres au contrôleur.

{# templates/images.html.twig #}
<img class="img-fluid"
     src="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200}) }}"
     srcset="{{ app_asset(asset('images/mon-image.jpg'), {'w': 400, 'h': 200, 'dpr': 2}) }}" 2x
     width="400"
     height="200"
     alt="Ma super image de 400x200"
     title="Ma super image de 400x200"
/>

J'ai juste ajouté avec le paramètre dpr (Device pixel ratio) pour générer une image 2 fois plus dense (en l'occurence 800x400).

Aller plus loin

Le bon développeur ou la bonne développeuse que vous êtes a sûrement détecté un pattern à factoriser pour améliorer la maintenabilité de tout ça. Je vous joins les 2 macros que j'utilise dans quasiment tous mes projets Symfony :

{# templates/macros.html.twig #}
{% macro image(path, width, height, attrs, params) %}
    <img src="{{ app_asset(path, params|default({})|merge({'w': width, 'h': height})) }}"
         srcset="{{ app_asset(path, params|default({})|merge({'w': width, 'h': height, 'dpr': 2})) }} 2x"
         width="{{ width }}"
         height="{{ height }}"
         loading="lazy"
        {% for name,value in attrs|default([])|filter((k, v) => k != 'class') %}{{ name }}="{{ value|e }}" {% endfor %}
    />
{% endmacro %}

{% macro fixedHeightImage(path, height, attrs) %}
    <img class="img-fluid {{ attrs.class|default(null) }}"
         src="{{ app_asset(path, {'h': height}) }}"
         srcset="{{ app_asset(path, {'h': height, 'dpr': 2}) }} 2x"
         loading="lazy"
        {% for name,value in attrs|default([]) |filter((k, v) => k != 'class') %}{{ name }}="{{ value|e }}" {% endfor %}
    />
{% endmacro %}

{# templates/images.html #}
{% import 'macros.html.twig' as macros %}

{{ macros.image(
    asset('images/mon-image.jpg'),
    300,
    300,
    {'class': 'img-fluid'},
) }}

Voilà ! Vous êtes maintenant un pro des miniatures ! N'hésitez pas à regarder le code source de la démo qui intègre Vite en plus de tout ça.

Pour aller plus loin

Coder sans jQuery ? Retour d'expérience

Guillaume Sainthillier — Thu, 16 May 2019 06:49:15 +0000

C'est officiel, Bootstrap va se séparer de sa dépendance la plus forte : jQuery. C'est ce qu'annonce cette PR sur le Github du plus célèbre Framework CSS. A la place, pas de nouveau framework Javascript, pas de super lib next gen : du Vanilla JS, tout simplement. Cette PR montre pour moi la tendance Javascript de 2019, qui se confirme en 2020 : jQuery a-t-il encore une raison d'exister ?

Si l'on remonte de quelques années aux temps où IE 6 était roi, jQuery avait du sens lorsque les navigateurs avaient d'énormes différences dans l'implémentation des specs. Aujourd'hui, bien qu'encore présentes, ces différences tendent à se réduire de plus en plus :

querySelector est devenu stable et consistent entre les navigateurs.
XMLHTTPRequest peut être remplacé par fetch qui est devenu standard.
Les animations peuvent être gérées en CSS3 et sont d'ailleurs plus performantes car elles utilisent le GPU du client.
Microsoft a annoncé l'arrêt de l'utilisation de son moteur de rendu en faveur de Chromium pour son navigateur Edge.
etc etc

Pour enfoncer le clou, GitHub annonce lui aussi qu'il a supprimé jQuery de son interface frontend. Alors, faut-il bannir absolument jQuery de ses nouveaux projets ?

Mon retour d'expérience

Un zeste de contexte

J'ai récemment développé une application Symfony pour un client. Fort de cette tendance, j'ai donc décidé d'utiliser du pur Javascript dans le projet et voir si j'arrivais à m'en sortir.

Pour ça, je me suis fortement inspiré de la structure frontend du site en-marche.fr qui était Open Source à l'époque (pro tip : vous n'avez pas besoin d'adhérer aux idées du parti politique pour pouvoir tirer le meilleur de l'architecture du site 🤫). Je trouve d'ailleurs que Titouan Galopin a fait de l'excellent travail lorsqu'il était sur ce projet.

La stack technique

Pour ce projet, j'ai utilisé Bootstrap, axios pour les requêtes HTTP, SweetAlert2 pour les popups, Select2 pour des jolis select et pjax pour accélérer les changements de page. Le code front métier étant écrit en ES6 et transpilé avec Webpack et Babel.

À cause de certaines de ces libs, j'ai donc quand même été contraint d'inclure jQuery dans mon projet, mais j'ai décidé de restreindre son utilisation uniquement pour manipuler les plugins. Histoire de jouer le jeu pour de vrai.

Résultat

Globalement, l'absence de jQuery ne s'est pas tant fait ressentir. C'est d'ailleurs gratifiant de savoir que l'on peut développer rapidement des apps sans framework JS et leurs contraintes associées.

En utilisant jQuery, je trouve aussi qu'on se place dans une zone de confort qui nous maintient à l’écart de l’univers JS. Et ça bouge vite, très vite. De nouveaux standards apparaissent quasiment chaque année, et apportent des évolutions intéressantes et de nouvelles façons de penser et d’écrire le Javascript. Il se passe des choses et il ne faut pas rater le coche, il n'y a qu’à voir du code écrit avec React pour se rendre compte du fossé qu'il y a avec jQuery, alors que les 2 s'appuient sur le même langage.

Mais tout n'est pas rose, il y a quand même eu quelques points de frustration :

Il y a toujours beaucoup de libs qui ne marchent qu'avec jQuery (Bootstrap 4, select2, etc etc). C'est pourquoi même si je n'en voulais pas, jQuery s'est invité de force dans mon fichier package.json.
fetch n'est pas si cool que ça. J'ai fini par utiliser axios après avoir perdu pas mal de temps à tenter de cerner ses subtilités.

Et vous ? Utilisez-vous encore jQuery en 2020 dans vos nouveaux projets ? Pensez-vous que jQuery va mourir ?

PS : Le bug de l'an 2000 risque bien de se reproduire si les systèmes ne se mettent pas à jour avant le 19 Janvier 2038 à 03h14 et 08s GMT, date à laquelle toutes les architectures d'ordinateurs qui sont encore en 32 bits cesseront de gérer correctement les dates. Mais ça reste entre nous 🤫

Utilisez Varnish et le cache ESI pour diviser le temps de réponse de votre site Web par 100

Guillaume Sainthillier — Sat, 11 May 2019 13:21:29 +0000

Le but de cet article est de vous faire comprendre les différents mécanismes qui peuvent être utilisés avec Varnish et le cache HTTP (TTL, Cache-Control, fragments ESI).

On va étudier un cas pratique avec une app PHP mais ces principes sont valables quel que soit le langage derrière, ce qui compte vraiment sont les entêtes de réponses que vous fournissez !

On évoque souvent la mise en place du cache applicatif type Redis comme la première solution pour optimiser les temps de réponse des sites. Découvrez ici seulement la vraie solution pour réduire les temps de réponse de votre site Web que seul 1% des gens connait.

Si vous lisez encore ces lignes, c'est que j'ai bien fait mon travail de teasing. Sans plus attendre, voici la solution ultime pour réduire les temps de réponse de votre site : Ne pas appeler votre site.

Mais quelle drôle d'idée.

Mine de rien, démarrer un process Web et retourner une réponse au client, même avec un super framework récent, ça reste long et coûteux. Bootstrapping du framework, connexion à une base de données, à un serveur Redis, vérification des droits utilisateurs, moteur de templating, etc etc. Sans trop forcer, vous pouvez vite atteindre les 200 ms pour retourner du contenu.

🤓 « Alors comment faire pour réduire mes temps de réponse ? Est-ce que je dois investir, booster mon serveur de prod et doubler le montant ma facture ? »

Pas du tout ! L'idée est d'utiliser à fond le cache HTTP pour stocker le rendu HTML généré par le backend. Pour ça, on va jouer avec Varnish, un reverse proxy-ultra puissant écrit en C. On parle ici de temps de réponse de l'ordre de quelques millisecondes si le contenu de la page est déjà présent dans le cache.

Le principe de Varnish est plutôt simple : Le reverse-proxy est en première ligne des requêtes utilisateurs. S'il possède déjà la réponse à cette requête, il la délivre directement sans interroger votre app. Sinon, il forward la request au backend et stocke le résultat (si vos entêtes lui indiquent). C'est aussi simple que ça. On va voir comment mettre en place concrètement ce flux en place.

Le principe simple de Varnish

C'est parti

L'idée est donc de mettre Varnish en frontal des requêtes utilisateur. C'est lui qui va maintenant écouter sur le port 80 et envoyer les requêtes vers votre serveur Web qui était en frontal jusqu'ici.

La première étape est de modifier les ports d'écoute de votre backend. Par exemple pour Apache on va modifier la configuration :

- Listen 80
+ Listen 8000

Gardez en tête le nouveau port d'écoute de votre serveur Web. Ensuite, on va installer Varnish : soit avec les paquets de votre distribution sur packagecloud, soit, le plus simple, avec l'image Docker officielle (c'est ce qu'utilise la démo, on y revient à la fin).

Un premier exemple : du contenu statique

Varnish utilise son propre langage de configuration (VCL) qu'il compile ensuite en C. C'est un poil bas niveau mais une fois bien configuré, vous allez mettre un moteur de Ferrari dans votre 2 CV.

On va commencer par un VCL minimaliste :

# /etc/varnish/default.vcl
vcl 4.1;

backend default {
    .host = "127.0.0.1"; 
    .port = "8000";  # Le port d'écoute de votre backend (Apache, Nginx, ...)
}

# Appelé à la fin de chaque réponse (en cache ou non)
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }

    set resp.http.X-Cache-Hits = obj.hits;

    return (deliver);
}

Prenez le temps de vous familiariser avec la syntaxe et la configuration. Ici, on a indiqué à Varnish qu'il existe un backend (default) accessible à l'adresse 127.0.0.1:8000 (souvenez-vous, c'est le nouveau port d'écoute de votre serveur Web).

On a aussi configuré une entête de réponse que l'on a nommé X-Cache pour savoir si la réponse a été récupérée du cache ou non.

Vérifions le résultat en appelant la page d'accueil de notre site pour la première fois :

Première requête : Varnish n'a rien en cache

Étant donné que c'est la première fois que l'on accède à la ressource, Varnish ne possède pas la réponse dans son cache, ce qui est logique. Il appelle donc le backend normalement et stocke le résultat pour une durée de 120 secondes (c'est la configuration par défaut de Varnish, vous pouvez bien sur le changer selon vos besoins). Si on actualise la page, on constate que Varnish réagit différemment :

Deuxième requête : Varnish retourne directement la réponse

Parfait ! Varnish a directement retourné le résultat qu'il avait stocké lors de la première requête. Le backend n'a purement pas été sollicité, vous n'aurez aucune trace d'accès dans les logs de votre serveur Web. Ça commence à ressembler à quelque chose.

🤓 « Mais si mon contenu varie en fonction de l'utilisateur... Je ne veux pas retourner le même contenu pour tout le monde. Comment faire ? »

C'est là qu'interviennent les fragments ESI, qui sont selon moi une source de performance extrême tellement sous-côtée !

Mettre en cache des fragments de page avec le cache ESI

Il est possible de mettre en cache une partie de la page pendant une certaine durée grâce aux blocs de cache ESI (Edge Side Includes). Cette spécification a été écrite par Akamai et Oracle en 2001 dans le but de mettre en place des stratégies de cache différentes par "bloc". Par exemple : ma page possède un menu type navbar avec le nom de l'utilisateur connecté. Le reste de ma page est identique pour tout le monde et affiche une liste de produits. Je peux donc mettre en place un bloc qui va contenir le menu et mettre en cache tout le reste.

Assez de théorie, voyons comment ça se traduit dans une app :


<html>
    <body>
        <h1>Ma super app</h1>

        <!-- Le bloc du ESI est défini là -->
        <esi:include src="/mon-menu-prive.php"/>
    </body>
</html>

C'est aussi simple que ça ! On peut le voir un peu comme un appel Ajax qui serait fait pour chaque bloc, sauf que c'est le reverse-proxy (Varnish) qui fait la requête, vous ne verrez pas de balise <esi> dans le code source généré.

Un cas d'étude concret

On va mettre en place une petite app PHP qui sera composée de plusieurs blocs. Certains blocs vont varier en fonction de l'utilisateur (ex: un menu), d'autres seront publics. La durée de mise en cache des blocs va aussi être variable.

La magnifique démo de cet article : 👉 https://labs.silarhi.fr/esi/

Entrons dans le vif du sujet, voici le code :

<?php
// index.php
header('Surrogate-Control: abc=ESI/1.0');
header('X-Reverse-Proxy-TTL: 10');
?>

<html lang="fr">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@tabler/core@1.7.1/dist/css/tabler.min.css">
    <title>Ma super page</title>
</head>
<body>
<main class="container my-4">
    <esi:include src="/menu.php" />
    <esi:include src="/time.php" />
    <div class="row">
        <div class="col-lg-8">
            <h1>Contenu public de la page</h1>
            <p>Mis en cache à <?= date('H:i:s') ?> (10s)</p>
        </div>
        <div class="col-lg-4">
            <esi:include src="/user.php" />
            <esi:include src="/sidebar.php" />
        </div>
    </div>
</main>
</body>
</html>

Ne vous focalisez pas encore trop sur le détail de ce code, l'idée est juste d'imaginer la mise en place de vos propres blocs dans votre application. La démo en ligne ajoute autour de chaque fragment un cadre qui affiche sa politique de cache et le temps qu'il lui reste : le code complet est sur GitHub.

Outre ce design de qualité, vous avez sûrement identifié les 4 tags <esi> :

Le menu du haut (menu.php)
L'heure du serveur avec la légende (time.php)
L'heure de la dernière connexion (user.php)
Les widgets (sidebar.php).

4 blocs pour 4 politiques de mise en cache différentes. C'est le mélange de la configuration dans Varnish et l'envoi d'entêtes HTTP de réponses par le backend qui vont nous permettre de mettre en place ces différentes politiques.

Configuration dans Varnish

# /etc/varnish/default.vcl
vcl 4.1;

import std;
import cookie;

backend default {
    .host = "127.0.0.1";
    .port = "8000";  # Le port d'écoute de votre serveur Apache / Nginx
}

# Appelé au début de chaque requête
sub vcl_recv {
    # Pas de mise en cache pour les méthodes type POST / DELETE
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }

    if (req.restarts > 0) {
        set req.hash_always_miss = true;
    }

    # Connexion / déconnexion : jamais en cache, elles modifient la session
    if (req.url ~ "^/(login|logout)\.php") {
        return (pass);
    }

    # On supprime les cookies sur les pages publiques (cf vcl_hash)
    if (req.url !~ "^/(menu|user)\.php") {
        unset req.http.cookie;
    }

    # On supprime tous les autres cookies que ESISESSID (la session de la démo) pour les pages privées
    if (req.http.cookie) {
        cookie.parse(req.http.cookie);
        cookie.keep("ESISESSID");
        set req.http.cookie = cookie.get_string();

        if (req.http.cookie == "") {
            unset req.http.cookie;
        }
    }

    return (hash);
}

# Appelé pour calculer un hash de la requête
sub vcl_hash {
    hash_data(req.url);

    if (req.http.host) {
        hash_data(req.http.host);
    } else {
        hash_data(server.ip);
    }

    if (req.http.Cookie) {
        hash_data(req.http.Cookie);
    }
}

# Appelé si le hash a été trouvé (= page en cache)
sub vcl_hit {
    if (obj.ttl >= 0s) {
        return (deliver);
    }

    return (restart);
}

# Appelé au retour de la réponse par le backend
sub vcl_backend_response {
    # L'entête est envoyée par index.php
    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        unset beresp.http.Surrogate-Control;
        set beresp.do_esi = true;
    }

    # Notre fameuse entête custom
    if (beresp.http.X-Reverse-Proxy-TTL) {
        set beresp.ttl = std.duration(beresp.http.X-Reverse-Proxy-TTL + "s", 0s);
        unset beresp.http.X-Reverse-Proxy-TTL;
    }

    return (deliver);
}

# Appelé à la fin de chaque réponse (en cache ou non)
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }

    set resp.http.X-Cache-Hits = obj.hits;

    return (deliver);
}

Il y a plusieurs concepts clés à comprendre dans cette configuration.

L'idée de fond est de générer un hash unique pour chaque requête / sous-requête. Ce hash doit dépendre du contexte utilisateur lorsque le contenu est censé être privé, en revanche il n'est pas nécessaire pour les blocs publics.

En PHP, l'utilisateur est lié à sa session via un cookie : PHPSESSID par défaut, que la démo renomme en ESISESSID (on verra pourquoi avec lib.php). C'est cette valeur de cookie que l'on doit conserver pour générer ce fameux hash unique dans les pages qui nous intéressent. Pour les autres pages, on peut se permettre de supprimer ce cookie dans le calcul du hash pour maximiser les chances de délivrer un contenu mis en cache par un autre utilisateur.

On supprime également les cookies non utiles au backend (du type Google Analytics etc) qui vont faire baisser le taux de HIT pour rien. Depuis Varnish 6.4, le module cookie est fourni avec Varnish : cookie.keep() remplace avantageusement les regsuball() illisibles que l'on trouvait partout. Adaptez bien sûr la fonction vcl_recv en fonction de vos besoins.

Les pages login.php et logout.php ne passent jamais par le cache (return (pass)) : elles modifient la session, leur réponse ne doit être ni stockée ni partagée.

L'illustration ci-dessous résume bien les différentes étapes pendant lesquelles nous devons agir :

Crédits : Varnish Basics

lib.php

<?php
// lib.php : inclus par les fragments privés, login.php et logout.php

// Pas PHPSESSID : une autre app PHP du même domaine utilise sûrement déjà ce nom
const SESSION_NAME = 'ESISESSID';

function session_open(): void
{
    session_name(SESSION_NAME);
    session_set_cookie_params(['httponly' => true, 'samesite' => 'Lax']);
    session_start();
}

// En lecture seule, et seulement si le visiteur a déjà une session
function session_read(): array
{
    if (!isset($_COOKIE[SESSION_NAME])) {
        return [];
    }

    session_open();
    $session = $_SESSION;
    session_write_close();

    return $session;
}

Deux pièges à éviter avec les sessions et un cache partagé.

Le nom du cookie : si une autre application tourne sur le même domaine (la démo CI de labs.silarhi.fr, en Symfony), elle utilise elle aussi PHPSESSID. Les deux apps se retrouvent alors avec le même identifiant de session, et se déconnectent l'une l'autre. Un nom de cookie propre à l'app règle le problème.

Le session_start() dans un fragment en cache : pour un visiteur anonyme, il crée une session et envoie un Set-Cookie que Varnish stocke avec le fragment. Quiconque appelle ce fragment directement pendant sa durée de cache reçoit alors le même identifiant de session. On ne lit donc la session que si le visiteur en a déjà une.

sidebar.php

<?php
// sidebar.php
header('X-Reverse-Proxy-TTL: 20');
?>
<section class="card">
    <div class="card-body">
        <h3>Widgets publics</h3>
        <p>Mis en cache à <?= date('H:i:s') ?> (20s)</p>
    </div>
</section>

Politique de mise en cache : Contenu public mis en cache pendant 20 secondes.

C'est l'entête X-Reverse-Proxy-TTL qui va donner la durée de mise en cache par Varnish. Cette entête n'est pas standard. On aurait pu jouer avec l'entête standard Cache-Control, mais elle possède un inconvénient majeur : On ne contrôle plus la propagation du cache avec la directive Cache-Control: public, s-maxage=20.

Eh oui, il peut y avoir d'autres serveurs mandataires entre le client et votre serveur qui peuvent eux-aussi mettre en cache le contenu HTML avec cette directive. Et si vous mettez des grandes valeurs de TTL dans votre politique de Cache-Control, adieu la maîtrise de vos mises à jour. Mieux vaut rester maître de la diffusion de vos contenus.

En revanche, pour vos contenus type Images/CSS/JS, faites vous plaisir et laissez le cache-control public avec un grand TTL si vous maîtrisez le cache busting.

menu.php

<?php
// menu.php
require __DIR__.'/lib.php';

header('X-Reverse-Proxy-TTL: 60');
$logged = session_read()['logged'] ?? false;
?>
<nav class="card">
    <div class="card-body d-flex align-items-center justify-content-between">
        <?php if ($logged): ?>
            <span class="badge bg-success">Connecté</span>
            <a class="btn" href="logout.php">Déconnexion</a>
        <?php else: ?>
            <span class="badge bg-secondary">Anonyme</span>
            <a class="btn btn-primary" href="login.php">Connexion</a>
        <?php endif; ?>
        <span>Mis en cache à <?= date('H:i:s') ?> (60s)</span>
    </div>
</nav>

Politique de mise en cache : Contenu privé mis en cache pendant 60 secondes

La mise en cache du contenu en fonction de l'utilisateur sera gérée dans Varnish directement. Le truc étant d'inclure le ESISESSID de l'utilisateur dans le calcul du "hash" d'une requête pour ce bloc-ci : vcl_recv ne garde que ce cookie, et vcl_hash l'ajoute au hash.

time.php

<?php
// time.php
?>
<section class="card">
    <div class="card-body">
        Heure serveur : <?= date('d/m/Y H:i:s') ?> (pas de cache)
    </div>
</section>

Politique de mise en cache : Contenu public sans mise en cache particulière.

Le backend est appelé systématiquement pour ce bloc (j'ai changé la configuration de base de Varnish pour mettre le TTL par défaut à 0s).

user.php

<?php
// user.php
require __DIR__.'/lib.php';

$session = session_read();
?>
<section class="card">
    <div class="card-body">
        <?php if ($session['logged'] ?? false): ?>
            Dernière connexion il y a <?= time() - $session['last_login'] ?>s
        <?php else: ?>
            Pas de dernière connexion
        <?php endif; ?>
    </div>
</section>

Politique de mise en cache : Contenu privé sans mise en cache particulière.

Le backend est appelé systématiquement pour ce bloc.

login.php

<?php
// login.php
require __DIR__.'/lib.php';

session_open();
session_regenerate_id(true);
$_SESSION['logged'] = true;
$_SESSION['last_login'] = time();

header('Location: ./', true, 303);

Un système de login maison très classique, à deux détails près.

session_regenerate_id() donne un nouvel identifiant de session à la connexion : c'est la protection classique contre la fixation de session, mais c'est aussi ce qui change la clé de cache de menu.php. Sans lui, un visiteur qui avait déjà une session continuerait à voir le menu « Anonyme » jusqu'à 60 secondes après s'être connecté.

La redirection est une 303 et pas une 301 : une redirection permanente peut être mise en cache par le navigateur, qui ne rappellerait alors plus jamais login.php.

logout.php

<?php
// logout.php
require __DIR__.'/lib.php';

if (isset($_COOKIE[SESSION_NAME])) {
    session_open();
    $_SESSION = [];
    session_destroy();

    // Même chemin et mêmes options que le cookie de session, sinon le navigateur le garde
    $params = session_get_cookie_params();
    unset($params['lifetime']);
    setcookie(SESSION_NAME, '', ['expires' => time() - 3600] + $params);
}

header('Location: ./', true, 303);

Il y a une particularité importante ici : On détruit entièrement le cookie de la session PHP pour que Varnish ne nous retourne pas l'ancien contenu utilisateur mis en cache qui n'a plus de raison d'exister.

Et avec Docker ?

La démo tourne avec Docker Compose : un conteneur PHP + Apache, et Varnish devant. Le backend du VCL n'est plus 127.0.0.1:8000 mais le nom du service PHP : .host = "esi-php" et .port = "80".

# docker-compose.yaml
services:
  esi-php:
    image: silarhi/php-apache:8.5
    volumes:
      - ./php:/app:ro

  varnish:
    image: varnish:8.0-alpine
    # -t 0 : TTL par défaut à 0s, seules les réponses avec X-Reverse-Proxy-TTL sont mises en cache
    command: [ "varnishd", "-F", "-f", "/etc/varnish/default.vcl", "-t", "0" ]
    depends_on:
      - esi-php
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    ports:
      - '8080:80'

Le depends_on n'est pas là pour faire joli : Varnish résout le nom du backend au chargement du VCL, il refuse donc de démarrer tant que le conteneur PHP n'existe pas. Pensez aussi à redémarrer Varnish quand vous modifiez le VCL : il n'est compilé qu'au démarrage.

Le mot de la fin

On a vu comment mettre en place plusieurs stratégies de cache différentes en fonction des types de blocs de vos pages. N'hésitez pas à vous approprier le concept de la mise en cache HTTP avec les fragments ESI et à l'utiliser massivement pour réduire drastiquement le temps de réponse de vos belles pages Web.

C'est également une architecture qui peut s'installer progressivement dans votre app. Envie d'ajouter un widget qui fait des appels externes à des pages ? Mettez en place un fragment ESI !

Ressources

Une image Docker PHP + Apache sur mesure pour la production

Guillaume Sainthillier — Mon, 25 Feb 2019 14:53:00 +0000

C'est quoi une image Docker parfaite ?

C'est avant tout une image établie selon votre besoin et votre expérience. Vous avez identifié des patterns communs de configuration qui se répètent au fil de vos développements. Et comme vous êtes quelqu'un de bien, vous voulez donc les regrouper dans une couche commune à toutes vos apps pour en faciliter la maintenance.

À partir de ma propre expérience et du type d'applications que je développe la plupart du temps, une image PHP Apache parfaite selon moi c'est :

Composer installé par défaut (qui n'utilise pas de gestionnaire de dépendances de nos jours ?).
PHP et Apache configurés pour la production.
Des modules PHP récurrents activés par défaut.
De jolies page d'erreurs type 404 un peu plus silencieuses que celles par défaut d'Apache.
Idéalement des variantes déjà prêtes pour des applications qui tournent avec Symfony.

Créer son image parfaite

En premier lieu on va partir de l'image officielle de php, parce qu'on veut gagner du temps et ne pas réinventer la roue. Vous savez quoi ? L'image est même fournie avec un serveur Apache intégré. TOP.

🤓 « Pourquoi utiliser Apache plutôt que nginx ? »

Parce que cet article n'est pas neutre et qu'il faut trancher. Personnellement, je trouve la différence de performances négligeables entre les deux et Apache convient parfaitement pour la plupart des projets. C'est également plus serein pour les mises à jour de sécurité qui seront directement effectuées par la team PHP Docker. Il m'arrive par contre pour des projets un peu plus importants d'utiliser nginx. Encore une fois, cela reste vraiment une question de besoin, d'expérience et de goûts.

On va donc commencer notre Dockerfile avec la ligne suivante :

# Dockerfile
FROM php:8.3-apache

On build et on run tout ça pour vérifier que tout va bien :

docker build -t super/hero .
docker run -it -p 8080:80 super/hero

En vous rendant sur http://127.0.0.1:8080 vous devez tomber sur une belle page 403. Ça veut bien dire que tout fonctionne, il n'y a pas encore vos sources donc Apache vous répond gentiement !

Composer par défaut

Rien de plus simple, on installe la dernière version de composer et on rend la commande accessible partout dans le conteneur.

# Dockerfile
ENV COMPOSER_ALLOW_SUPERUSER=1
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version

Configuration d'Apache

Par défaut, l'image officielle est configurée pour avoir la racine du serveur Web dans /var/www/html. Trop long ! On va ignorer tout ça et accueillir notre futur code source dans un dossier /app directement à la racine du conteneur.

# conf/vhost.conf
<VirtualHost *:80>
    ServerAdmin contact@monsupersite.fr

    DocumentRoot /app

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# conf/apache.conf
<Directory /app/>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

ServerTokens Prod
ServerSignature Off

# Dockerfile
# ...
COPY conf/vhost.conf /etc/apache2/sites-available/000-default.conf
COPY conf/apache.conf /etc/apache2/conf-available/z-app.conf
RUN a2enconf z-app

On a changé ici la configuration du vhost de base d'Apache (000-default.conf), qui délivre maintenant le contenu du dossier /app. On configure aussi le dossier /app pour ne pas autoriser Apache de lister les fichiers d'un répertoire avec Options -Indexes.

Pour ma part, je n'aime pas configurer mes sites avec un .htaccess (pour des raisons de performance). C'est pourquoi j'ai placé la directive AllowOverride None. Comme l'image est destinée pour le staging / production, j'ai aussi supprimé les infos sur l'infrastructure utilisée avec les directives ServerTokens Prod et ServerSignature Off.

J'ai volontairement nommé la configuration z-app pour être sûr qu'elle soit chargée en dernier et qu'aucun autre module ne vienne surcharger les instructions.

Configuration de PHP

On va configurer PHP selon les besoins récurrents de nos futures images. Ne mettez pas de valeurs trop importantes ici, si un de vos conteneurs en particulier a besoin d'une configuration plus véloce, vous pourrez override cette configuration de base dans le Dockerfile propre à cette app.

; conf/php.ini
date.timezone = Europe/Paris

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.revalidate_freq = 0
apc.enable_cli = On

upload_max_filesize = 16M
post_max_size = 16M

realpath_cache_size = 4096k
realpath_cache_ttl = 7200

display_errors = Off
display_startup_errors = Off

# Dockerfile
# ...
RUN apt-get update -qq && \
    apt-get install -qy \
    git \
    gnupg \
    unzip \
    zip 
RUN docker-php-ext-install -j$(nproc) opcache pdo_mysql
COPY conf/php.ini /usr/local/etc/php/conf.d/app.ini

Adaptez les modules par défaut qui vous semblent essentiels. Pour moi, la quasi totalité de mes projets utilisent PDO et MySQL. OPCache est bien sûr par défaut également.

Des jolies pages d'erreur par défaut

Qui ne s'est jamais retrouvé devant la page 404 par défaut d'Apache ? C'est l'assurance de perdre la crédibilité du ninja DevOp big data pro de baby-foot et autres buzzwords que vous êtes auprès de votre client. On va donc modifier la conf existante pour ajouter la gestion des pages d'erreurs :

# conf/apache.conf
# ...
<Directory /errors/>
    Options -Indexes
    AllowOverride None
    Require all granted
</Directory>

Alias /_errors/ /errors/
ErrorDocument 404 /_errors/404.html
ErrorDocument 403 /_errors/403.html
ErrorDocument 500 /_errors/500.html

# Dockerfile
# ...
COPY errors /errors

Pour ne pas causer de conflits avec les futures apps, j'ai placé le contenu des pages d'erreur dans un dossier à part (/errors à la racine du conteneur) et j'isole les requêtes HTTP spécifiques à ces pages via le chemin /_errors.

Vous pouvez récupérer directement le contenu du dossier errors dans le repo Github du tuto.

Ça donne quoi au final ?

Le Dockerfile a été optimisé pour réduire la taille des couches.

# Dockerfile
FROM php:8.3-apache

ENV COMPOSER_ALLOW_SUPERUSER=1

EXPOSE 80
WORKDIR /app

# git, unzip & zip are for composer
RUN apt-get update -qq && \
    apt-get install -qy \
    git \
    gnupg \
    unzip \
    zip && \
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer && \
    apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# PHP Extensions
RUN docker-php-ext-install -j$(nproc) opcache pdo_mysql
COPY conf/php.ini /usr/local/etc/php/conf.d/app.ini

# Apache
COPY errors /errors
COPY conf/vhost.conf /etc/apache2/sites-available/000-default.conf
COPY conf/apache.conf /etc/apache2/conf-available/z-app.conf
COPY index.php /app/index.php

RUN a2enmod rewrite remoteip && \
    a2enconf z-app

# conf/apache.conf
<Directory /app/>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted

    SetEnvIf X_FORWARDED_PROTO https HTTPS=on
</Directory>

ServerTokens Prod
ServerSignature Off

<Directory /errors/>
    Options -Indexes
    AllowOverride None
    Require all granted
</Directory>

Alias /_errors/ /errors/
ErrorDocument 404 /_errors/404.html
ErrorDocument 403 /_errors/403.html
ErrorDocument 500 /_errors/500.html

# conf/vhost.conf
<VirtualHost *:80>
    ServerAdmin guillaume@silarhi.fr

    DocumentRoot /app

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

; conf/php.ini
date.timezone = Europe/Paris

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.revalidate_freq = 0
apc.enable_cli = On

upload_max_filesize = 16M
post_max_size = 16M

realpath_cache_size=4096k
realpath_cache_ttl=7200

display_errors = Off
display_startup_errors = Off

Curieux de voir le résultat ? J'ai mis en place rien que pour vous :

DEV Community: Guillaume Sainthillier

UX Icons JS : les icônes de Symfony UX, enfin en JavaScript, React et Vue

L'histoire d'une PR refusée

Une icône, quatre façons de l'afficher

C'est parti

Les détails qui m'ont donné du fil à retordre

Le même HTML, vraiment

Un export par icône, pour le tree-shaking

Et quand le nom de l'icône vient d'une API ?

ux:icons:lock, côté JavaScript

Et Preact ?

PHP 8.2 et Symfony 6.4

Ça donne quoi au final ?

Pour aller plus loin

L'authentification à double facteur avec Symfony (2FA)

Démo

Installation

Mise en place

Controller

security.yaml

L'authenticator

Le Subscriber

Pour aller plus loin

Gérez vos sites de production avec Traefik, Docker & Let's Encrypt

Traefik, c'est quoi ?

Installation de Traefik

Configuration de Traefik

L'ajout des apps Docker dans Traefik

Du concret

Modifier les informations de connexion à la base de données

Aller plus loin avec Traefik

Sécuriser le dashboard Traefik

Les middlewares à la rescousse

Forcer l'authentification avec auth

Rediriger www vers non-www avec redirectregex

Gérer des sous-repertoires avec stripprefix

Ressources

Le déploiement continu en production pour Symfony 8 avec Docker et CircleCI

Le déploiement continu, c'est quoi ?

Le cas d'étude

Dans le vif du sujet de la CD

La CD avec CircleCI

Le script de déploiement

L'hébergement sur la production

La gestion de la mise à jour

Pour aller plus loin

PicassoBundle : le composant image qui manquait à Symfony

En une ligne de Twig

C'est parti

Les détails qui m'ont donné du fil à retordre

La détection des dimensions

Les images prioritaires et le LCP

Les placeholders

Des loaders pour la vraie vie

Et pour les frontends headless ?

La purge du cache

Ça donne quoi au final ?

Pour aller plus loin

Gérer ses miniatures avec Symfony et Glide

Démo

Installation

Configuration

Mise en place

Le controller

L'extension Twig

Utilisation

Gestion des écrans retina

Aller plus loin

Pour aller plus loin

Coder sans jQuery ? Retour d'expérience

Mon retour d'expérience

Un zeste de contexte

La stack technique

Résultat

Utilisez Varnish et le cache ESI pour diviser le temps de réponse de votre site Web par 100

C'est parti

Un premier exemple : du contenu statique

Mettre en cache des fragments de page avec le cache ESI

Un cas d'étude concret

Configuration dans Varnish

`ux:icons:lock`, côté JavaScript

Forcer l'authentification avec `auth`

Rediriger www vers non-www avec `redirectregex`

Gérer des sous-repertoires avec `stripprefix`