L’application de démonstration : chaque page est une vraie question

4 min

Une documentation explique. Une application de démonstration prouve. Celle-ci est une application Symfony qui tourne, où chaque page est une vraie question posée par un vrai point d’entrée, et le tout est couvert par une suite de tests qui s’appuie sur les décisions plutôt que sur les codes de statut.

git clone https://github.com/Spomky-Labs/access-control-demo
cd access-control-demo
docker compose up -d

Ouvrez localhost:8000. L’image construit l’application et la sert, donc rien n’est à installer sur la machine hôte. Connectez-vous avec user, manager ou admin, le mot de passe étant l’identifiant.

Il n’y a pas de base de données, ni de service de base de données dans le fichier compose. Les comptes et les documents vivent en mémoire, délibérément : ce que l’on démontre est l’autorisation, et un schéma à migrer avant que la première page ne s’affiche ne ferait que se mettre entre vous et elle.

Quatre sections, quatre questions

  • Guards : où une décision s’applique-t-elle ? Un attribut sur un contrôleur et sur une classe, une politique au sujet d’un sujet, des règles en configuration, une garde de workflow.
  • Decisions : comment le verdict est-il atteint ? Cinq algorithmes de combinaison, la même requête sous deux d’entre eux, des formes de politiques, une expression, une fermeture.
  • Requesters : qui demande ? L’usurpation d’identité, la délégation, et l’environnement d’accès.
  • Reasons : que peut-on voir après coup ? Les verdicts avec leurs raisons, décider pour d’autres comptes, la piste d’audit, le panneau du profileur.

Le menu est engendré depuis une seule classe de catalogue, et un test échoue si une page est ajoutée sans place dans cette carte. Un second test rend toutes les routes, de sorte qu’une erreur de gabarit dans une feuille ne peut pas se cacher derrière une suite verte.

Les points d’extension, écrits dans src

Les pièces qu’une application est censée écrire sont toutes là, chacune devenant un service par la seule implémentation d’une interface :

Et un fichier qui démontre la migration en n’étant pas touché : un votant Security, qui vote toujours à travers la passerelle, et dans lequel rien ne sait que le bundle existe.

Sans Security du tout

Le coin intéressant du dépôt est un jeu de noyaux sous tests/Standalone/ qui enregistrent le bundle et pas de SecurityBundle, et qui décident quand même : la hiérarchie de rôles sur la clé propre à la bibliothèque, des règles déclaratives, #[AccessPolicy], l’#[IsGranted] de Symfony, les aides de contrôleur et un workflow gardé, sans pare-feu, sans jeton et sans fournisseur d’utilisateurs.

C’est la troisième des trois configurations, tenue debout dans une application plutôt que dans un test unitaire.

Sur la console

php bin/console app:report:generate --as=admin
php bin/console app:document:purge --force --as=admin
php bin/console app:access:check VIEW 2 --as=user

Il n’y a pas d’utilisateur connecté sur une console, donc --as tient lieu d’identité de service. La dernière commande imprime le verdict, la raison et chaque vote, ce qui est le plus court tour possible de ce que porte une décision. Une commande refusée sort en 113, et deux d’entre elles répondent 77 à la place par un écouteur, parce qu’un état de sortie appartient aux scripts autour d’une commande, pas à la règle qui l’a refusée.

Pourquoi elle suit la branche de développement

Les deux paquets sont exigés sur la branche de développement plutôt que sur une version étiquetée, exprès. Quand la bibliothèque bouge, cette suite le dit, ce qui fait de la démonstration un test des paquets autant qu’une vitrine.

Cela clôt cette série. Le code est sur access-control-framework, la documentation sur acf.spomky-labs.com, et la démonstration sur access-control-demo. Les tickets et les pull requests ont leur place sur le dépôt du framework, les deux paquets n’en étant que des extractions en lecture seule.

Étiquettes : , ,