Plus d’autorisations : exemples

  programmer des droits d’accès (sans programmer)

Quelques astuces complémentaires pour améliorer les possibilités de contrôle d’accès dans vos squelettes, en utilisant indirectement les facilités comme #AUTORISER programmées par des experts.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Attention, cette page est encore en  

 Rappel général

Pour restreindre spécifiquement certaines opérations, en particulier les possibilités de gestions dans l’espace privée de SPIP, il faut surcharger les fonctions d’autorisations de SPIP, soit par l’intermédiaire d’un plugin (ldéfinir des zones par accès restreint soit par une lame dédiée et peu connue du Couteau Suisse), soit... définir vos propres fonctions, c’est à dire pratiquer la surcharge de fonctions d’autorisation.

 Un exemple pour limiter l’accès à quelques articles

Imaginons que l’on veuille interdire la publication de certains articles : le statut ’publie’ ne peut être affecté que par une opération particulièrement contrôlée dans SPIP, surveillée par l’autorisation d’instituer
Par exemple, on rajoute dans mes_fonctions (à créer éventuellement dans ./config) :
après une ligne d’intro

  1. <?php
  2. _ if (!defined("_ECRIRE_INC_VERSION")) return;

Télécharger

....
les lignes d’exemples suivantes (en fonction des éléments voulus) :

  1. bloquer la publication d’articles ciblés :
    //  la liste des id_articles que l'on ne veut jamais voir publiés
    //  (plus facile à modifier ici que directement dans la fonction ci-dessous)
    define('MES_ARTICLES_BLOCK', '2:56:125:3');

    //  bloquer la publication
    function autoriser_instituer($faire, $type, $id, $qui, $opt) {
     if($type == 'article' AND in_array($id, explode(":", MES_ARTICLES_BLOCK))) {
       return false;
     }
     return autoriser('modifier', $type, $id, $qui, $opt);
    }

    La question initiale voulait même ne laisser que les choix de : ’redac’, ’prop’ et ’poub’ ; la réponse attendra....

Si vous voulez contrôler l’accès à des squelettes spécifiques, vous utiliserez plutôt la balise [ (#AUTORISER{...}|sinon_interdire_acces{}) ], en vous reportant aux divers articles sur Les autorisations / gestion des droits et les Autorisations Dans Spip.

 Utiliser les Autorisations de zones

Dans certains cas, vous allez vouloir piloter des autorisations pour des groupes fluctuants d’auteurs... que vous aimeriez changer avec une interface conviviale.
Les zones d’accès du plugin accès restreint proposent un outil éprouvé pour gérer des regroupements d’auteurs et d’accès, avec les droits d’éditions fondés sur la hiérarchie des rubriques ; toutefois, il n’est pas facile d’en utiliser le concept et le code pour s’en servir pour des autorisations dans vos pages de squelettes, quoique...
Une fonction filtres permet l’équivalent d’une autorisation sur les zones, mais sa syntaxe est bien moins explicite : la function accesrestreint_acces_zone($id_zone,$id_auteur=null) teste l’appartenance d’un auteur à une zone, ce qui permet d’écrire une balise SPIP
[(#VAL{id_zone}|accesrestreint_acces_zone|oui)]
sans doute moins lisible que [ (#AUTORISER{acces,zone,<code>}) ] [1], mais qui doit vous permettre de fonder une autorisation à l’auteur sur son appartenance à une zone numérotée !
Et pour valider l’accès à une rubrique [2], il existe aussi un filtre analogue, qui différentie en interne l’accès en espace privé ou public : la function accesrestreint_rubrique_restreinte($id_rubrique, $id_auteur=null) peut être utilisée de façon analogue pour un test equivalent à [ (#AUTORISER{voir, rubrique,id_rubrique}) ]...

 Approcher la programmation d’Acces Restreint

Cela a commencé sur IRC (en 2013...)

J’ai rencontré hier un comportement d’Accès restreint qui m’a paru (fonctionnellement) anormal : un simple Administrateur peut se rajouter les droits d’accès à une zone qui ne lui est pas ouverte !
Ne faudrait-il pas réserver ce comportement aux seuls Webmestres, ou conditionner l’accès aux Administrateurs déjà membres ?
(il est actuellement restreint aux non-admins complets !)

En fait, c’est bien la fonctionnalité qui était voulue (mais il faut le savoir..).
Avec un peu de recherches dans le code (du plugin), les autorisations en cause sont (dans inc/accesrestreint_autoriser.php) les suivantes :
- autoriser_zone_administrer et
- autoriser_auteur_affecterzones_dist [3].
Seuls les administrateurs complets non restreints, et les webmestres, ont cette possibilité.


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

[1Cela devrait s’écrire en rajoutant dans mes_options quelque chose comme :

  1. function autoriser_zone_acces_dist($faire, $type, $id, $qui, $opt) {
  2.    return accesrestreint_acces_zone($id, $qui['id_auteur']);
  3. }// mais je n'ai pas testé

Télécharger

[2Pour un traitement extérieur aux affichages d’objets éditoriaux déjà filtrés nativement par le plugin par exemple...

[3Le suffixe _dist indique que cette fonction est surchargeable par l’utilisateur : vous pouvez donc définir vos propres autorisations pour ceux qui affecteront les zones restreintes, mais un webmestre aura toujours la ressource d’aller bidouiller les tables ZONES et ZONES_LIENS...


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

Article publié le 13 décembre 2019, et actualisé en février 2020 Provisoire (à compléter...) .

Répondre à cet article