Ssss... Ce n'est pas le son d'un serpent mais les initiales de <a href="https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir" target="_blank">Shamir's Secret Sharing Scheme</a>.&nbsp;Avant d'expliquer ce dont il s'agit, laissez-moi contextualiser.

Il y a un peu plus d'un an j'ai travaillé avec <a href="http://twitter.com/dunglas" target="_blank">Kévin Dunglas</a> sur <a href="https://api-platform.com/" target="_blank">API Platform</a>&nbsp;et à ce moment-là, il y avait des modifications à effectuer sur les conteneurs de la distribution. <a href="http://Mercure.rocks" target="_blank">Mercure.rocks</a> venait d'arriver et la restructuration nécessitait d'avoir du HTTP/2 + SSL pour bénéficier des capacités de HTTP/2 PUSH. Seulement, il y avait des problématiques de génération de certificats. Je savais comment générer les certificats mais je suis devenu curieux. J'ai voulu comprendre ce qu'il se passe vraiment&nbsp;lorsqu'un certificat est émis. Quelle est la mécanique derrière HTTPS ? Comment sont utilisés les certificats, et comment sont sécurisés les échanges ?

J'ai donc fait mes devoirs, et autant que d'autres en profitent. J'ai écrit une conférence dédiée à RSA, ainsi qu'une suite d'articles disponible en 3 parties :&nbsp;<a href="https://knot.gheb.dev/blog/rsa-tls-aes-wtf-part-1/" target="_blank">partie 1</a>, <a href="https://knot.gheb.dev/blog/rsa-tls-aes-wtf-part-2/  " target="_blank">partie 2</a> et <a href="https://knot.gheb.dev/blog/rsa-tls-aes-wtf-part-3/  " target="_blank">partie 3</a>.&nbsp;Cette suite d'articles a ensuite donné lieu à une conférence (pour ceux qui n'ont pas le courage de lire)&nbsp; :&nbsp;

<center><iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/GTy3aelf7AI" width="560"></iframe></center>

Dans un autre registre d'opportunité, j'ai eu la chance de participer à un <a href="https://les-tilleuls.coop/fr/blog/article/hackathon-eu-fossa-2019" target="_blank">hackathon Symfony / API Platform&nbsp;organisé par la Commission Européenne</a>&nbsp;durant&nbsp;lequel un nouveau composant Symfony est né. Composant... une nouvelle fonctionnalité plutôt, parce que techniquement ce n'est pas un composant indépendant. Mais je vais continuer de dire composant quand même, c'est&nbsp;le composant «&nbsp;secrets&nbsp;». &nbsp;

Il permet de chiffrer vos secrets (comme un mot de passe de base de données), et il est d'ailleurs très pratique lorsque vous manquez de confiance envers votre hébergeur, ou tout simplement parce que vous êtes soucieux de la sécurité et qu'il n'est pas possible pour vous d'utiliser de variable d'environnement sur votre serveur. &nbsp;

Il utilise une librairie C (<a href="https://libsodium.gitbook.io/doc/" target="_blank">libsodium</a>) à travers une API dédiée en PHP et il se trouve que les méthodes de chiffrements utilisées par libsodium&nbsp;pour le composant «&nbsp;secrets&nbsp;»&nbsp;sont les mêmes algorithmes que ceux utilisées dans RSA !&nbsp;J'avais donc la possibilité de promouvoir cette fonctionnalité tout en expliquant les mécaniques sous-jacentes. Chose qui m'a été offerte lors du <a href="https://www.youtube.com/watch?v=w3PcUa9qzME" target="_blank">Symfony World 2020</a>&nbsp;où j'ai pu confronter mes connaissances, lors de différents échanges avec d'autres contributeurs de Symfony.

L'un d'eux (coucou Jérémy !) m'a alors fait la réflexion suivante : "avant il y avait des secrets dans un fichier connu que du serveur. Maintenant, il y a des secrets chiffrés dans un fichier connu de tous, mais déchiffrable uniquement avec la clé connue que du serveur. Dans les 2 cas, que se passe-t-il si je n'ai pas confiance en mes fournisseurs ? Que ce soit un serveur classique, ou des conteneurs dans le cloud, il faut que la clé soit déposée quelque part. Je n'ai pas de solution parfaite encore pour protéger cette clé...". C'est alors que je me suis souvenu avoir vu <a href="https://www.youtube.com/watch?v=K54ildEW9-Q" target="_blank">une vidéo d'un mathématicien</a> : Matt Parker. Dans cette vidéo il explique un principe mathématique permettant de diviser un secret en une multitude de morceaux, trois, cinq, douze. Mais n'ayant besoin que d'un certain minimum de morceaux pour reconstruire l'intégralité du secret.

Je me suis demandé si ça ne pouvait pas être une solution. Et il se trouve que oui. Par ailleurs, l'excellent VaultProject.io de HashiCorp utilise <a href="https://www.vaultproject.io/docs/internals/security#internal-threat-overview" target="_blank">cette même technique pour protéger les clés</a>. Je me suis dit que ce serait top si ça existait en PHP ! Et puis j'ai oublié de chercher dans Google.&nbsp;Je suis allé voir des revues mathématiques et&nbsp;j'ai rien compris. Je suis allé lire des pages Wikipédia et&nbsp;j'ai&nbsp;rien compris. J’ai ouvert des pages, et autres articles de blogs vulgarisateurs, j'ai compris un peu. J'ai revu la vidéo de Matt Parker, je l'ai un peu plus comprise, puis j'ai réouvert Wikipédia que j'ai compris et enfin, j'ai réouvert les revues mathématiques et je n’ai toujours pas compris. Alors pourquoi ça marche ?

<h3>jingle&nbsp;Tuto rapide !</h3>

Prenons mon mot de passe de session d'ordinateur : «&nbsp;peanuts!&nbsp;»&nbsp; Je vais envoyer des pièces incomplètes à des tiers :

<ul>
	<li>p _ _ nu _ _ _&nbsp;</li>
	<li>_&nbsp;e _&nbsp; _&nbsp;_ t _ !&nbsp;</li>
	<li>p _ a _ _ _ s _</li>
</ul>

En combinant les 3 morceaux, je peux reconstituer la valeur d'origine mais avec seulement 2, il va me manquer des éléments.&nbsp;

Disons que je crée plus de variations, je peux alors imaginer qu'il y ait un certain nombre de lettres communes ainsi qu'un certain nombre de lettres absentes dans chaque variation. Cette valeur que j'aurais décidée au préalable me permet de contrôler le nombre de variations minimum dont j'ai besoin pour retrouver la valeur d'origine. Moins j'ai d'intersections entre les variations, plus j'ai besoin de morceaux, pour recomposer la valeur. Je peux ainsi donner mon mot de passe, sans qu'il ne soit mis en danger, à moins que les tiers ne décident de se concerter pour le décoder !

<h3>jingle&nbsp;Tuto costaud</h3>

<h4>Destructuring the secret</h4>

Sur le principe énoncé précédemment voilà comment les mathématiques sont appliquées. Nous allons transformer notre chaîne de caractères à subdiviser, en valeur numérique. Pour l'exemple, disons que mon mot de passe nous donne la valeur 42. Nous allons créer une fonction, dont la première entrée est notre valeur numérique :&nbsp;&nbsp;<img alt="f(x)=42" id="image" src="https://api.les-tilleuls.coop/upload/424" title="f(x)=42" />.

Sous cette forme, ça ne fait pas grand-chose. Nous allons y ajouter des valeurs. Une de moins que de "morceaux/parts" désirés pour pouvoir plus tard reconstruire la valeur. Si je m'impose de ne pouvoir reconstituer le secret qu'avec au moins k = 3 "morceaux", la fonction devient alors : <img alt="f(x)=a0+a1x+a2x^2+a3x^3" id="image" src="https://api.les-tilleuls.coop/upload/423" title="f(x)=a0+a1x+a2x^2+a3x^3" />.

De manière générale, la formule est :&nbsp;<img alt="f(x)=a0+a1x+a2x^2+a3x^3+...+ak-1x^k-1" id="image" src="https://api.les-tilleuls.coop/upload/425" title="f(x)=a0+a1x+a2x^2+a3x^3+...+ak-1x^k-1" /> (a0 étant notre secret). Ce type de fonction porte un nom : polynomiale. Il faut sélectionner pour chaque "degré" (le nom des valeurs) un nombre entier positif sélectionné au hasard. Par exemple, prenons des valeurs simples comme 3 puis 5 : <img alt="f(x)=42+3x+5x^2" id="image" src="https://api.les-tilleuls.coop/upload/426" title="f(x)=42+3x+5x^2" />

Que se passe-t-il si je passe 0 à notre fonction ? Vous l'avez tout de suite compris, les multiplications et les montées en puissance vont résulter à 0. Nous obtiendrons la seule valeur importante, notre secret. C'est l'opération que l'on souhaite effectuer à la fin, avoir été capable de reconstruire cette formule, pour pouvoir retrouver notre secret. Sur un graphe orthonormé, la formule résultera en une courbe avec laquelle lorsque l’on donne x = 0, y nous donnera la valeur du secret.

Partant de ce principe, nous allons donc aller chercher au moins 3 points sur cette courbe. Prenons 4 valeurs qui seront les x. 18, 27, 31, 35. La formule nous donne les y suivants : 1716, 3768, 4940, 6272. Soit les points (18, 1716), (27, 3768), (31, 4940) et (35, 6272).

Et maintenant ? &nbsp;Et bien, il est temps d'envoyer un point à chaque service/serveur/client de confiance ainsi que la valeur k, nécessaire pour la reconstruction.

<h4>Restructuring the secret</h4>

Nous possédons un point. C'est bien, mais ça ne nous indique rien. &nbsp;

Mais si nous connaissons le nombre d'entrées nécessaire pour la formule, alors en possédant autant de points dans l'espace il est possible de "deviner" la formule. Pour le faire, il faut utiliser l'interpolation polynomiale de Lagrange. Je vous passe la formule, mais si vous êtes curieux, <a href="https://en.wikipedia.org/wiki/Lagrange_polynomial" target="_blank">elle est ici</a>.&nbsp;Une fois reconstruite, vous aurez compris qu'en donnant la valeur 0 à cette formule, nous devrions retomber sur notre secret !

Il reste un détail crucial à couvrir. Sans connaitre k, il n'est pas vraiment possible de reconstruire la formule, mais, si un attaquant arrive à se procurer un nombre suffisamment grand de points générés. Alors il réduit la marge d'erreur et peut lui aussi finir par deviner la courbe. S’il obtient k, alors des méthodes mathématiques lui permettent de déduire certaines valeurs, les unes après les autres.

Ceci est possible parce que nos points représentent exactement des valeurs supérieures à notre secret.

Pour contourner ce problème, il faudra ajouter une opération modulo à notre formule pour brouiller les pistes. Sans la valeur des points, ni de k, ni du modulo, impossible de reconstruire la formule ni de deviner les emplacements réels. Pour bien faire la valeur du modulo sera un nombre premier bien entendu.

<h3>De la théorie à la pratique ?</h3>

Let's make baby steps with PHP. Créez&nbsp;le nécessaire pour constituer la formule.

<pre>
<code class="language-php">// split into N shares here 3 for example it mean I need a polynomial function of degree 2. (k-1)
$k = $minShares; 
$m = $modulo; 

// including our secret, we need 2 more numbers at random to plot our function.
// they are coefficient, no real needs to be high.
$numbers = array_map(static function () {
 return (string) random_int(0, 99);
}, array_fill(0, $k - 1, null));

$polynomial = new Polynomial([...$numbers, $secret], $m);

// let generate N points to dispatch
$points = array_map(static function () use ($polynomial) {
 $rand = random_int(0, 100);
 return ["$rand", $polynomial("$rand"), $polynomial-&gt;quotient];
}, array_fill(0, $maxShares, null));

return $points;</code></pre>

<a href="https://github.com/GregoireHebert/ShamirSecretSharingScheme/blob/f43f6c8d3abd76c397199c51aa6117167017bcdd/src/Polynomial/Polynomial.php," target="_blank">L'objet Polynomial</a>&nbsp;est issu du travail de Mark Rogoyski que j'ai revu pour mes besoins. C'est lui qui porte la responsabilité de créer la fonction et de l'exécuter. Avec ces points, il faut à présent être capable de reconstituer la fonction.

<pre>
<code class="language-php">$lp = LagrangePolynomial::interpolate($points, $m);
$secret = $lp('0', false);</code></pre>

L'objet LagrangePolynomial est lui aussi issu du travail de Mark Rogoyski, également revu pour mes besoins.&nbsp; Premier essai après quelques heures, j'obtiens les points, et j'obtiens de nouveau le secret !

Proof Of Concept réussi&nbsp;et du premier coup ! Attendez… c'est louche. J'ai tenté les mêmes valeurs que celles de mon exemple (42). Dans un cas réel, j'aurais plutôt une clé probablement générée par LibSodium.&nbsp;

<pre>
<code class="language-php">$secretKey = SodiumHelper::generateKey(); // this will be stored in shares.
$nonce = SodiumHelper::generateNonce(); // this could be part of your app configuration

$secret = 'Sensitive information';
var_dump("secret : $secret");

// symmetric key encryption with padded message to hide it's length. This does not matter, it's for show !
$encryptedMessage = SodiumHelper::encrypt($secret, $secretKey, $nonce);

$number = gmp_import($encryptedMessage);
$valueToPlot = gmp_strval($number);</code></pre>

et j'obtiens plutôt des valeurs comme&nbsp;1472502186037957747441234705645302953943147992477563238054054428338355254101.&nbsp;Un peu plus important que 42. Voyons si les maths tiennent la route. NON&nbsp; Évidemment, le résultat explose littéralement. Après quelques coups de débogage, je constate que la génération des points est valide. C'est la suite qui se corse. En effet, l'interpolation polynomiale de Lagrange joue avec des additions (ça va), des multiplications (ça va), des divisions (oula !) sur de grandes valeurs... Et si vous n'avez pas encore vu <a href="http://https://www.youtube.com/watch?v=0iEKP4tsWe0" target="_blank">l'excellente conférence de Benoit Jacquemont sur le sujet</a> : allez-y, il y a de grandes chances que je sois dans cette situation !

Je ne me décourage pas j'essaie de trouver les raisons des erreurs. Même s’il y a des approximations, je dois pouvoir m'en sortir, je ne suis pas le premier à faire des calculs sur de grands nombres. Et ce n'est pas comme si je manipulais des flottants dès le départ ! Les approximations ne devraient pas être un problème dans ma situation.

Je remplace tous les calculs mathématiques par gmp car il semble tout indiqué, jusqu'au moment où j'arrive sur les opérations modulo. J'ai besoin de récupérer le quotient de l'opération, or rien ne le permet sans réeffectuer les calculs derrière. Qu'à cela ne tienne, allons-y. Manque de bol, j'ai de nouveau des soucis d'approximation.

Je remplace tous les calculs mathématiques par <a href="https://www.php.net/manual/fr/book.bc.php" target="_blank">bcmath</a>, l'autre solution qui semble aussi adaptée. Bon là, il y a un peu plus de travail, puisque bcmath manipule des strings. Je vais devoir modifier un peu plus que juste les opérations. À cœur vaillant, rien d'impossible, ça prendra juste un peu de temps. Rebelote. Problèmes d'approximation... C'est vraiment, vraiment pas cool PHP pour les maths.&nbsp;Je m'y prends peut-être mal, mais je suis alors pris d'une frénésie, et me lance même dans la ré-écriture du code en R ! Mais il est tard... je mets en pause le dev.

Je reviens sur mes pas. Clairement en PHP, le plus à même de faire le job, c'est bcmath. Et je suis sûr que d'autres ont rencontré le problème, alors je décide d'aller à la boîte à outils, pour comprendre où l'approximation démarre. En PHP, l’approximation vient des Float et Double. Mais elle peut l’être moins grâce à l'écriture scientifique ! Et tant que je manipule des doubles ET l'écriture scientifique, sur le papier, je ne dois pas perdre en précision. Mais, Ô grand Mais, lorsque cette écriture scientifique est utilisée, particulièrement lors de l'usage de modulo, la chaîne numérique obtenue, est imprécise ! Caster en float, utiliser number_format&nbsp;ou utiliser sprintf&nbsp;d'un double en écriture scientifique, n'est pas précis sur des valeurs si grandes. Et croyez-moi j'ai écumé les discussions sur le sujet.

Il faut que je trouve une parade à l'écriture scientifique. Après des heures de recherche, <a href="https://github.com/krowinski/bcmath-extended" target="_blank">je trouve une librairie</a>&nbsp;qui apporte sa méthode de conversion de l'écriture scientifique ainsi que des ajustements des méthodes de bcmath. Exactement ce dont j'avais besoin (ouf pas besoin de l'écrire), si tant est qu'elle fonctionne et corrige mes problèmes d'approximation. Je l'importe et remplace... Je n'ose pas regarder la sortie du terminal... &nbsp;

