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) : #AUTORISER{webmestre}
facile : il suffit d’écrire   return autoriser('webmestre');
D’ailleurs, cette fonction existe déjà dans le Code de SPIP !

- autoriser admin() : #AUTORISER{configurer}
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 !)
Sinon il faudrait définir une fonction function autoriser_restreint($id_rubrique) avec
 ($qui['statut'] == '0minirezo')  and  in_array($id_rubrique,$qui['restreint']);.

- 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], la balise #SESSION ou 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é de Webmestre 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.

[1Voir peut-être la balise balise_SESSION() ou une fonction dédiée que je n’ai pas vue !


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

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

Répondre à cet article