Donnez un répartiteur d’événements au gestionnaire et il raconte son propre travail. Le panneau du profileur est un lecteur de ce récit, les assertions de test en sont un autre, et la piste d’audit en production est celle que vous écrivez vous-même.
- L’événement de question : quelqu’un a demandé. Émis par les points d’entrée et par la passerelle Security, ce qui fait qu’une question passée par le vérificateur de Security est comptée quand même.
- L’événement de vote : un votant a répondu, avant qu’aucun algorithme de combinaison n’y touche.
- L’événement de décision : le gestionnaire a arrêté un verdict, sous un algorithme nommé.
- L’événement de politique : un nœud d’un arbre de politiques d’accès a été évalué.
L’événement de décision porte son parent quand une question a été posée depuis une autre, et l’événement de politique fait de même pour la forme d’une politique. Ce que vous collectez est un arbre, pas une liste de réponses sans rapport.
Un abonné d’audit
public static function getSubscribedEvents(): array
{
return [
AccessDecisionEvent::class => 'onDecision',
VoteEvent::class => 'onVote',
AccessQueryEvent::class => 'onQuery',
];
}Voilà tout l’enregistrement dans une application Symfony. L’application de démonstration en fournit un, et il vaut d’être lu pour deux décisions qu’il prend.
Il écarte les abstentions du journal des votes. La plupart des votants s’abstiennent sur la plupart des questions, et les garder enfouirait la piste sous le bruit. Ce que vous voulez voir, c’est qui a exprimé un avis.
Il note si une décision était imbriquée. Une question qu’un votant a posée en répondant à une autre est un fait différent d’une question posée par un point d’entrée, et aplatir les deux fait mentir une piste d’audit sur le nombre de fois où l’accès a été vérifié.
Pourquoi ne pas réemployer celui du débogage
Le bundle tient un journal de décisions en mode débogage, celui que lisent le panneau et les assertions. Il n’est délibérément pas celui que vous voulez en production : il garde tout en mémoire pour la durée de la requête, et il n’est pas là quand le drapeau de débogage est baissé.
Une piste d’audit est un autre objet avec d’autres contraintes : elle filtre, elle persiste, et elle survit. Partager les événements plutôt que le collecteur est ce qui permet aux deux d’exister sans qu’aucun ne soit un compromis.
Un détail que porte le journal de débogage
Il sait remonter la pile pour nommer le site d’appel de chaque décision, et il ne le fait qu’en débogage, parce que cette remontée n’est rentable que là : c’est ce qui nomme une décision dont personne n’a déclaré l’origine, un gabarit ou un service qui demande de lui-même.
La première trame qui n’appartient ni au composant ni au répartiteur est celle qui a demandé. Les fixtures de test sont exclues de ce saut à dessein : un test qui demande de lui-même mérite d’être nommé comme n’importe quel autre appelant.
Hors de Symfony
Rien de tout cela n’a besoin du framework. Le gestionnaire prend un répartiteur d’événements PSR, et une application PHP nue qui lui en donne un obtient les quatre mêmes événements, le même arbre, et la même capacité à s’appuyer dessus dans ses tests.
Ce qui est la forme générale de ce composant : la bibliothèque décide, et tout ce qui la regarde décider est un écouteur que vous pouvez remplacer.