Ça a marché ! Et me voici avec un prototype qui fonctionne !&nbsp;

<a href="http://https://github.com/GregoireHebert/ShamirSecretSharingScheme" target="_blank">Le dépôt est ici</a>,&nbsp; je partage le code aux collègues, c'est un réfllexe, j'ai des encouragements, c'est cool. On me demande si ça n'existe pas déjà, c'est aussi un réflexe. Je réponds que non, je ne me serais pas cassé la tête sinon... c'est pas cool. &nbsp;

Pas cool, parce que plus tard, je réalise que je n'ai jamais tapé les mots clés «&nbsp;shamir, secret, sharing, php&nbsp;» dans un moteur de recherche... J'ai foncé tête baissée. Oh je m'en veux. <a href="https://github.com/teqneers/shamir" target="_blank">Parce qu'il y a ça</a>&nbsp;et ça m'a pas l'air mal du tout&nbsp; : ce que j'aime c'est que le soin a été pris de couvrir les aspects critiques de la sécurité mathématique, avec l'application d'un modulo sur les résultats pour masquer la longueur du secret. C'est top. En prime, la librairie hash le résultat des morceaux pour n'avoir qu'une chaîne simple à stocker, tandis que pour l'instant mon code renvoie un tableau, mais ce ne serait pas très difficile à implémenter. Enfin, il y a un détail qui me fait un peu peur parce que je manque de connaissances mathématiques, c'est que sa librairie impose le choix du nombre premier utilisé dans l'exécution du modulo. L'intérêt de ce modulo est de brouiller les pistes, mais si en connaissant la librairie, on connait la valeur du modulo, je pense que cela perd complètement de son usage (mais je peux me tromper), tandis qu'au contraire, dans ma librairie, je demande à l'utilisateur de donner cette valeur, pour qu'elle puisse être différente d'une installation à une autre. Un peu plus de contraintes, pour un peu plus de sécurité. C'est à pondérer, et surtout à confirmer par quelqu'un de plus expert que moi.

