Comment patcher une dépendance Composer sans la forker ?

Lorsque vous travaillez sur un projet PHP utilisant Composer pour la gestion des dépendances, il peut arriver que l’une de vos bibliothèques présente un bug ou nécessite une modification spécifique pour répondre à vos besoins. La solution immédiate qui vient souvent à l’esprit est de forker le dépôt, y apporter les modifications nécessaires, puis de l’utiliser comme source dans votre projet.

Cependant, cette approche n’est pas toujours idéale. Forker une dépendance signifie prendre en charge sa maintenance, suivre ses mises à jour et gérer les éventuelles incompatibilités futures. Cela peut rapidement devenir un fardeau, surtout si vous devez maintenir plusieurs forks.

Heureusement, il existe une alternative élégante : appliquer un patch directement sur la dépendance, sans avoir besoin de forker. Cette méthode vous permet de corriger ou modifier le comportement de la bibliothèque tout en continuant à bénéficier des mises à jour officielles.

Dans cet article, nous explorerons comment utiliser Composer et les outils associés pour appliquer des patchs à vos dépendances de manière efficace, maintenable et sans complexifier votre workflow. Que vous soyez développeur débutant ou expérimenté, cette technique pourra vous faire gagner du temps et simplifier la gestion de vos projets.

4 étapes pour réaliser votre patch

1 – Installation des packages nécessaires au patch

composer require cweagans/composer-patches symplify/vendor-patches --dev

2 – Préparer le fichier de patch

Dans le dossier de vos vendors, une fois le bon fichier identifié, créez une copie de ce dernier en le suffixant par « .old« 

cp vendor/package/toto/src/toto.php vendor/package/toto/src/toto.php.old

Il suffit maintenant de modifier le fichier « .php » et d’appliquer vos modifications.

Seuls les fichiers *.php sont chargés, et non les fichiers *.php.old. De cette manière, vous pouvez vous assurer que le nouveau code fonctionne correctement avant de générer les patchs.

3 – Création du patch

Exécuter la ligne suivante :

vendor/bin/vendor-patches generate

Cette ligne va générer un fichier dans le dossier patches, voici un exemple :

/patches/package-toto-src-toto.php.patch

Le chemin du patch est créé à partir du chemin du fichier original, ce qui garantit que le nom du patch est toujours unique.

De plus, la configuration pour cweagans/composer-patches est ajoutée à votre fichier composer.json :

{
    "extra": {
        "patches": {
            "package/toto": [
                "patches/package-toto-src-toto.php.patch"
            ]
        }
    }
}

4 – Réinstallation des package et vérification du patch

Il suffit de vérifier que tout fonctionne en remettant au propre le code.

Le plus simple est de supprimer le dossier vendor et de relancer l’installation des packages:

rm -Rf vendor
composer install

Et voilà, vous êtes maintenant un maître dans l’art de patcher vos dépendances sans tout casser (ou presque) ! Avec cette méthode, vous pourrez corriger des bugs plus vite que votre collègue ne corrige ses fautes de frappe dans Slack. Alors, à vos claviers, et que vos projets soient aussi stables qu’un serveur un vendredi soir à 18h ! 🚀

Laravel – Routes Signées

key, castle, security

Depuis la version 5.6, Laravel vous permet de mettre en place des URL dites signées, nous allons voir comment programmer tout cela.

Pourquoi utiliser des URL signées ?

Quelques exemples, vous souhaitez, par exemple, réaliser un sondage avec un lien unique, utilisable une seule fois, envoyé à chacun de vos utilisateurs. Ou encore, vous souhaitez confirmer une inscription à une newsletter.

Comment faire ?

Dans cet article, nous allons imaginer qu’un utilisateur a besoin de valider une information, mais que pour ce faire, il n’a pas besoin d’être connecté, mais nous devons être capables de l’identifier de manière unique et que l’information reste fiable.

Étape 1 : Utilisation du middleware "signed"

Pour Laravel < 11.x

Dans le fichier « Http/Kernel.php » ajouter le code suivant (il est possible que vous ayez déjà des middlewares inclus pour les routes).

					protected $routeMiddleware = [
 'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,
];

Pour Laravel >= 11.x

Ce middleware n’est plus à ajouté et il est directement intégré dans les routes (voir chapitre ci-dessous)

Étape 2 : Créer une route

Dans un fichier de gestion des routes, par exemple « route/web.php », on ajoute une route qui va prendre en compte le middleware « signed ».

					use Illuminate\Http\Request;

Route::get('newsletter/confirm/{email}/{user}', function ($email, $user) {
    if (! $request->hasValidSignature()) {
        abort(401);
    }
   // Action à ajouter
})->name('confirmation.email')->middleware(['signed']);

Générons aussi un moyen de créer un lien signé pour pouvoir faire des tests, le code ci-dessous est un exemple.

					use \Illuminate\Support\Facades\URL;

$url = URL::temporarySignedRoute('confirmation.email', now()->addHour(), [
    'email' => 'test@test.com',
    'user' => 1
]);

Étape 3 : Vérification de la route

La route est vérifiée automatiquement via la gestion des routes, si la signature n’est pas bonne, Laravel lèvera une erreur de type : Illuminate\Routing\Exceptions\InvalidSignatureException.

Comment est définie la signature ?

La signature est un hachage HMAC (sha256) de l’URL, elle utilise comme clé de chiffrement la clé secrète de l’application enregistrée dans le fichier .env de l’application.