La documentation, section par section

La documentation du framework Access Control vit sur acf.spomky-labs.com, dans un dépôt qui lui est propre, et elle est organisée par la question que vous posez plutôt que par les classes qui y répondent.

Cinq sections, et l’ordre est délibéré. Voici ce qu’il y a dans chacune, et quand l’ouvrir.

Le projet

What is Access Control? donne la forme générale en une page : ce qu’il décide, pourquoi il existe, pourquoi il n’a besoin d’aucune pile d’authentification, et la panne contre laquelle il est bâti. Installation couvre les deux paquets, les prérequis, et le tableau des paquets facultatifs avec ce que chacun débloque.

Contributing est courte et vaut d’être lue même si vous n’envoyez jamais de correctif, parce qu’elle dit ce que le projet s’impose : des tests toujours, des tests qui passent par le vrai chemin, et tout ce qui touche à la passerelle Symfony vérifié sous trois configurations.

Access Control in a nutshell

La moitié conceptuelle, quatre pages : Vocabulary, Voters, Combining Algorithms et Requesters and Actors.

Lisez d’abord la page de vocabulaire, même pressé, et surtout si vous venez de XACML : le mot subject désigne ici la ressource, pas l’acteur, et toutes les autres pages supposent que vous le savez.

Pure PHP

Trois pages pour la bibliothèque seule, sans le moindre framework en vue : The Manager, Access Policies et Testing.

Cette section existe en tant que section, plutôt qu’en note de bas de page de celle sur Symfony, parce que l’indépendance est une fonctionnalité et non une affirmation. Documentée après coup, elle finirait par le devenir.

Le bundle Symfony

Huit pages, une par point d’entrée : Installation, Configuration, Controllers, URL Rules, Templates, Console Commands, Workflow Guards et The Profiler Panel.

Chaque page porte ce qui est facile à rater plutôt que le seul chemin heureux : la page des règles d’URL explique pourquoi ses règles ne sont pas un doublon de celles de Security, la page console pourquoi le code de sortie est 113, la page workflow pourquoi un paquet doit être installé et ne sert jamais.

Migration

Trois pages : The Two Migrations, Coming From Security et Known Divergences.

La dernière des trois est celle à lire avant de décider quoi que ce soit : tout ce que le composant refuse de transporter, tout ce qu’il nomme autrement, et tout ce qu’il accepte comme un coût. Rien de ce qui s’y trouve n’est censé changer en silence.

C’est un dépôt, donc il accepte les correctifs

Les sources vivent dans access-control-doc, en Markdown. Une page qui a mal répondu à votre question est une pull request, et une question à laquelle aucune page ne répond est un ticket sur le dépôt principal, où vit aussi le code.

Une chose que la documentation dit explicitement, et elle est assez inhabituelle pour être répétée : les algorithmes de combinaison portent leurs noms XACML exprès, alors merci de ne pas « corriger » cela par mimétisme.