Plugin ACL

Récapitulation des informations sur le sujet

-  l’API Autoriser définie depuis SPIP 2, son pipeline Autoriser et son code
-  Programmer des Autorisations et le Fonctionnement et déclaration des fonctions d’autorisations,
-  le pipeline Autoriser et son code
-  l’usage du pipeline dans programmer.spip
-  des exemples d’utilisation sont aussi disponibles dans le CS, ainsi qu’une lame de Securité ecrire/?exec=admin_couteau_suisse&cmd=descrip&outil=autorisations rappelant toutes les fonctions d’autorisations disponibles dans SPIP, et permettant d’en créer de nouvelles.

Enfin, un dernier point à prendre en compte : toute solution doit être adaptée à la gestion en volume (dans l’annuaire de SPIP ou depuis un annuaire exterieur LDAP/AD ou CAS) : les traitements individuels par auteur ne seront qu’une personnalisation exceptionnelle et ponctuelle, à limiter aux caps particuliers.

On pourrait aussi adjoindre la problématique classique, à nouveau espérée par Pierretux cet hiver, d’un annuaire d’auteurs multi-sites (à partir de LDAP ou autre...)

Des solutions actuelles

Plusieurs extensions au core de spip permettent des fonctionnements complémentaires (sans compter les divers plugins de gestion d’accès) :
-  le plugin autorité
-  la solution opérationnelle proposée par [dev] Les autorisations du Couteau Suisse et sa lame ’Sécurité / Fonctions d’autorisations’
-  le plugin ciautoriser (étendant/redéfinissant le pipeline correspondant) pour ciar : plugin « Accès restreints issus de Giseh »
-  la démarche de David... (cf. mails du 25/11/2015 et 17/08/2016 sur spip-dev)
-  la réflexion sur une table d’ACL pré-générant des fonctions autoriser surchargeantes
-  sans oublier la réflexion de Cerdic pour étendre AR aux articles : Accès restreint V2 - Les objectifs.

Les Zones d’Acces Restreint ne sont pas evoquées ici, alors meme qu’elles proposent déjà une notion implicite de groupe : il serait tellement facile de les utiliser pour des #AUTORISER{'zone',#ID_ZONE...} sans mettre de restriction de rubriques ; toutefois pour un usage complémentaire plus développé, il manque la possibilité de sélectionner de nombreux auteurs d’un coup /facilites ergonomiques/..

0. le Plugin Autorité

Ce plugin surcharge certaines autorisations, avec des écrans de configurations ; sa documentation (ancienne, pourrait être complétée, en particulier sur un plan technique.) liste les diverses autorisations paramétrables, sans expliciter les verbes d’autorisation modifiée...

1. la syntaxe descriptive simplifiée du Couteau Suisse

Dans la lame Fonctions d’autorisations (du groupe Sécurité - non documentée), le Couteau Suisse (« CS ») propose
-  d’une part la récupération de toutes les fonctions d’autorisations du site (voir source [2]),
-  d’autre part, d’en générer de nouvelles, avec une syntaxe allégée, et proposant des alias pour ces autorisations (voir source [3])....

La syntaxe est : « qui : faire type id = alias » , dont quelques exemples sont donnés :

// creer article = creer rubrique
// 23 : modifier article 18 = ok
// configurer cs = webmestre
// auteur 7 = niet

Ainsi le CS rend disponible deux fonctions fort utiles :

• la génération du code de fonctions d’autorisations supplémentaires (compatible SPIP),
• une reprise simple de toutes les fonctions d’autorisations existantes (des plugins activés) !

2. Le plugin ciautoriser

Proposé pour développer la compatibilité Gizeh, l’un des nombreux plugins d’Equipement développe une extension facilitant l’utilisation multiple du pipeline standard autoriser de SPIP : voir son analyse PDF et son implémentation actuelle.. Cela permet en particulier de gérer des autorisations par groupes....

3. Un plugin ACL

Un projet de David Fredette en-cours d’etude
-  PDF : Analyse PDF
-  PDF Implémentation,
-  Discussion sur spip-dev au 25/11/2015, poursuivie depuis le 17/08/2016...
(hélas, tous ces liens Canadiens semblent avoir disparu Avril 2023)]

4. Une base ACL en table

Une réflexion déjà ancienne, à réactualiser par YannX !

L’idée, en bref : construire une table spip_acl permettant de préempter les définitions par défaut de SPIP, en surchargeant le code d’autorisation par construction au vol d’une fonction à partir de l’exploration de la table : cela reprendrait partiellement la pratique du CS, mais à partir d’une requete SQL et non de saisies textes [4] .
-  les champs de la table : correspondent essentiellement aux champs de la fonction autoriser ( $faire , $type ,  $id , array $qui , array $opts ) :

• id_acl : champ d’index pour estre compatible avec les API de manipulation d’objet éditorial
• objet  : type de l’objet considéré (avec caractères génériques)
• id_objet /valeur facultative/ : pour restreindre à une instance (avec caractères génériques)
• faire : identifiant textuel caractéristique de l’autorisation pilotée(attention aux droits composés avec des underscores)
• groupe-objet : à priori ’auteur’ pour gérer directement les droits par auteur,
  mais prévoir cette zone permet éventuellement d’imaginer des extensions dans le modèle, en restant lié à la structuration par modèle d’objets éditoriaux (ex. ZAR)
• id_auteur (ou id_user ?) : restriction à un individu $qui [5] (avec caractères génériques), ou indication d’un statut générique (alphanumérique) [6]
• options pour pouvoir étendre des conditions liées, ou les exceptions
  (S’inspirer de certaine syntaxe evoquée par le CS ?)
• alias : nommer la ligne par un alias permettra de la traiter comme élément d’uen condition plus complexe,
  donc on ouvre déjà la structure aux traitements divers dépassant une simple coordination logique.
• commentaires : pour pouvoir documenter /par le webmestre, ou le gestionnaire/ l’usage de cette ligne d’autorisations (et ses conséquences). [7]

La gestion dans une table en BDD permet de traiter très simplement les OR, la gestion des conditions liées en AND étant à reporter alors dans les options (par des alias de clauses nommées ? ou par des ajouts d’exceptions, ou de conditions supplémentaires, par exemple sur le statut des auteurs considérés)...
Idée : utiliser le plugin Acces Restreint-ZAR (qui permet de définir des groupes d’auteurs en zone d’accès restreint) pour piloter la notion de groupe de rôles, sans utiliser la gestion par rubriques...
Il faudrait aussi prévoir l’implémentation d’une hiérarchie des autorisations (par surcharge en programmation objet des fonctions autorisations)

L’implémentation serait alors d’ajouter en pré-exécution dans le code d’appel d’autoriser, l’appel à une fonction autoriser_acl( $faire , $type ,  $id , array $qui , array $opts ) qui renverrait une autorisation extraite de la table ACL si elle existe , en plus de celle éventuellement trouvée par l’appel traditionnel (du core de SPIP ou définie par le plugin...) !
Une option complémentaire (qui avait précédé cette démarche de modélisation en table SQL), retrouvée depuis dans ce CS : offrir un générateur interactif [8] de fonctions autoriser_..() spécifique... car le CS propose déjà un fichier « mes_autorisations.php » analogue aux fichiers déjà existants (mes_options et/ou mes_fonctions), ou à celui gérable par chaque plugin.
Toutefois, le traitement des exceptions, ou des conditions indirectes (accès à la rubrique d’un administrateur restreint par exemple) devra passer par une extension de traitement utilisant le champ prévu options, avec une syntaxe adaptée, de par exemple la lame du CS... en attendant une étude plus pointue de ciautoriser !