Carnet Wiki

Version 10 — August 2016 YannX

Le système d’autorisations de SPIP -tel que décrit dans Autorisations Dans Spip- est très structuré et relativement facile à utiliser et étendre, en particulier par un modèle de fonctions pour les plugins ; cela représente un atout par rapport aux autres CMS...

Neanmoins, il présente quelques inconvénients d’usage :
-  par exemple il n’est accessible que par programmation php
il n’existe aucune interface d’administration clicable
-  il n’est pas directement gérable par groupes ou zones
-  il n’est pas facile d’affecter directement des droits ponctuels à un auteur
-  l’usage du pipeline correspondant (voir ciautoriser : plugin « Pipeline pour autoriser »)
-  .... vos autres reproches..
-  le plugin Acces Restreint pourrait etre étendu, cf. Etendre Acces Restreint au-delà des Rubriques ?..

Cette page de carnet propose de regrouper pour discussion diverses approches.

Récapitulation des documentations et informations sur le sujet


-  l’[API Autoriser->net/5528" class='spip_url spip_out auto' rel='nofollow external'>http://www.spip.net/5528] net/fr_article5528 . définie depuis SPIP 2, son pipeline [Autoriser->http://programmer.spip.net/205] et son [code->html" class='spip_url spip_out auto' rel='nofollow external'>http://code.plugins.spip.net/commandes/pipelines/autoriser.html]
- [Programmer des Autorisations->http://programmer.spip.net/48] et le [Fonctionnement et déclaration des fonctions d’autorisations->http://code.spip.net/30],
depuis SPIP 2 - le pipeline [Autoriser->http://programmer.
spip.net/205] et son [code->http://code.plugins.spip.net/commandes/pipelines/autoriser . net/autoriser] html]
-  l’usage du pipeline dans [programmer.spip->http://programmer.spip.net/30]
net/Creer-ou-surcharger-des]
- 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.

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...

0. le Plugin Autorité

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

1. 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

2. Un plugin ACL

Une suggestion en-cours d’etude [1] analyse PDF et implémentation, suite a une longue discussion sur spip-dev au 25/11/2015

3. Une base ACL

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.
-  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 /facultatif/ : pour restreindre à une instance (avec caractères génériques)
  • verbe_faire (nom provisoire) : identifiant textuel de l’autorisation pilotée
  • 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 [2] (avec caractères génériques)
  • options
  • titre / commentaires : pour pouvoir documenter /par le webmestre, ou le gestionnaire/ l’usage de cette ligne d’autorisations (et ses conséquences).

Idée : utiliser le plugin ZAR (qui permet de définir des groupes d’auteurs en zone d’accès restreint) pour
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) : offrir un générateur interactif [3] de fonctions autoriser_..() spécifique...celui-ci permettrait de générer 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...