<h3>Que pouvons-nous faire de cette technique ?</h3>

<ul>
	<li>Le plus évident puisque c'est pour ça que j'ai travaillé dessus : diviser et partager des clés privées. Par exemple, la clé utilisée&nbsp;pour les secrets de Symfony, ou encore la clé privée pour les token JWT (qui en passant <a href="https://blog.silentsignal.eu/2021/02/08/abusing-jwt-public-keys-without-the-public-key/" target="_blank">mérite une plus grande attention</a>).</li>
	<li><a href="https://www.researchgate.net/publication/325862750_Authentication_as_a_service_Shamir_Secret_Sharing_with_byzantine_components" target="_blank">L'Authentication As Service</a>.</li>
	<li>L'amélioration de la sécurité d'ouverture de salle <a href="https://www.researchgate.net/publication/342343321_Increasing_the_Security_of_RFID-based_Classroom_Attendance_System_with_Shamir_Secret_Share" target="_blank">par RFID</a>.</li>
</ul>

Laissez libre cours à votre imagination, je suis sûr que vous trouverez d'autres usages !

C'est un concept qui fonctionne, mais qui est encore un concept ici, je manque de validation de la part de chercheurs en sécurité. Mais je serai&nbsp;ravi d'en discuter ! Merci de m'avoir lu et à bientôt !

