Carnet Wiki

Autorisations Dans Spip

Version 29 — Avril 2012 — Luis Speciale

<blockquote class="spip">

La notion d’autoriation dans spip est 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.

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 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 :
-  en SPIP v2 stable à ce jour, 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....
-  l’autre solution consiste à en regarder les usages : cherchez les fichiers avec autoriser(' (pour commencer..)

L’appel aux autorisations

Récapitulons les paramètres de la fonction :
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 preciser si l’autorisation concerne tel ou tel champ)

Le retour d’un test d’autorisation est : vide si refusé, un espace pour valider (et afficher les parties conditionnelles !)

Notes sur ’$qui’ :

-  $qui[’restreint’] est renseigné

-  En SPIP3 (mais pas SPIP2) $qui['webmestre'] vaut ’oui’ lorsque l’auteur est un webmestre.

Notes sur $id
>>> c’est pas clair français ça et sans tester ou regarder le code je ne comprend pas :
Si un #ID est exprimé, le plus souvent celui de la rubrique d’appartenance pour les Admins restreints, il servira au controle spécifique, sinon l’autorisation générique. :

Debugging
Vous pouvez définir

	
define ('_DEBUG_AUTORISER', true);  

dans mes_fonctions pour tracer les autorisations dans tmp/spip.log (voir ecrire/inc/autoriser.php[117]

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’executer 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

 
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 )
  • 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)

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

Evidement, 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, et nous ne parlerons pas des auteurs désactivés [2] ; sinon les droits classiques sont exposés dans la plupart des articles sur le statut des utilisateurs, avec une mention pour le tableau récapitulatif de utiliser Spip.
 [3].

Le tableau ci-dessous donne un premier aperçu des commandes possibles [4], à préciser en fonction de l’objet (et de la clé) éventuellement complété, sinon repris dans le 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

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

Partie à compléter

-  les documentations disponibles ne sont pas totalement claires sur le mode d’insertion des fonctions autoriser personnalisées (si ce n’est pas dans un plugin)

-  traduire en autorisations le #SESSION{auteur} ou #SESSION{statut} (voir les tests sur le statut décrits dans #Session, à remplacer par <code class=« spip »>#AUTORISERecrire</code code>#AUTORISERecrire</code >, <code class=« spip  »> > #AUTORISERconfigurer, et <code class=« spip  »> > #AUTORISERwebmestre).

-  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ère aussi les Admins.Restreints devenus Rédacteurs....
et restreindre pareillement des auteurs redacteurs 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 redacteur 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.
Voire les remarques sur SPIP.net : la rubrique 60. Statuts et Autorisations (vide) et les articles #Autoriser et #Session, et les rappels de Programmer : Créer/surcharger des autorisations, pour utiliser des autorisations personnalisées.

Retour à la version courante

Toutes les versions