une reprise du carnet (article principalement écrit par le même auteur)

Autorisations Dans Spip

Outre la balise #AUTORISER la notion d’autorisation dans spip est désormais spécifiée dans l’ API sur SPIP.net, et documentée dans la doc "programmeurs" : Gestion d’autorisation. On peut aussi consulter la partie du CR des troglospip https://contrib.spip.net/TrogloSpip... dévolue à ce sujet, et la documentation en fin de l’article décrivant le Plugin Autorité.
Enfin les lames avancées Fonctions d’Autorisations du CS proposent une visualisation et manipulation facilitées, avec le Debogueur-de-developpement.

Les fonction et balise [1] d’autorisations sont très utiles,... quand on sait quel paramètre donner dans les squelettes d’appel !

Cette page vise à documenter et préciser les rôles et valeurs possibles des paramètres d’appels des fonctions d’autorisation.

Article publié le 4 décembre 2014, et actualisé en février 2022

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Les sources définissant les fonctions d’autorisation peuvent nous renseigner sur ces rôles et valeurs possibles :
- depuis SPIP v2 et SPIP 3, il faut examiner ./ecrire/inc/autoriser.php, et ./ecrire/inc/utils.php
- pour les plugins, vous pourrez rechercher les lignes contenant le code : function autorise.... (d’ailleurs très souvent regroupé dans un fichier plugin_autorisations.php),
- pour les développeurs, vous pouvez faire imprimer directement la liste d’après array get_defined_functions ( void )
en restreignant votre recherche aux fonctions utilisateur (accessibles via $arr["user"] )
- pour les webmestres paresseux(=efficaces ;), visualisez la lame « Autorisations » du CS...
- car par le plugin Le Couteau Suisse, vous pouvez afficher toutes les fonctions d’autorisations avec la lame de Sécurité nommée Fonctions d’autorisations (et en définir de nouvelles sans programmation !),
- l’autre solution consiste à en regarder les usages : cherchez les fichiers avec autoriser(' (pour commencer..),
- enfin vous pouvez poser une option de débug des autorisations (voir "Debugging" ci-dessous).
Pour mémoire, vous retrouverez l’identifiant de l’auteur par #SESSION{id_auteur} ou (en php) $GLOBALS['visiteur_session']['id_auteur'].

 L’appel aux autorisations

Les autorisations ne dépendent pas seulement du statut auteur défini dans la table auteurs, selon les valeurs standard '0minirezo'  ,   '1comite'  ,   '6forum' [2]
Récapitulons les paramètres de la balise #AUTORISER et de la la fonction (à commencer par le $faire [3] ce qui nous intéresse) :
function autoriser_dist($faire, $type='', $id=0, $qui = NULL, $opt = NULL)

API pour les fonctions et balises d’autorisation :

  • $qui est :
    • vide (on prend alors visiteur_session)
    • un id_auteur (on regarde dans la base)
    • qui est traduit par autoriser_dist en un tableau décrivant l’auteur $qui
  • $faire est une action (’modifier’, ’publier’...) : insensible à la casse, indiquée sans quote pour #AUTORISER
  • $type est un type d’objet ou nom de table (’article’)
  • $id est l’id de l’objet sur lequel on veut agir
  • $opt (inutilisé en général) = options sous forme de tableau associatif
    // (par exemple pour préciser si l’autorisation concerne tel ou tel champ)

Le retour d’un test d’autorisation est un booléen, qui correspondra ensuite à : vide si refusé, ou un espace pour valider (et afficher les parties conditionnelles !), comme tout retour de balise...

Notes sur ’$qui’ :
- $qui[’restreint’] est renseigné (non vide si Admin -ou rédacteur- restreint à des rubriques.
- en SPIP3 [4] :$qui['webmestre'] vaut ’oui’ lorsque l’auteur est un webmestre.
Par exemple, vous pourrez utiliser [(#AUTORISER{webmestre}|oui) <pre>#ENV{type} - #ENV{composition}</pre> ] pour n’afficher les paramètres de Z qu’au WebMestre...

Notes sur $id :
Ce paramètre spécifie l’identifiant (clé primaire) de l’occurrence d’objet choisie ( un #ID_RUBRIQUE ou #ID_FORUM par exemple).
Si un #ID non nul est explicité, le plus souvent celui de la rubrique d’appartenance pour les Admins restreints, il servira au contrôle spécifique sur cette occurrence, sinon ce sera une autorisation générique pour tous les objets de ce type.

Debugging
Pour faciliter le traçage des autorisations (debug), en SPIP 2.x et 3.0 vous pouviez définir define ('_DEBUG_AUTORISER', true);   dans mes_options.php pour tracer les autorisations dans tmp/spip.log [5] (voir ecrire/inc/autoriser.php[34]).

Depuis SPIP 3.1 l’appel des autorisations sera tracé dans un fichier journal spécifique .\tmp\log\autoriser.log [6] sous réserve de définir define('_LOG_FILTRE_GRAVITE',8); ! En conséquence cette valeur _DEBUG_AUTORISER ne sera plus utilisée...

Cascade d’appel, du plus spécifique au plus général
Après récupération/valorisation contextuelle des valeurs par défaut, la fonction autoriser_dist($faire, $type=’’, $id=0, $qui = NULL, $opt = NULL) tente de générer et d’exécuter la meilleure autorisation déclarée (en surcharge, sinon en _dist ) sur le type, l’action, et l’objet (identifié si possible), sinon sur le type et l’action, sinon sur le type seul, ou sinon, enfin, sur l’action seule.

Dans l’ordre on va chercher [7] :

autoriser_type_faire[_dist],
autoriser_type[_dist],
autoriser_faire[_dist],
autoriser_defaut[_dist]

 Valeurs de $faire dans les autorisations standards

La liste des actions contrôlées, c’est à dire la liste des valeurs possibles du paramètre $faire, est détaillée ci-dessous : ce mot sélectionne l’autorisation testée et appliquée au type d’objet courant.

On trouve ainsi des autorisations génériques (se reporter à l’ordre de recherche des fonctions..) :

  • les niveaux d’autorisations globales selon le statut d’auteur :
    • autoriser_webmestre : pour les identifier plus facilement
    • autoriser_configurer : les Admins non restreints
    • autoriser_ecrire : Admins et Rédacteurs pour accès à l’espace privé
    • autoriser_previsualiser : partiellement configurable..
    • autoriser_dater
    • autoriser_ok et autoriser_niet
    • autoriser_voir (dépend du $type )
  • pour le traitement des rubriques :
    • autoriser_rubrique_publierdans = autoriser_rubrique_modifier
    • autoriser_rubrique_creerRubriquedans
    • autoriser_rubrique_editermots
  • pour le traitement des articles :
    • autoriser_article_modifier :=autoriser_rubrique_publierdans
    • autoriser_article_editermots = autoriser_rubrique_editermots
  • ensuite la plupart des autorisations vont dépendre aussi du $type :
    • autoriser_voir (dépend du $type )
  • pour les auteurs, on trouvera d’autres fonctionnalités :
    • autoriser_auteur_modifier : prend divers cas...
    • avec une fonction liste_rubriques_auteur (gestion de spip_auteurs_rubriques en SPIP2)
  • pour les pétitions :
    • pour la modération et la suppression : #AUTORISER{modererpetition,article,#ID_ARTICLE}

Ceci nous donne une liste des mots d’autorisations faire pour récapituler des actions :
- dans utils :
previsualiser - debug
- dans autoriser :
verifier -
voir - modifier - publierdans - editermots

Nota Bene : voir Autorisations PHP pour les Auteurs et aussi un article récent du Carnet/Contrib récapitule de nombreuses informations plus détaillées sur les codages et solutions d’autorisations !

 Un tableau des Droits

Evidemment, l’utilisation des tests d’Autorisations ne peut concerner qu’un auteur identifié/connecté à SPIP.
Un cas particulier concerne l’autorisation webmestre, la seule qui soit refusée aux administrateurs de configurer, et nous ne parlerons pas des auteurs désactivés [8] ; sinon les droits classiques sont exposés dans la plupart des articles sur le statut des utilisateurs [9].

Le tableau ci-dessous donne un premier aperçu des commandes autorisées [10], par statut d’auteur ; si les types et clés d’objets sont omis, ils seront repris du contexte !

Valeur de $faire Utilisation Visiteur Rédacteur Admin.restreint Administrateur
valeur interne du statut 6forum 1comite 0minirezo 0minirezo
voir Visiter le site Public (peut être restreinte à certains objets..) OK OK OK OK
voirrevisions Voir les modifications internes (article..) OK OK OK OK
forums/abo Fonctionnalité a configurer ; test dans le formulaire...pas de mot-clé identifié - - OK OK
ecrire Accès initial à l’espace privé - OK OK OK
modifier Modifier un objet (non publié) - - OK OK
creerobjetdans rédiger de nouveaux contenus - - OK OK
proposer proposer ces nouveaux contenus - - OK OK
 ? relire et commenter d’autres articles proposés - - OK OK
previsualiser prévisualiser un objet standard (avec var_mode=preview dans l’url) #CONFIG{preview} - - OK OK
joindreDocument ajouter des documents, pièces jointes #CONFIG - - OK OK
modifier modifier un article publié - - #ID OK
creerRubriqueDans créer une sous-rubrique - - #ID OK
publierDans publier l’article d’une rubrique - - #ID OK
 ? modérer un forum/article - - #ID OK
mot_creer creer un mot-clé - - - OK
mot_modifier Modifier un un mot-clé - - - OK
groupemots_creer Creer un nouveau groupe de mots-clé - - - OK
groupemots_modifier Modifier un groupe de mots-clé - - - OK
 ? créer un nouvel auteur - - - OK
 ? modifier les statuts auteurs - - - OK
voirstats Consulter les Statistiques - - - OK
defaut pour toutes autres demandes.. - - - OK
configurer configurer le site - - - OK
 ? activer certaines configurations - - - OK
webmestre réaliser les opérations bridées par FTP = être webmestre - - OK OK
creer auteur ne peut pas créer un auteur avec des droits supérieurs aux siens - - OK OK
modifier auteur ne peut pas donner des droits supérieurs aux siens - - OK OK

Rq 0 : voir la lame Fonctions d’autorisations CS pour un autre aperçu.
Rq 1 : L’indication #ID fait référence à un test sur l’identificateur de l’objet (souvent rubrique).
Rq 2 L’indication #CONFIG renvoie à une option de configuration générale du site.
Rq 3 : Les absences ci-dessus sont des autorisations non explictement résolues.
Rq 4 : Attention aux autorisations composées (contenant le caractère _ entre deux mots)...
Rq 5 : il est facile de piloter directement des Autorisations par les Zones du plugin Acces Restreint : voir "zoner" ci-dessous en fin d’article !

 Partie à compléter

- les documentations disponibles ne me sont pas totalement claires sur le mode d’insertion des fonctions autoriser personnalisées lorsque ce n’est pas fait dans un plugin
- traduire en autorisations le #SESSION{auteur} ou #SESSION{statut} (voir les tests sur le statut décrits dans #Session, à remplacer par #AUTORISER{ecrire},  #AUTORISER{configurer}, et  #AUTORISER{webmestre}).
- Il manque ci-dessus la solution pour identifier facilement les admins restreints (quel est le paramétrage de leur autorisation), récupérer plus facilement leurs rubriques autorisées => ressortir le $qui de autoriser_dist ?

Il est possible d’utiliser le tableau correspondant à #SESSION{restreint}, pour savoir si l’on est connecté à une rubrique en Administrateur Restreint :
       [Admin Restreint à (#SESSION{restreint}|table_valeur{#ID_RUBRIQUE}) #TITRE <br>]

Suite à une "feature" de SPIP, cela gérait aussi les Admins.Restreints devenus Rédacteurs.... en restreindre pareillement des auteurs rédacteurs et pas seulement des admins, à une liste de rubriques (mais en SPIP 3, la table change de formats....) : à noter (Spip 2.1.12) la conversion d’un Admin restreint en rédacteur ne supprime pas les restrictions dans la table auteurs_rubriques => à tester pour usage en autorisations..

- Surcharger une autorisation

  • exemples
  • >>> préciser plus clairement : Quand on surcharge des autorisations, il ne faut pas oublier de laisser la porte ouverte aux autorisés de plus haut niveau.

exemple de surcharge :
On veut permettre aux administrateurs restreints de modifier le login et mot de passe des visiteurs, mais pas de changer leur statut... il faut s’attaquer à la fonction autoriser_auteur_modifier_dist - https://core.spip.net/projects/spip... et principalement à cette partie du code ligne 763 :

elseif ($opt['statut'] == '0minirezo' OR $opt['restreintes'])
                        return false;

qu’on peut modifier dans le fichier squelettes/mes_fonctions.php en renommant la fonction "autoriser_modifier_auteur" :

elseif ($opt['statut'] == '0minirezo'  OR $opt['statut'] == '1comite')
                        return false;

pour permettre aux administrateurs restreints de changer le statut (ni administrateur ni rédacteur, ils ont toujours la liste déroulante, mais le choix de statut différent de visiteur ne s’enregistre pas). Le fait de supprimer OR $opt['restreintes'] permet de changer le login et mot de passe, c’est une découverte intéressante parce que c’est justement ce qu’on veut, mais on peut se poser la question : pourquoi le fait de retirer OR $opt['restreintes'] permet-il de modifier le login et mot de passe ?
voir le ticket https://core.spip.net/issues/3069

 Un exemple concret dans un plugin

Cet exemple -récupéré où- montre comment autoriser l’usage d’un nouveau bouton (en sous-menu d’Édition et dans la barre d’outils_rapides)
- dans le paquet.xml sont déclarés deux nouveaux boutons qui ouvrent la même nouvelle page :

        <menu nom="exporter_documents" titre="prefixe_plugin:titre_cadre_export_documents" parent="menu_edition" icone="images/exporter-document-16.png" action="exporter_documents" />
        <menu nom="exporter_documents_rapide" titre="prefixe_plugin:titre_cadre_export_documents" parent="outils_rapides" icone="images/exporter-document-16.png" action="exporter_documents" />

En l’état, les boutons sont bien utilisables par les administrateurs, mais pas pour les autres, administrateurs restreints ou rédacteurs... il faut déclarer les autorisations qui régleront les droits d’accès à ces boutons.
- également dans le paquet.xml, on doit nommer le fichier des autorisations :

        <pipeline nom="autoriser" inclure="prefixe_plugin_autorisations.php" />

Puis dans ce fichier prefixe_plugin_autorisations.php, on place les fonctions, simples mais efficaces :

/**
* Fonction d'appel pour le pipeline
* @pipeline autoriser */
function prefixe_plugin_autoriser(){}

function autoriser_exporterdocuments_menu_dist($faire, $type, $id, $qui, $opt){
        return true;  }
function autoriser_exporterdocumentsrapide_menu_dist($faire, $type, $id, $qui, $opt){
        return true; }

Et c’est tout.

Ça aide à comprendre la fonction autoriser, où exporterdocuments et exporterdocumentsrapide sont les noms des boutons (attribut nom de la balise xml <menu>) sans les éventuels "_" (tirets bas, ou underscore) [11].

 Et les zones d’accès restreint ?

Le plugin Acces Restreint fourni une autre forme de contrôle d’accès : mais le plugin n’assure que le filtrage sur l’arborescence native de SPIP, c’est à dire uniquement la structure des rubriques attribuées à une zone d’accès restreint, et les articles associés : le reste des objets editoriaux n’est pas filtré [12]

Néanmoins, il est aussi possible d’utiliser les autorisations implicites des zones d’accès en récupérant les fonctions du code interne, en particulier des filtres...
Il faut donc "faire son marché" dans accesrestreint_fonctions.php..
- accesrestreint_acces_zone($id_zone,$id_auteur=null){

Plus globalement, il vous suffit d’ajouter [13] une fonction

  1. function autoriser_zoner_dist($faire, $type, $id, $qui, $opt) {
  2.     if (is_null($id))  return $id;
  3.     if (!intval($id_zone = $id)) {
  4.         $id_zone = intval(sql_select('id_zone','spip_zones','titre LIKE '.$id));
  5.     }
  6.     include_spip(’inc/accesrestreint_autoriser’);
  7.     return accesrestreint_acces_zone($id_zone,$qui);
  8. }

Télécharger

pour pouvoir utiliser #AUTORISER{zoner,'nom de zone'} dans vos squelettes (que la zone comporte des rubriques explicites ou non !) donnant une nouvelle gestion de groupes d’auteurs pour autorisations !
Deux autres points à noter : il manque(ait) peut-être un champ #TEXTE permettant une description explicite des zones (utile quand on revient sur la définition d’un site avec de très nombreuses zones de protections...).
Mais il y a(vait ?) aussi un problème d’accès aux documents protégés qui ne relèveraient pas d’une extension (type de fichiers) définie à l’origine native de SPIP....


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.

[1Ces balises tronquent l’affichage de tout espacement supplémentaire à suivre...(passage par un ltrim avant sortie ?)..

[2Sans oublier ’5poubelle’ : voir auteur.

[3attention au nom de fonction, à écrire autoriser_type_faire : autoriser_type_faire($faire, $type='', $id=0, $qui = NULL, $opt = NULL) qui sera recherché automatiquement pour la fonction autoriser('faire','type'..) doit être écrit

[4pas en SPIP2, qui ne disposait pas encore de cette autorisation spécifique

[5Ne pas laisser les traces en Production : verbeux, et moins sécurisé..

[6Affiché par le plugin Simples-Logs s’il existe !

[7Dans les fonctions surchargées, le nom de type (normalisé sans s de pluriel, ni _ intermédiaire ) précède le verbe d’action $faire

[8Avec un code : info_statut_site_4 = ’5poubelle’

[9Rappelons que la table des statuts est codée en ecrire/inc_version.php[375], comme celle des états des articles, d’ailleurs ; mais il n’y a pas, à proprement parler, de table des Autorisations => voir-ci-dessous !.

[10Les commandes non qualifiées restent à identifier...

[11Attention à l’usage de tirets bas dans les noms systèmes d’autorisations /une remarque de Marcimat -cf. https://www.spip.net/5528 en bas- explicitait les ’allitérations’ automatiques de SPIP éliminant parfois tous les underscore.... !

[12Erreur (à vérifier encore), mais le filtrage d’accès Restreint s’opère sur toute table comportant un champ #ID_RUBRIQUE.....
(cf le nouveau plugin acces_restreint_objets https://zone.spip.net/trac/spip-zon...).

[13On se demande parfois pourquoi cela n’a pas été introduit d’office ;-)

[14Ces balises tronquent l’affichage de tout espacement supplémentaire à suivre...(passage par un ltrim avant sortie ?)..


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.

Article publié le 4 décembre 2014, et actualisé en février 2022 .

Répondre à cet article