Mathématiques

Shamir's Secret Sharing Scheme

Shamir's Secret Sharing Scheme en PHP

<a href="https://dunglas.fr/2021/02/using-the-103-early-hints-status-code-in-go-applications/" target="_blank">Read the original version of this post</a>.

103 est un nouveau code de statut HTTP expérimental défini dans <a href="https://www.rfc-editor.org/rfc/rfc8297.html" target="_blank">la RFC 8297.</a> Il s'agit d'un statut informationnel qui peut être envoyé par un serveur avant la réponse HTTP principale. Utilisé en conjonction avec <a href="https://www.rfc-editor.org/rfc/rfc8288.html" target="_blank">l'en-tête HTTP Link</a> et <a href="https://www.w3.org/TR/preload/" target="_blank">la relation preload</a>, 103 donne au client la possibilité de récupérer des ressources (assets, images, documents liés à l’API...) liées à celles explicitement demandées, le plus tôt possible, alors que le serveur prépare la réponse principale. Early Hints ressemble à cela :

<pre>
HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script

[… le reste de la réponse est volontairement retiré de cet exemple …]</pre>

<h3>Early Hints en quelques mots</h3>

Le code de statut 103 Early Hints pourrait être une bonne alternative au <a href="https://dunglas.fr/2019/11/vulcain-http-2-server-push%E2%80%A8-and-the-rise-of-client-driven-rest-apis/" target="_blank">Server Push d’HTTP/2</a>, qui sera supprimé de Chrome dans un futur proche et <a href="https://github.com/httpwg/http2-spec/issues/786#issuecomment-776291594" target="_blank">déconseillé</a> dans la spécification d’HTTP/2. Il ajoute 1 <a href="https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip_Time_(RTT)" target="_blank">Round Trip Time (RTT)</a>&nbsp;par rapport au Server Push, mais, parmi d'autres avantages, il permet une meilleure mise en cache et est (théoriquement) plus facile à implémenter. Chrome et Fastly <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md" target="_blank">mènent une expérience</a> pour mesurer l'avantage potentiel de ce nouveau code de statut. Mais pour que cette expérience soit couronnée de succès, nous avons besoin de serveurs compatibles... et les serveurs attendent des navigateurs compatibles avant de mettre en œuvre ce nouveau code de statut. Nous sommes dans un problème typique de "l'œuf ou la poule".&nbsp;

<h3 dir="ltr">Go et les Early Hints</h3>

Comme vous le savez peut-être, chez Les-Tilleuls.coop, nous sommes attachés au sujet du préchargement des ressources appliqué aux APIs web. Nous sommes à l’origine du <a href="https://vulcain.rocks/" target="_blank">protocole Vulcain</a>, qui est une alternative à (certaines fonctionnalités de) GraphQL. Il permet de concevoir des APIs rapides et idiomatiques, orientées client, en suivant strictement le style architectural REST. Vulcain <a href="https://github.com/dunglas/vulcain/blob/main/spec/vulcain.md" target="_blank">supporte Early Hints depuis le départ</a>, et a été conçu en tenant compte de la compatibilité avec ce code de statut. Nous publierons bientôt une nouvelle révision de Vulcain prenant en compte le déclin du Server Push, et <a href="https://event.afup.org/afup-day-2021/afup-day-2021-lille/programme/#3687" target="_blank">Kévin Dunglas présentera en détails ce que cela changera pour le protocole lors de l'AFUP Day Lille 2021</a>.

Cependant, le serveur de passerelle Vulcain (l'implémentation de référence), ne supporte pas encore le nouveau code de statut. Les serveurs utilisant ce composant ne peuvent donc pas participer à l'expérience.

Comme le hub <a href="https://mercure.rocks/" target="_blank">Mercure.rocks</a>, le serveur de passerelle Vulcain est maintenant disponible en tant que module du <a href="https://caddyserver.com/" target="_blank">serveur web Caddy</a>. Cela a été rendu possible parce que Caddy et la bibliothèque qui implémente Vulcain sont tous les deux écrits en Go. Malheureusement, la bibliothèque standard de Go ne supporte pas encore le code de statut 103. Cela empêche d'utiliser Early Hints avec Caddy et Vulcain.

Afin d’avancer sur le sujet, nous avons soumis au projet Go des patchs mettant en œuvre la RFC <a href="https://github.com/golang/go/pull/42597" target="_blank">pour HTTP/1.1</a> et <a href="https://github.com/golang/net/pull/87" target="_blank">pour HTTP/2</a>. Ils ne sont pas encore mergés, mais comme <a href="https://blog.golang.org/go1.16" target="_blank">la version 1.16 de Go a été publiée il y a quelques jours</a>, cela pourrait bientôt atterrir dans la branche de développement. En attendant, il est déjà possible d'utiliser cette fonctionnalité dans vos propres projets Go, et c'est ce que nous verrons dans la suite de cet article !

La chaîne d'outils Go (en particulier le compilateur gc) a une caractéristique intéressante : <a href="https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary" target="_blank">elle crée des binaires liés statiquement par défaut</a>. Cela signifie qu'une fois compilés avec une version de développement de Go supportant la nouvelle fonctionnalité, vos binaires autonomes peuvent être déployés sans devoir changer quoi que ce soit sur vos serveurs.

Assurez-vous d'abord que <a href="https://golang.org/doc/install" target="_blank">la version stable de Go est installée</a>. Comme la chaîne d'outils de Go elle-même est écrite en Go, nous avons besoin de Go pour compiler Go. C'est ce qu'on appelle <a href="https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit#!" target="_blank">le processus de bootstrapping</a> (encore une histoire "d’œuf ou la poule").

Ensuite, clonez notre fork de Go et allez sur la branche contenant les changements requis pour HTTP/1.1 :

<pre>
<code class="language-go">
git clone https://github.com/dunglas/go.git dunglas-go
cd dunglas-go
git checkout feat/http-103-status-code</code></pre>

Cette branche contient le patch pour HTTP/1.1 mais pas pour HTTP/2. L'implémentation HTTP/2 de Go est stockée dans un module séparé : x/net/http2. Avant de créer notre version personnalisée de Go, nous devons récupérer la version corrigée de x/net/http2 et la regrouper dans la bibliothèque standard. Commencez par remplacer le paquet x/net par notre fork, et mettez à jour <a href="https://golang.org/ref/mod#vendoring" target="_blank">les dépendances vendored</a> :

<pre>
<code class="language-go">export GOROOT=$(pwd)
cd src/
go mod edit -replace="golang.org/x/net=github.com/dunglas/net@2f6bd1bb0ddb1202d12f52cd0bd643d4eeedf1ce"
go mod vendor
unset GOROOT</code></pre>

Ensuite, installez&nbsp;la commande bundle, et utilisez-la pour regrouper le module net/http :&nbsp;

<pre>
<code class="language-go">go get golang.org/x/tools/cmd/bundle
cd net/http/
$(go env GOPATH)/bin/bundle -o=h2_bundle.go -dst net/http -prefix=http2 -tags='!nethttpomithttp2' golang.org/x/net/http2</code></pre>

Le fichier h2_bundle.go a été remplacé par un bundle contenant notre patch.

Enfin, retournez dans le répertoire src/ et construisez la version Go adaptée au code de statut 103 :&nbsp;

<pre>
<code class="language-go">cd ../../
./make.bash</code></pre>

Notre compilateur Go “amélioré” est prêt !

<h3 dir="ltr">Exemple de programme&nbsp;</h3>

La mise en œuvre de l'exemple fourni dans la RFC est simple :

<pre>
<code class="language-go">// main.go
package main

import (
 "io"
 "log"
 "net/http"
)

func main() {
 helloHandler := func(w http.ResponseWriter, req *http.Request) {
 w.Header().Add("Link", "; rel=preload; as=style")
 w.Header().Add("Link", "; rel=preload; as=script")

 w.WriteHeader(103)

 // do your heavy tasks such as DB or remote APIs calls here

 w.WriteHeader(200)

 io.WriteString(w, "\n[... le reste de la réponse est volontairement retiré de cet exemple ...]")
 }

 http.HandleFunc("/hello", helloHandler)
 log.Fatal(http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil))
}
</code></pre>

