Un rôle représente les permissions et les accès nécessaires pour effectuer une tâche. Une fois que les rôles ont été mis en place, on peut intuitivement les assigner, regrouper, transférer et partager avec les utilisateurs du CMS. Voici une approche directe de la mise en place des rôles dans Joomla.
Dans un précédent article, j'ai présenté un cas basé sur les rôles pour le contrôle de l’accès à un site géré par plusieurs personnes. L’utilisation des rôles est intuitive, l’attribution des rôles correspond aux responsabilités variées et en constante évolution du personnel. Des rôles bien conçus peuvent accorder aux utilisateurs seulement les accès et les permissions qui leurs sont nécessaires et rien d’autre.
L'approche basée sur les rôles est une dérogation à l'approche basée sur le niveau que nous avons utilisé avec Joomla 1.5 et à la configuration par défaut ACL en 2.5. Considérons les groupes traditionnels Auteur-> Editeur-> Publieur. À moins que les règles métier nécessitent comme contrainte que l'éditeur doit toujours être un auteur et qu’un publieur doit toujours être un éditeur, il n'est pas nécessaire de mettre en place ces héritages. Au lieu de cela, chacun pourrait partager public comme son parent, ce qui nous permettrai d'affecter un utilisateur à n'importe lequel de ces trois rôles indépendants. Qui a dit qu’un éditeur doit également être un auteur !
Une approche basée sur les rôles traverse les supposées frontières dans une perspective basée sur le niveau et que la version 2.5 a effacé.
En même temps que nous mettons en place des rôles, nous créons de nouveaux groupes et niveaux d'accès, établissant une hiérarchie plus plate de nos nouveaux groupes et attribuant des permissions avec parcimonie. Dans un framework basé sur les niveaux, ces pratiques semblent inadaptées. Pour trouver l’inspiration, il faut regarder au-delà de la configuration ACL traditionnelle. Voici une approche pour la mise en place des rôles dans Joomla.
Identifier les rôles dont votre client a besoin
Identifier les responsabilités CMS qui sont susceptibles d'être partagées ou transférées entre les utilisateurs. Un bon point de départ consiste à se concentrer sur chaque composant et d'examiner s'il doit avoir un rôle qui lui est propre. Cela semble trop simpliste, mais comme les rôles sont souvent liés à un seul composant, ceci se trouve être un bon point de départ. Et bien sûr, un rôle sera parfois responsable de plusieurs composants ou seulement de quelques parties d'un composant plus complexe. Quand vous devez identifier un rôle, définissez-le dans des termes simples et à la portée de ceux qui gèrent le site et son contenu.
Créer un groupe pour chaque rôle
Nous allons utiliser les "groupe d'utilisateurs" de Joomla pour représenter un rôle. Chaque rôle est représenté par son propre groupe. Si vous identifiez douze rôles, vous ajouterez donc douze nouveaux groupes d'utilisateurs. Chaque groupe attribuera un ensemble d'permissions et d'accès spécifiques à ce rôle - ni plus, ni moins. Le nom que vous utilisez pour le groupe sera le nom du rôle que le client verra lors de l'attribution des rôles aux utilisateurs, donc utilisez un nom intuitif, même s’il est composé de plusieurs mots.
Aplatir la hiérarchie de groupe
La plupart des rôles seront les fils d’un même parent et la hiérarchie sera peu profonde. Ceci est différent de l'héritage que nous avons vu en 1.5 et 2.5, où les groupes ayant un même parent sont rares et où l'héritage linéaire est récurrent. En revanche, la plupart des groupes basés sur les rôles partageront le même parent étant donné que la plupart des rôles sont indépendants des autres rôles. Il sera possible d'affecter un utilisateur à n'importe quelle combinaison de rôles sans chevauchements ou conflits.
Supposons que les groupes basés sur les rôles aient le même parent. Il faut tout de même être conscient que deux raisons courantes défendent l’idée d’ajouter un niveau supplémentaire d'héritage :
(1) Lorsque des groupes multiples partagent un certain nombre de permissions ou de niveaux d'accès, il est judicieux de créer un groupe parent qui représente ces permissions ou accès partagés.
(2) Lorsqu'un rôle doit inclure toutes les permissions et les accès d'un autre rôle, puis y en ajouter d’autres, ce rôle devrait être un héritage du rôle de base.
Typiquement plusieurs rôles devront avoir accès au backend, et c'est la raison pour laquelle il faut créer un groupe parent qui permet une Connexion à l'administration. Tous les rôles backend se partageront cet accès avec leur parent. Un groupe qui donne un accès backend nécessite une attention particulière sur deux points. Tout d'abord, allez dans Configuration Globale et paramétrez les permissions pour ce groupe afin de lui permettre une Connexion à l'administration. Ensuite, si vous voulez que le menu admin montre ces utilisateurs (pour certains sites vous ne pourrez pas), vous devez ajouter à ce nouveau groupe le niveau d'accès spécial. (Pourquoi ? Le menu administrateur est réglé sur le niveau d'accès spécial, et vous êtes chargé d’ajouter chaque groupe que vous créez dans les niveaux d'accès appropriés.)
Les rôles qui ne nécessitent pas d’accès backend peuvent partager public ou Registred avec leur parent, ou si vous trouvez cela plus intuitif, vous pouvez créer un groupe appelé Rôles Frontend dans le but de rassembler tous les rôles frontend sous un groupe parent unique.
Attribuez des permissions pour chaque rôle
En général, un rôle sera limité à un seul composant. Pour chaque groupe basé sur les rôles, allez au(x) composant(s) associé(s) et accordez les permissions nécessaires uniquement à ce groupe. Il n'est pas rare qu'un composant accorde des permissions seulement au Super Utilisateur, Administrateur et un groupe basé sur les rôles. En fait, il est préférable de retirer les permissions précédemment accordées à l'administrateur (et même Super Utilisateur) laissant ce groupe comme le seul conférant ces permissions.
Créer des niveaux d'accès basés sur les rôles
Il est utile ici de comprendre comment les niveaux d'accès s'insèrent dans la ACL. Mécaniquement, un niveau d'accès n'est rien d’autre qu’un regroupement de groupes d'utilisateurs. En réalité, le niveau d'accès représente les critères auxquels un utilisateur doit satisfaire pour déterminer si oui ou non cet utilisateur est membre du niveau d'accès en question (et mérite donc cet accès). Modules, options de menu, plugins, catégories, et même chaque article peuvent être associés à un niveau d'accès. Cette association est une association par règle qui indique à Joomla si oui ou non il affichera l'élément ou traitera le plugin – en se basant indirectement sur l'association d’un groupe à un utilisateur.
On peut dire que l’appellation "Niveau d'accès" pourrait être remplacé par "Règle d'accès". Bien que les réglages par défaut des niveaux d'accès (public, enregistré, spécial) sont mis en place pour représenter trois « niveaux » représentatifs, avec Joomla 2.5 il n’est pas possible de trouver des niveaux qui confèrent d’autres niveaux. Un niveau d'accès ne déclare qu'une série de groupes (dans n'importe quelle combinaison et sans se lier aux niveaux).
Nous allons utiliser cette prise de conscience à notre avantage. Si une partie quelconque du site (catégorie, module d'administration, menu, etc) doit être accessible uniquement à ceux qui sont associés à ce rôle, alors on créé un niveau d'accès basé sur les rôles qui ne comprend que ce groupe. Pour le moment, nous avons paramétré cela dans une relation one-to-one, afin que ce niveau d'accès permette l’accès uniquement à ceux qui ont été affectés à ce rôle. Si un utilisateur n'est pas associé à ce rôle, ils n’y aura pas accès. Gardez à l'esprit qu’un niveau d'accès basé sur les rôles n'est pas toujours nécessaire, mais si vous avez des options d'édition qui doivent être affichées que si l'utilisateur est affecté à un rôle particulier, alors vous aurez besoin d'un niveau d'accès correspondant.
Les conventions de nommage nous aident à gérer ce qui peut devenir une liste non-trivial. Je fais précéder chaque niveau d'accès basé sur les rôles d'un tilde (~).Puisque les niveaux d'accès sont répertoriés par ordre alphabétique, cela aide à repérer visuellement les niveaux d'accès basés sur les rôles et de les séparer des paramètres traditionnels (public, enregistré, spécial).
Restructurer votre ACL
La "Restructuration" est une pratique consistant à prendre des choses inutilement complexes et de les simplifier. En mathématiques, on simplifie 15/25 en 3/5. En programmation on prend le code et on le simplifie afin qu’avec moins de lignes il fasse toujours la même chose, ceci dans le but de le rendre plus lisible et compréhensible.
Ici, nous allons évaluer les groupes et les niveaux d'accès que nous avons créé et allons chercher un moyen de les simplifier. Peut-être qu’un ensemble de groupes nécessite la création d’un nouveau groupe parent commun pour des permissions de partage ou un niveau d'accès qu’ils partagent. Peut-être que certains niveaux d'accès basés sur les rôles ne sont pas vraiment nécessaires, ou il y a une nécessité d’en séparer un ou plusieurs dans un niveau d'accès unique. Si tout se passe bien, vous n'avez pas besoin de faire une restructuration, mais le faire pourrait conduire à une configuration plus intuitive.
Les modules admin
Un des grands avantages d'une approche basée sur les rôles, c'est que ceux qui gèrent le site via le backend peuvent avoir un tableau de bord qui affiche uniquement les choses auxquelles ils ont besoin d’accéder. Le menu d'administration ne doit pas montrer ce que l'utilisateur n'a pas la permission d'utiliser. Un moyen efficace de personnaliser le backend est de créer des modules admin, un par rôle, et d’attribuer chacun des modules à leur niveau d'accès basé sur les rôles respectifs. Chacun de ces modules peut contenir des informations ou des liens qui doivent être affichés uniquement pour les personnes affectées à ce niveau d'accès. Le backend affichera uniquement les modules correspondant aux rôles assignés à un utilisateur.
Affectation des utilisateurs aux rôles
Il est de notre responsabilité, en tant qu’intégrateurs, d'avoir créé et configuré les rôles qui correspondent aux besoins votre affaire. Si cela a été fait correctement, alors ce que nous proposons à nos clients est un système très intuitif pour la gestion de l’attribution des rôles. Il s'agit d'une simple checklist de rôles, chacun nommé de façon intuitive et conférant les permissions que l’on souhaite. C'est aussi simple que cela.
Ce qui pourrait ne pas être immédiatement évident est la nécessité d'avoir un rôle "Gestion des utilisateurs". Ce rôle particulier accorde la possibilité de créer des utilisateurs, modifier les paramètres et d’attribuer des groupes basés sur les rôles. Fidèle à la philosophie basée sur les rôles, ce rôle nous permet d'accorder à quelqu'un l’permission de gérer les utilisateurs et cela, sans avoir à les élever au rang d'administrateur. N’oubliez donc pas de créer ce rôle.
Pour renforcer cette approche directe, voici les étapes pour créer le rôle "Gestion des utilisateurs".
- Créer un nouveau groupe. Appelez-le "Gestion des utilisateurs." Son parent doit être un groupe qui a un accès backend. Si vous ne disposez pas d'un tel groupe, créez-le et donnez-lui les permissions de connexion admin et ajoutez-le au niveau d'accès spécial.
- Attribuez les permissions nécessaires. Depuis le backend allez à l’écran Utilisateurs et sélectionnez Paramètres. Dans la section "Gestion des utilisateurs" (et uniquement dans cette section) autorisez tout sauf "configurer". Ne donnez aucune autre permission.
- Niveaux d'accès. Dans ce cas, nous n'avons pas besoin d'un niveau d'accès basé sur les rôles parce que le menu principal sera automatiquement accessible à ceux qui en ont le droit. Cependant, si vous voulez fournir des modules admin qui seront disponibles seulement pour ceux qui gèrent les utilisateurs, alors vous aurez besoin de créer ce niveau d'accès basé sur les rôles pour ce rôle.
- Affectez un utilisateur seulement à ce rôle. Testez vos paramètres. Connectez-vous en tant que cet utilisateur au backend et observez avec quelle simplicité nous avons créé « Gestion des utilisateurs ».
Cet article offre une approche rapide de la configuration des rôles dans Joomla. Ce n’est pas difficile, mais mettre en place une ACL basée sur les rôles nécessite une nouvelle vision des choses. En êtes-vous capable ?
Articles qui devraient vous intéresser
Phoca Gallery 3.2.4 : une galerie Joomla pour vos photos
Réussir votre entreprise sur Internet grâce à Joomla
