Deux bonnes bibliothèques qui occupent des terrains voisins est une situation courante dans un écosystème, et la tentation est toujours d’absorber l’une dans l’autre.
La situation
LexikJWTAuthenticationBundle est la façon habituelle d’authentifier une API Symfony avec des jetons. Il s’occupe du pare-feu, du fournisseur d’utilisateurs, du flux de rafraîchissement. Son encodeur de jetons, en revanche, ne couvre qu’une tranche étroite de JOSE : la signature, avec quelques algorithmes.
S’il vous faut des jetons chiffrés, des jeux de clés, une rotation par kid ou un algorithme qu’il n’implémente pas, vous êtes coincé entre un bundle qui fait bien l’authentification et un framework qui fait bien JOSE.
La décision intéressante
Le bundle expose son encodeur sous forme d’interface. La réponse n’était donc pas de le forker, ni de lui demander de grossir : c’était de fournir une autre implémentation de cette interface, adossée à JWT-Framework.
Une centaine de lignes environ. Le bundle continue de faire de l’authentification, le framework continue de faire du JOSE, et aucun n’a eu à apprendre le métier de l’autre.
Pourquoi cela vaut d’être dit
Parce qu’une fourche paraît moins coûteuse le jour où vous la faites et ne l’est jamais ensuite. Vous héritez de chaque correctif à venir, de chaque avis de sécurité, et de l’obligation d’expliquer aux utilisateurs laquelle des deux ils doivent installer.
Et parce que cela pose une exigence à l’auteur de bibliothèque : exposez des interfaces aux jointures. Le pont n’existe que parce que quelqu’un, dans l’autre projet, a rendu son encodeur remplaçable. Cette décision ne lui a rien coûté et a évité une fourche.
lexik-jose-bridge, si vous êtes dans cette situation.