Pour générer un certificat TLS approuvé localement&nbsp;(nécessaire pour utiliser HTTP/2), nous recommandons <a href="https://github.com/FiloSottile/mkcert" target="_blank">la commande mkcert</a> :&nbsp;

<pre>
mkcert -cert-file ./cert.pem -key-file ./key.pem localhost</pre>

Utilisez le build personnalisé de Go que nous avons créé pour compiler le programme, et lancez-le :&nbsp;

<pre>
<code class="language-go">/path/to/dunglas-go/bin/go build main.go
./main main
</code></pre>

Vous pouvez aussi exécuter go run main.go pour compiler et démarrer le programme avec une seule commande. Utilisez curl pour vérifier s'il fonctionne correctement.&nbsp;

Avec HTTP/1.1 :

<pre>
curl -v --http1.1 https://localhost/hello</pre>

et avec HTTP/2 :

<pre>
 curl -v https://localhost/hello</pre>

Vous devriez voir quelque chose comme ceci :

<pre>
<code class="language-go">[snip]
&lt; HTTP/2 103
&lt; link: ; rel=preload; as=style
&lt; link: ; rel=preload; as=script
&lt; HTTP/2 200
&lt; link: ; rel=preload; as=style
&lt; link: ; rel=preload; as=script
&lt; content-type: text/html; charset=utf-8
&lt; content-length: 79
&lt; date: Sat, 13 Feb 2021 09:47:27 GMT
&lt;

[snip]</code></pre>

<h3>Envoi d’Early Hints&nbsp;</h3>

Appeler plusieurs fois http.ResponseWriter.WriteHeader() provoquera une erreur avec l’exécution Go vanilla. Pour pouvoir compiler le même programme avec le compilateur stable et avec celui qui est patché, vous pouvez “envelopper” l'appel à http.ResponseWriter.WriteHeader(103) dans une condition :

<pre>
<code class="language-go">package main

import (
 "io"
 "log"
 "net/http"
 "runtime"
 "strings"
)

func main() {
 helloHandler := func(w http.ResponseWriter, req *http.Request) {
 w.Header().Add("Link", "; rel=preload; as=style")
 w.Header().Add("Link", "; rel=preload; as=script")

 if strings.HasPrefix(runtime.Version(), "devel") {
 // skip if compiled with a stable version of Go
 w.WriteHeader(103)
 }

 w.WriteHeader(200)

 io.WriteString(w, "\n[... le reste de la réponse est volontairement retiré de cet exemple ...]")
 }

 http.HandleFunc("/hello", helloHandler)

 log.Fatal(http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil))
}</code></pre>

<h3>103 Early Hints et HTTP/3</h3>

<a href="https://quicwg.org/base-drafts/draft-ietf-quic-http.html" target="_blank">HTTP/3</a> est la prochaine version du leader des protocoles web. Il devrait prochainement devenir une RFC. <a href="https://caniuse.com/http3" target="_blank">HTTP/3 est déjà activé par défaut dans Safari et il peut être activé manuellement dans Firefox et Chrome.</a>

Une implémentation expérimentale de HTTP/3 pour Go (qui est utilisée par Caddy et Vulcain) est disponible, mais elle ne prend pas en charge le code de statut 103. Une pull request a été ouverte pour ajouter le support de ce code de statut à <a href="https://github.com/lucas-clemente/quic-go" target="_blank">quic-go</a>. Pour utiliser le code de statut 103 avec HTTP/3 : <a href="https://github.com/lucas-clemente/quic-go/pull/3047" target="_blank">essayez ce patch</a>.&nbsp;

Et voilà ! Vous êtes prêt·e à créer des programmes supportant ce nouveau code de statut, et vous pouvez participer à cette expérience pour rendre le web plus rapide et plus vert ! Si vous vous en servez, prévenez-nous <a href="http://twitter.com/cooptilleuls" target="_blank">sur Twitter</a> ! Le serveur de passerelle Vulcain sera bientôt mis à jour pour supporter le code de statut 103 en utilisant l'approche que nous avons vue dans cet article. Testez les patches, et prévenez-nous si vous rencontrez le moindre souci !

Golang

Vulcain

Early ints

Utiliser le code de statut de réponse “103 Early Hints” dans les applications Go

A signed URL is a URL containing authentication information directly in its query string. It allows a non-authenticated user to access protected resources or routes, for a limited time.

Signing a URL can be very useful in a stateless application. There are two main use cases for using them:

<ul dir="ltr">
	<li>allowing an external user to access a resource otherwise not accessible without being authenticated,</li>
	<li>downloading a file with the browser without using Ajax (without a fetch() sending the authentication information).</li>
