Carnet Wiki

Autorisations Dans Spip

Version 74 — Février 2019 YannX

<blockquote class="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 [TrogloSpip] Comment personnaliser l’espace privé avec le crayon dévolue à ce sujet.... et la documentation en fin sur Le plugin « Autorité ».
Enfin les lames avancées Fonctions d’Autorisations du CS proposent une visualisation et manipulation facilitées.

Les fonctions et balises d’autorisations sont très utiles,... mais leur emploi suppose de savoir quel paramètre donner dans les squelettes d’appel. C’est ce que cette page vise a préciser : les rôles et valeurs possibles des paramètres d’appels des fonctions d’autorisation.

</blockquote>

Les sources définissant les fonctions d’autorisation peuvent nous renseigner sur ces rôles et valeurs possibles :
-  depuis SPIP v2 , 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....
-  vous pouvez en regarder les usages : cherchez les fichiers avec autoriser('
-  enfin vous pouvez poser une option de débug des autorisations (voir « Debugging » ci-dessous).

L’appel aux autorisations

Récapitulons les paramètres de la balise #AUTORISER et de la la fonction :
function autoriser_dist($faire, $type='', $id=0, $qui = NULL, $opt = NULL)

API pour les fonctions et balises d’autorisation :

  • $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’) sans ’underscore’ (ils sont éliminés par objet_type() !). Lorsque $type n’est pas un nom de table, il faut le préfixer par un _.
  • $id est l’id de l’objet $type à propos duquel on teste l’autorisation d’agir
  • $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
  • $opt (inutilisé en général) = options sous forme de tableau associatif
    // (par exemple pour preciser si l’autorisation concerne tel ou tel champ)

Le retour d’un test d’autorisation est : vide si l’autorisation n’est pas accordée, un espace si l’autorisation est accordée (et permettre le traitement et l’affichage des parties conditionnelles).
Attention
suite à une discussion entre Rasta et gOuz Ou placer les tests d’autorisation pour un CVT
, rappelez-vous que l’autorisation peut changer entre le Chargement d’un formulaire et la Verification-Traitement, soit parce que les valeurs ont changé par aiileurs [1], soit parce que les droits calculés par la fonction php d’autorisation ont changé entre-temps....
- RastaPopoulos : mais c’est possible qu’à terme il faille mettre l’autorisation, dans charger(), dans verifier() ET dans l’action hors formulaire (qui peut être appelé par d’autres trucs)

Notes sur ’$qui’ et l’auteur
-  l’identifiant de l’auteur peut être obtenu en SPIP par #SESSION{id_auteur} ou en php par $GLOBALS['visiteur_session']['id_auteur'].
-  $qui[’restreint’] est renseigné
-  En SPIP3 (mais pas en SPIP2) :$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. Ne laissez pas les traces une fois passé en production.
Depuis SPIP 3.1 l’appel des autorisations sera tracé dans un fichier journal spécifique .\tmp\log\autoriser.log 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 [2] :

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

Valeurs prises par $faire dans les appels aux autorisations standards

La liste des actions contrôlées, c’est à dire la liste des valeurs possibles du paramètre $faire, est détaillé 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..) :

    • autoriser_webmestre
    • autoriser_defaut = autoriser_configurer : les Admins non restreints
    • autoriser_ecrire : pour autoriser l’accès à l’espace privé
    • autoriser_previsualiser
    • 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 )
    • autoriser_bidule_iconifier (pour qu’il n’y ait pas de formulaire de logo sur un objet bidule, il suffit de renvoyer false)

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

Un tableau des Droits

L’utilisation des tests d’autorisations ne peut concerner qu’un auteur identifié/connecté à SPIP, sans parler pas des auteurs désactivés, dont le statut est ’5poubelle’.

Le tableau ci-dessous donne un premier aperçu des valeurs par défaut des autorisations standards.

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 - - selon champ selon champ
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
iconifier_bidule présence ou non d’un formulaire de logo sur un objet bidule

Rq 1 :#ID fait référence à un test sur l’identificateur de l’objet (souvent une rubrique ou un article).
Rq 2 #CONFIG renvoie à une option de configuration générale du site.
Rq 3 : Les absences ci-dessus sont des autorisations non explicitement résolues.
Rq 4 : Attention aux autorisations composées (contenant le caractère _ entre deux mots) car le _ est supprimé...

Partie à compléter

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

-  Pour les droits des admins restreints, il est possible d’utiliser le tableau des rubriques administrées : #SESSION{restreint} afin de tester si la rubrique courante en fait partie.

  • Exemple :       [Admin Restreint à (#SESSION{restreint}|table_valeur{#ID_RUBRIQUE}) #TITRE <br>]
  • Attention : le champ ’restreint’ n’est pas vidé quand un Admin Restreint est rétrogradé au statut ’Rédacteur’. En toute rigueur, il faut donc AUSSI tester le champ ’statut’.

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 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 » (on enlève le _dist pour qu’elle devienne prioritaire) :

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 ?

Surcharger 2 fois une autorisation ?

- https://contrib.spip.net/Astuces-longues-pour-SPIP#a34

exemple d’utilisation dans un plugin : autoriser l’usage d’un nouveau bouton

On veut conditionner l’apparition d’une nouvelle entrée en sous-menu d’Édition et dans outils_rapides.
-  dans le paquet.xml on a déclaré 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 utilisables par les administrateurs, mais pas pour les administrateurs restreints ou rédacteurs... On peut modifier les autorisations pour régler 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 prefixe_plugin_autorisations.php, on place les fonctions suivantes :

/**
 * Fonction d'appel pour le pipeline
 * @pipeline 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.
exporterdocuments et exporterdocumentsrapide sont les noms des boutons (attribut nom de la balise xml <menu>) dont les ’_’ ont été ôtés.

Restriction par zone

Le plugin Acces Restreint fourni une autre forme de controle 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é.....
(cf le nouveau plugin acces_restreint_objets http://zone.spip.org/trac/spip-zone/browser/_plugins_/acces_restreint_objets/trunk)

Neanmoins, 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 dans mes_fonctions.php [3] la fonction

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

pour pouvoir utiliser #AUTORISER{zoner,'nom de zone'} dans vos squelettes.

Voire les remarques sur SPIP.net :
-  la rubrique 60. Statuts et Autorisations (vide)
-  l’API « autoriser »
les balises #Autoriser et #Session,
-  le filtre |sinon_interdire_acces pour renvoyer vers une page 404 ou 403....
précaution : toujours ajouter un test d’autorisation avec ce filtre dans tous les formulaires (à la fin !!)

Voir aussi les rappels sur autoriser de Programmer :
-  Créer/surcharger des autorisations
-  le Processus de la fonction -autoriser-, pour définir des autorisations personnalisées.

Enfin, certaines autorisations sont directement liées à la Gestion des Statuts.

Retour à la version courante

Toutes les versions