Boomtchak1. Parametrer le nom du composant
Un nom de composant definit de facon unique une zone de controle a l’interieur de PostNuke. C’est pourquoi vous devez choisir le nom de votre composant pour qu’il ne soit pas en conflit avec un autre composant, et pour qu’il n’y ait pas d’ambiguite pour l’administrateur du site lorsqu’il voudra definir des permissions.
Les composants sont constitues de trois parties, separees par des ( :).
Le nom du bloc comme défini dans $blocks_modules ?...?’text_type’
La seconde partie est renseignée par le systeme. Il s’agit du nom du bloc specifie par l’administrateur.
La troisieme partie est reservee pour l’instant. Laisser la vide.
Noter que parfois il est inutile de specifier le nom d’un composant. C’est le cas pour tout bloc n’incluant pas son propre contenu, et qui n’apporte pas une fonction separée. Dans ces situations, il est tout de meme preferable d’attribuer un nom au composant. Cela permet d’une part de voir les permissions d’utilisation du bloc, et d’autre part de reserver le nom pour le jour ou le bloc en aura besoin.
2. Definir un schema d’instance
Le schema d’instance de vos blocs définit le type d’information dependantes du contenu utilisees pour les permissions. Le schema d’instance est constitue de trois parties, separees par ( :). Ces parties sont completement independantes des fonctionnalites du bloc, et contiendront normalement des informations dynamiques.
Voici un exemple : un bloc qui affiche les statistiques du site et des utilisateurs. Les statistiques que vous avez sont les suivantes :
Utilisateurs en ligne ( ’Users on’ dans le bloc )
Nombre de hits/seconde de la page ( ’Page hits’ dans le bloc)
Votre instance pour le premier item sera ’Users on ::’ et la seconde sera ’Page hits ::’.
Votre schema d’instances est ’statistic name ::’.
Il permettra a un administrateur d’autoriser tout le monde a voir combien d’utilisateurs sont en ligne, mais de montrer le nombre de hit/secondes uniquement aux administrateurs.
Un autre exemple pourrait etre pour un menu, pour lequel l’instance correspond au titre.
< !—pagebreak—> 3. Configurer les permissions d’un bloc :
La premiere chose a faire est de declarer votre schema d’instace. Pour cela, ajouter les lignes suivantes directement apres la zone ’blocks_modules’ :
addinstanceschemainfo(’component’, ’instance’) ;
’component’ et ’instance’ ont ete definis au dessus.
Par exemple, pour le bloc ’Menu’ :
addinstanceschemainfo(’Menublock ::’, ’Link name ::’) ;
Ensuite, vous devez proteger toutes les operations avec les composants, instance et niveau d’acces adequats. Vous faites cela en appelant la fonction authorised()
authorised() prend quatre paramtres :
- realm : actuellement 0
- component : decrit ci-dessus
- instance : decrite ci-dessus
- access level : niveau d’acces minimum recquis pour permission. Les niveaux d’acces sont les suivants :
ACCESS_NONE Pas d’acces
ACCESS_OVERVIEW Autorise a lire un resume du contenu
ACCESS_READ Autorise a lire le contenu
ACCESS_COMMENT Autorise a commenter le contenu
ACCESS_MODERATE Autorise a moderer le contenu
ACCESS_EDIT Autorise a editer le contenu
ACCESS_ADD Autorise a ajouter du contenu
ACCESS_DELETE Autorise a effacer du contenu
ACCESS_ADMIN Acces complet
Ces niveaux d’acces sont cumulatifs. Une personne avec les droits EDIT peut aussi lire, commenter et moderer par exemple.
Par exemple, le bloc ’Menu’ autorisera l’affichage de liens standard de la facon suivante :
if (authorised(0, "Menublock :$blocktitle :", "$linktitle ::", ACCESS_READ))
// Affiche les liens
Vos papiers s’il vous plait !
Votre bloc pourrait avoir besoin de controler un composant etranger pour s’assurer que l’information qu’il donne est correcte. Un exemple de cela est le bloc qui liste les derniers articles par categories. Le bloc devrait controler le composant ’Stories ::’ pour chaque article qu’il veut afficher, pour confirmer que l’utilisateur a les permissions de le lire. Notez que dans ces cas là, il est crucial que le bloc corresponde a la bonne instance.
4. Pratiques saines :
- Controler les permissions a chaque fois que vous en avez besoin. Ne considerez pas qu’une permission controlee a un stade ulterieur de la navigation signifie que l’operation est autorisee. Cela vous assurera que de vilaines choses comme des URLs perverties vous arrivent et causent des degats.
- Controler au plus vite les permissions. Si l’utilisateur n’a le droit de rien faire avec un bloc, ne perdez pas de temps a generer de l’information qui ne sera pas affichee.
- Utiliser autant que possible l’information d’instance. Elle permet une gestion plus fine des permissions par l’administrateur et conduit a un systeme plus flexible.
- Laisser le systeme de gestion des permissions decider. Si vous voulez afficher un lien vers un module d’administration, demander l’autorisation au systeme de gestion des permissions par rapport au module que vous visez, et pas par rapport a votre bloc...
Exemples :
La plupart des blocs fournis avec Post Nuke utilisent ce systeme de permission. Un exemple interessant est le bloc ’includes/advblocks/stories.php’ qui contient tout ce dont il a ete question dans ce document.
Traduction francaise du site docs.postnuke.com par Sylvain Lemore, Get Electronique SA
RSS 2.0