</ul>

The latter is the most common use case. Let's take an example: we have created a personal cloud where users can store their files. This application is built with a SPA for the front and communicates with a secured API by using a JWT token. Jean has uploaded a big video showing a live coding session of a nice feature in API Platform, and he wants to download it to watch it again.

The first reflex to implement this download feature in the SPA would be to do something like this:

<pre>
<code class="language-js">const res = await fetch('videos/d35e0296-7b19-42be-82f2-789213229f36/download', {
 headers: {
 Authorization: `Bearer ${localStorage.getItem('token')}`,
 Accept: 'application/octet-stream',
 },
});
const blob = await res.blob();
const objUrl = URL.createObjectURL(blob);
const link = document.createElement('a');
link.href = objUrl;
link.download = true;
link.click();
</code></pre>

This method has a lot of drawbacks:

<ul dir="ltr">
	<li>The browser download interface is used only after the file has been downloaded. We need to show Jean that a download is ongoing, for instance by adding a spinner somewhere. Jean cannot pause or cancel the download.</li>
	<li>The downloaded file is stored in memory until it is complete, which can cause performance issues if the file is too big.</li>
</ul>

To solve this, you could use the JWT token in the query string to download the video. Yes, <a href="https://tools.ietf.org/html/rfc6750#section-2.3" target="_blank">it is possible</a>, but it is a bad idea:

<ul dir="ltr">
	<li>A JWT token can be big. Big enough to exceed the URL length limit.</li>
	<li>You don't want the JWT tokens to show in your server logs. This is a security breach in your application that would facilitate a <a href="https://en.wikipedia.org/wiki/Session_hijacking">session hijacking</a> kind of attack.</li>
</ul>

That's why in this case, it is preferable to use a signed URL, like this:

<pre>
<code class="language-js">const res = await fetch('videos/d35e0296-7b19-42be-82f2-789213229f36/signed-url', {
 headers: {
 Authorization: `Bearer ${localStorage.getItem('token')}`,
 },
});
const { url } = await res.json();
const link = document.createElement('a');
link.href = url;
link.download = true;
link.click();
</code></pre>

That's way better: fetch() is only used to get the signed URL with authentication, signed URL which is then used directly to download the file. And of course you can also use this signed URL generation for adding a sharing feature, for instance if Jean wants his friends to download the video without being authenticated.

Laravel includes the <a href="https://laravel.com/docs/5.6/urls#signed-urls" target="_blank">generation of signed URLs</a> since its version 5.6, but there was no easy way to do it in Symfony.

With the <a href="https://github.com/coopTilleuls/UrlSignerBundle" target="_blank">UrlSignerBundle</a>, it has now been fixed!

So, how do we use it?

<h3 dir="ltr">Usage</h3>

First step, install the bundle. By using Symfony Flex, it's very straightforward:

<pre>
<code class="language-bash">composer req tilleuls/url-signer-bundle</code></pre>

Thanks to Flex, all the configuration has been done (see the config/packages/url_signer.yaml file).

Change the signature in the .env (or the .env.local) file:

<pre>
<code class="language-env">SIGNATURE_KEY=XAR5vxusewjY9KJ2w8apxVzVq5EPtl</code></pre>

Everything is ready to start using the bundle and to create your signed URL!

For instance in a controller, we will inject the UrlSignerInterface service and then use it to create a signed URL which will be returned in the JSON response of the /videos/{id}/signed-url route:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Controller;

use CoopTilleuls\UrlSignerBundle\UrlSigner\UrlSignerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class VideoController extends AbstractController
{
 public function __construct(
 private UrlSignerInterface $urlSigner,
 ) {}

 #[Route('/videos/{id}/signed-url', methods: ['GET'])]
 public function newSignedUrl(string $id): Response
 {
 $this-&gt;denyAccessUnlessGranted('ROLE_USER');

 return new JsonResponse(['url' =&gt; $this-&gt;generateSignedUrl($id)]);
 }

 private function generateSignedUrl(string $id): string
 {
 $url = $this-&gt;generateUrl('download_video', ['id' =&gt; $id]);
 // Will expire after 10 seconds.
 $expiration = (new \DateTime('now'))-&gt;add(new \DateInterval('PT10S'));

 return $this-&gt;urlSigner-&gt;sign($url, $expiration);
 }
}
</code></pre>

We can now retrieve a signed URL from the /videos/{id}/signed-url route. The signed URL will look like this:

/videos/d35e0296-7b19-42be-82f2-789213229f36/download?expires=1611316656&amp;signature=82f6958bd5c96fda58b7a55ade7f651fadb51e12171d58ed271e744bcc7c85c3

As you can see, the signed URL has two parameters:

<ul dir="ltr">
	<li>expires which contains the timestamp of the expiration date: the URL is no longer valid after this date.</li>
	<li>signature which is in fact the hash of the path, the expiration parameter and the secret.</li>
</ul>

The last step is to validate it when the route corresponding to the URL is accessed. We reuse our VideoController:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\BinaryFileResponse;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class VideoController extends AbstractController
{
 #[Route('/videos/{id}/download', name: 'download_video', defaults: ['_signed' =&gt; true], methods: ['GET'])]
 public function download(string $id): Response
 {
 // Get the file.

 return new BinaryFileResponse();
 }
}
</code></pre>

As you can see, we just added a _signed <a href="https://symfony.com/doc/current/routing.html#extra-parameters" target="_blank">extra parameter</a> to the route. It is this parameter that activates the signature validation when a request hits the route.

And that's it! If you access the download route without a signature or with an invalid signature, you will get a 403 response.

If you want to use signed URLs in API Platform, how do you do it? Well it's even easier!

It will look like this:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Controller\CreateSignedUrlVideoAction;
use App\Controller\DownloadVideoAction;

#[ApiResource(
 itemOperations: [
 'get',
 'delete',
 'put',
 'signed_url' =&gt; [
 'security' =&gt; "is_granted('ROLE_USER')",
 'method' =&gt; 'GET',
 'path' =&gt; '/videos/{id}/signed-url',
 'controller' =&gt; CreateSignedUrlVideoAction::class,
 ],
 'download' =&gt; [
 'method' =&gt; 'GET',
 'path' =&gt; '/videos/{id}/download',
 'controller' =&gt; DownloadVideoAction::class,
 'defaults' =&gt; ['_signed' =&gt; true],
 'formats' =&gt; ['binary'],
 ],
 ],
)]
class Video
{
 // Properties, getters, setters
}
</code></pre>

The signed_url operation creates the signed URL (and has authentication). The download operation allows users to download the video using the signed URL, with the extra _signed parameter that enables validation of the signed URL. The corresponding controllers are very similar to the previous VideoController controller.

