Version 43 — Novembre 2013 — 77.203.xx.xx
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....
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..)
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 :
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.
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 c’est pas clair français ça et sans tester ou regarder le code je ne comprend pas : de l’occurence d’objet choisie ( un # ID_RUBRIQUE ou # ID_FORUM par exemple )
Si un #ID non nul est explicité exprimé , le plus souvent celui de la rubrique d’appartenance pour les Admins restreints, il servira au contrôle controle spécifique sur cette occurence , sinon ce sera une autorisation l’autorisation générique pour tous les objets de ce type . :
Debugging
Vous pouvez définir <code>define code >
define (’_DEBUG_AUTORISER’, true) ; dans mes_fonctions pour tracer les autorisations dans mes_fonctions tmp/spip .php pour tracer les autorisations dans tmp/spip.log [2] (voir log ( voir
ecrire/inc/autoriser.php[117]</code>). >
{{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]
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..) :
spip_auteurs_rubriques
en SPIP2)#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
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 [3] ; 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.
[4].
Le tableau ci-dessous donne un premier aperçu des commandes possibles [5], à 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 |
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 |
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)...
- 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 #AUTORISER{ecrire}
, #AUTORISER{configurer}
, et #AUTORISER{webmestre})
.
- 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
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 - http://core.spip.org/projects/spip/repository/entry/branches/spip-3-stable/ecrire/inc/autoriser.php#L739 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 » :
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 ?
voir le ticket http://core.spip.org/issues/3069
Voire les remarques sur SPIP.net :
- la rubrique 60. Statuts et Autorisations (vide)
- l’API « autoriser »
les balises #Autoriser et #Session,
- le filtre < code>|sinon_interdire_acces</code > pour renvoyer vers une page 404 ou 403 ....
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 [-> [ 4453.