Les autorisations basiques

  Code des fonctions standard

Les fonctions d’Autorisations Dans Spip ont une syntaxe d’appel assez standardisée pour être facilement extensibles ; mais leurs formulations sont aussi très répétitives !
En attendant que les principales soient factorisées, voici un récapitulatif des besoins principaux.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 Rappel de la syntaxe commune

Récapitulons les paramètres de la balise #AUTORISER et de la fonction correspondante (depuis Autorisations Dans Spip) :
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, voir [143] function autoriser_dist())
    • 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 : vide si refusé, ou un espace pour valider (et afficher les parties conditionnelles !), comme tout retour de balise...
le retour de certaines fonctions est un vrai booléen : attention !

Et pour mémoire, les statuts standard sont bien '0minirezo'  ,   '1comite'     , '6forum' sans oublier '5poubelle' ; si vous voulez ajouter d’autres statuts, vous pourriez bien avoir à reprendre TOUTES les fonctions d’autorisation....

 Les codes d’autorisations

Pour rechercher des exemples, en attendant d’utiliser cet article, le plus simple était peut-être de ’faire son marché’ dans ecrire/inc/autoriser.php : on l’a fait pour vous !
Nota Bene : le pseudo-nom de fonction utilisé ci-après n’existe pas réellement sous SPIP !

- autoriser webmestre($qui) :
facile : il suffit d’écrire   return autoriser('webmestre');
D’ailleurs, cette fonction existe déjà dans le Code de SPIP !

- autoriser admin() :
tout aussi facile : c’est le retour standard de autoriser('_configurer') soit :
 $qui['statut'] == '0minirezo'  and !$qui['restreint'];

- autoriser restreint() : sur une rubrique ciblée,
toujours aussi facile : vous trouverez la fonction acces_restreint_rubrique($id_rubrique)
(mais celle-ci traite uniquement l’auteur connecté, de façon booléenne !).

- autoriser redige() :
_ en s’inspirant de autoriser_article_creer, vous pourrez utiliser
  return in_array($qui['statut'], array('0minirezo', '1comite')));
(mais attention au cas où vous voudriez utiliser d’autres statuts personnalisés)....

- autoriser prive() : l’accès général à l’espace privé autoriser_ecrire est :
isset($qui['statut']) and in_array($qui['statut'], array('0minirezo', '1comite')).

- autoriser visiteur() (donc même dans l’espace public) : pas de fonction [1], mais une variable php à tester par isset($GLOBALS['visiteur_session']['id_auteur']).

Attention à quelques mini-pièges des autorisations standard dans SPIP ; j’ai noté :
- un Admin Restreint reste ’restreint’ en étant rétrogradé en Rédacteur,
- un Administrateur rétrogradé pourrait encore voir le menu Développement (?),
- ....
Donc souvent, les autorisations de consultation des menus (ex. autoriser_auteurs_menu proviennent d’autorisations d’actions (ex. autoriser('voir', '_auteurs', $id, $qui, $opt);)...


Merci de nous signaler les coquilles ou erreurs qui figureraient dans cette page.

[1Peut-etre que je n’ai pas trouvé : voir la balise#SESSION !


Liens visibles seulement pour les inscrits.

Article publié le 4 décembre, et actualisé en décembre 2018 .

Répondre à cet article