<h3 dir="ltr">Features</h3>

There are of course other features in the bundle:

<ul dir="ltr">
	<li>The algorithm to sign the URL can be changed. By default, it is SHA-256.</li>
	<li>You can easily create your own Signer: extend the AbstractUrlSigner class, and you are done (you can use it by modifying the configuration in the config/packages/url_signer.yaml file)!</li>
	<li>The time before expiration is customizable (by default 24h).</li>
	<li>Parameter names in the signed URL are customizable.</li>
</ul>

<h3 dir="ltr">How does it work?</h3>

Internally the bundle uses the library <a href="https://github.com/spatie/url-signer" target="_blank">spatie/url-signer</a>.

Each Signer corresponds to an algorithm and extends an abstract class (AbstractUrlSigner) based on the Spatie URL signer. In a dedicated compiler pass, the configured signer is automatically aliased to the UrlSignerInterface.

For the validation, the method is really simple: an event listener is used. Each time a request is performed, it checks if the route has the _signed parameter. When it does, the signature is validated by the URL signer.

The bundle is very well tested: it has unit tests with PHPUnit and Prophecy and functional tests with Behat and the SymfonyExtension. The tests cover 100% of the code, and even better, the mutation score, calculated with the mutation testing framework <a href="https://infection.github.io" target="_blank">Infection</a> is also 100%.

And finally, the type coverage is 100% too, calculated by Psalm (PHPStan is also used).

If you need signed URLs in a Symfony or API Platform project, this bundle is for you! Feel free to test it, tell us what you think about it, and why not contribute to its development on GitHub: <a href="https://github.com/coopTilleuls/UrlSignerBundle" target="_blank">https://github.com/coopTilleuls/UrlSignerBundle</a>.

Symfony

Sécurité, mot de passe, phrase de passe, passphrase,

UrlSignerBundle, create and validate signed URLs with Symfony

Une URL signée est une URL contenant des informations d'authentification directement dans sa query string. Elle permet à un utilisateur non authentifié d'accéder à des ressources ou à des routes protégées, pour une durée limitée.

Signer une URL peut être très utile dans une application stateless. Il existe deux cas d'utilisation principaux&nbsp;:

<ul dir="ltr">
	<li>permettre à un utilisateur externe d'accéder à une ressource autrement inaccessible sans être authentifié,</li>
	<li>télécharger un fichier avec le navigateur sans utiliser Ajax (sans un fetch() envoyant les informations d'authentification).</li>
</ul>

Ce dernier cas est le plus courant. Prenons un exemple&nbsp;: nous avons créé un cloud personnel où les utilisateurs peuvent stocker leurs fichiers. Cette application est construite avec une SPA pour le front et communique avec une API sécurisée en utilisant un jeton JWT. Jean a ajouté une grosse vidéo montrant une session de codage en direct d'une fonctionnalité intéressante d'API Platform, et il veut la télécharger pour la regarder à nouveau.

Le premier réflexe pour implémenter cette fonctionnalité de téléchargement dans la SPA serait de faire quelque chose comme ça&nbsp;:

<pre>
<code class="language-js">const res = await fetch('videos/d35e0296-7b19-42be-82f2-789213229f36/download', {
 headers: {
 Authorization: `Bearer ${localStorage.getItem('token')}`,
 Accept: 'application/octet-stream',
 },
});
const blob = await res.blob();
const objUrl = URL.createObjectURL(blob);
const link = document.createElement('a');
link.href = objUrl;
link.download = true;
link.click();
</code></pre>

Cette méthode présente de nombreux inconvénients&nbsp;:

<ul dir="ltr">
	<li>L'interface de téléchargement du navigateur n'est utilisée qu'après le téléchargement du fichier. Nous devons montrer à Jean qu'un téléchargement est en cours, par exemple en ajoutant un spinner quelque part. Jean ne peut pas mettre en pause ou annuler le téléchargement.</li>
	<li>Le fichier téléchargé est stocké en mémoire jusqu'à ce qu'il soit complet, ce qui peut entraîner des problèmes de performance si le fichier est trop volumineux.</li>
</ul>

Pour résoudre ce problème, il serait possible d'utiliser le jeton JWT dans la query string pour télécharger la vidéo. Oui, <a href="https://tools.ietf.org/html/rfc6750#section-2.3" target="_blank">c’est possible</a>, mais c’est une mauvaise idée&nbsp;:

<ul dir="ltr">
	<li>Un jeton JWT peut être gros. Assez gros pour dépasser la limite de longueur de l'URL.</li>
	<li>Vous ne voulez pas que les jetons JWT apparaissent dans les logs de votre serveur. Il s'agit d'une faille de sécurité dans votre application qui faciliterait une attaque de type <a href="https://en.wikipedia.org/wiki/Session_hijacking" target="_blank">session hijacking</a>.</li>
</ul>

C'est pourquoi, dans ce cas, il est préférable d'utiliser une URL signée, comme ceci&nbsp;:

<pre>
<code class="language-js">const res = await fetch('videos/d35e0296-7b19-42be-82f2-789213229f36/signed-url', {
 headers: {
 Authorization: `Bearer ${localStorage.getItem('token')}`,
 },
});
const { url } = await res.json();
const link = document.createElement('a');
link.href = url;
link.download = true;
link.click();
</code></pre>

C'est beaucoup mieux&nbsp;: fetch() est uniquement utilisée pour obtenir l'URL signée avec de l’authentification, URL signée qui est ensuite utilisée directement pour télécharger le fichier. Et bien sûr, vous pouvez aussi utiliser cette génération d'URL signée pour ajouter une fonction de partage, par exemple si Jean veut que ses ami·e·s téléchargent la vidéo sans être authentifié·e·s.

Laravel inclut la <a href="https://laravel.com/docs/5.6/urls#signed-urls" target="_blank">génération d'URLs signées</a> depuis sa version 5.6, mais il n'y avait pas de moyen facile de le faire dans Symfony.

Avec le <a href="https://github.com/coopTilleuls/UrlSignerBundle" target="_blank">UrlSignerBundle</a>, c'est maintenant corrigé !

Alors, comment l'utiliser ?

<h3 dir="ltr">Utilisation</h3>

Première étape, installer le bundle. En utilisant Symfony Flex, c'est très simple&nbsp;:

<pre>
<code class="language-bash">composer req tilleuls/url-signer-bundle</code></pre>

Grâce à Flex, toute la configuration a été faite (voir le fichier config/packages/url_signer.yaml).

Puis changez la signature dans le fichier .env (ou .env.local)&nbsp;:

<pre>
<code class="language-env">SIGNATURE_KEY=XAR5vxusewjY9KJ2w8apxVzVq5EPtl</code></pre>

Tout est prêt pour commencer à utiliser le bundle et pour créer votre URL signée !

Par exemple dans un contrôleur, nous allons injecter le service UrlSignerInterface puis l’utiliser pour créer une URL signée qui sera retournée dans la réponse JSON de la route /videos/{id}/signed-url&nbsp;:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Controller;

use CoopTilleuls\UrlSignerBundle\UrlSigner\UrlSignerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class VideoController extends AbstractController
{
 public function __construct(
 private UrlSignerInterface $urlSigner,
 ) {}

 #[Route('/videos/{id}/signed-url', methods: ['GET'])]
 public function newSignedUrl(string $id): Response
 {
 $this-&gt;denyAccessUnlessGranted('ROLE_USER');

 return new JsonResponse(['url' =&gt; $this-&gt;generateSignedUrl($id)]);
 }

 private function generateSignedUrl(string $id): string
 {
 $url = $this-&gt;generateUrl('download_video', ['id' =&gt; $id]);
 // Expirera après 10 secondes.
 $expiration = (new \DateTime('now'))-&gt;add(new \DateInterval('PT10S'));

 return $this-&gt;urlSigner-&gt;sign($url, $expiration);
 }
}
</code></pre>

Nous pouvons maintenant récupérer une URL signée à partir de la route /videos/{id}/signed-url. L'URL signée ressemblera à ceci&nbsp;:

/videos/d35e0296-7b19-42be-82f2-789213229f36/download?expires=1611316656&amp;signature=82f6958bd5c96fda58b7a55ade7f651fadb51e12171d58ed271e744bcc7c85c3

Comme vous pouvez le constater, l’URL signée possède deux paramètres&nbsp;:

<ul dir="ltr">
	<li>expires qui contient le timestamp de la date d’expiration&nbsp;: l’URL n’est plus valide passée cette date.</li>
	<li>signature qui est en fait le hash du path, du paramètre d’expiration et du secret.</li>
</ul>

La dernière étape consiste à la valider lors de l'accès à la route correspondant à l'URL. Nous réutilisons notre VideoController&nbsp;:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\BinaryFileResponse;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class VideoController extends AbstractController
{
 #[Route('/videos/{id}/download', name: 'download_video', defaults: ['_signed' =&gt; true], methods: ['GET'])]
 public function download(string $id): Response
 {
 // Récupération du fichier.

 return new BinaryFileResponse();
 }
}
</code></pre>

Comme vous pouvez le voir, nous venons d'ajouter un <a href="https://symfony.com/doc/current/routing.html#extra-parameters" target="_blank">paramètre extra</a> _signed à la route. C’est ce paramètre qui active la validation de la signature lorsqu’une requête arrive sur à la route.

Et c'est tout ! Si vous accédez à la route de téléchargement sans signature ou avec une signature invalide, vous obtiendrez une réponse 403.

Si vous voulez utiliser des URLs signées dans API Platform, comment faire ? Et bien c'est encore plus facile !

Voici à quoi cela ressemblera&nbsp;:

<pre>
<code class="language-php">&lt;?php

declare(strict_types=1);

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Controller\CreateSignedUrlVideoAction;
use App\Controller\DownloadVideoAction;

#[ApiResource(
 itemOperations: [
 'get',
 'delete',
 'put',
 'signed_url' =&gt; [
 'security' =&gt; "is_granted('ROLE_USER')",
 'method' =&gt; 'GET',
 'path' =&gt; '/videos/{id}/signed-url',
 'controller' =&gt; CreateSignedUrlVideoAction::class,
 ],
 'download' =&gt; [
 'method' =&gt; 'GET',
 'path' =&gt; '/videos/{id}/download',
 'controller' =&gt; DownloadVideoAction::class,
 'defaults' =&gt; ['_signed' =&gt; true],
 'formats' =&gt; ['binary'],
 ],
 ],
)]
class Video
{
 // Propriétés, getters, setters
}
</code></pre>

L’opération signed_url permet de créer l’URL signée (et possède de l’authentification). L’opération download permet de télécharger la vidéo en se servant de l’URL signée, avec le paramètre extra _signed qui permet d’activer la validation de l’URL signée. Les contrôleurs correspondants sont très ressemblants au contrôleur VideoController précédent.

<h3 dir="ltr">Fonctionnalités</h3>

Il y a bien sûr d'autres fonctionnalités dans le bundle&nbsp;:

<ul dir="ltr">
	<li>L'algorithme de signature de l'URL peut être modifié. Par défaut, il s'agit de SHA-256.</li>
	<li>Vous pouvez créer facilement votre propre Signer&nbsp;: étendez la classe AbstractUrlSigner, et vous avez terminé (vous pouvez l’utiliser en modifiant la configuration dans le fichier config/packages/url_signer.yaml) !</li>
	<li>Le délai avant expiration est personnalisable (par défaut fixé à 24h).</li>
	<li>Les noms des paramètres dans l'URL signée sont personnalisables.</li>
</ul>

<h3 dir="ltr">Comment ça fonctionne ?</h3>

En interne le bundle utilise la bibliothèque <a href="https://github.com/spatie/url-signer" target="_blank">spatie/url-signer</a>.

Chaque Signer correspond à un algorithme et étend une classe abstraite (AbstractUrlSigner) basée sur le signer de Spatie. Dans un compiler pass dédié, le signer configuré est automatiquement aliasé par UrlSignerInterface.

Pour la validation, la méthode est très simple&nbsp;: un event listener est utilisé. Lors de chaque requête, il vérifie si la route a le paramètre _signed. Si c'est le cas, la signature est validée en utilisant le signer.

Le bundle est très bien testé&nbsp;: il dispose de tests unitaires avec PHPUnit et Prophecy et de tests fonctionnels avec Behat et la SymfonyExtension. Les tests couvrent 100% du code, et mieux encore, le score de mutation, calculé avec le framework de test de mutation <a href="https://infection.github.io" target="_blank">Infection</a> est également de 100%.

Enfin, la couverture des types est également de 100 %, calculée par Psalm (PHPStan est également utilisé).

Si vous avez besoin d'URLs signées dans un projet Symfony ou API Platform, ce bundle est fait pour vous ! N'hésitez pas à le tester, à nous dire ce que vous en pensez, et pourquoi pas à contribuer à son développement sur GitHub&nbsp;: <a href="https://github.com/coopTilleuls/UrlSignerBundle" target="_blank">https://github.com/coopTilleuls/UrlSignerBundle</a>.

API, web and cloud experts.

API Platform creators.
Symfony and Open Source contributors.

Our services

Expertise

Development

They trust us

Arnaud Senlis