Accueil > Blog > Comprendre les droits et niveaux d'accès de Joomla!

Création et référencement de sites internet - centre de formation

Infogérance, intranets, sites web et formations: actualités et tutoriels

Comprendre les droits et niveaux d'accès de Joomla!

Les droits et accès du CMS Joomla!

Question abordée lors de nos formations sur le CMS Joomla! comment fonctionnent les droits ? On désigne dans un premier temps par le mot "droits" tout ce qui définit ce que les utilisateurs (en front ou en back office) peuvent voir et faire sur le site. Nous allons découvrir qu'il faut faire une distinction importante.

Principes de base avec Joomla!

Avec le CMS Joomla! on distingue en effet ce qu'on peut voir (les niveaux d'acces ou ACL -Access Control Lists- en anglais) de ce qu'on peut faire (les droits à proprement parler).

Ces deux notions sont très différentes et sont gérées en des endroits très différents du back office. Pour autant elles tirent toutes les deux leur origine dans la définition des groupes d'utilisateurs.

droits acl joomla groupes droits acls


Joomla! et les utilisateurs: les groupes

Les utilisateurs dans Joomla! sont des comptes qui peuvent se connecter en front ou en back office. Il existe aussi l'utilisateur 'invité' qui regroupe tout internaute qui visite le site sans se connecter.

Un utilisateur possède un identifiant et un email unique. Il appartient aussi à au moins un groupe d'utilisateurs (il peut faire partie de plusieurs groupes).

La notion fondamentale pour comprendre les niveaux d'accès et les droits de Joomla! est cette notion de groupe. Dans 99% des cas on ne va pas attribuer de droits ou de niveau d'accès à un utilisateur isolé mais à un groupe. L'utilisateur hérite des droits et des niveaux d'accès des groupes auxquels il appartient.

droits acl joomla groupes

On remarquera que les groupes sont rangés selon une hiérarchie qui prendra toute son importance dans la gestion des droits et des niveaux d'accès.

Les droits

Dans le menu Système / configuration et l'onglet DROITS on retrouve par groupe ce que les utilisateurs d'un groupent peuvent faire:

droits acl joomla config generale

C'est le point de départ pour cette matrice de droits qui va ensuite être surchargée dans les différents composants.

La hiérarchie des groupes définit un héritage des droits qu'on peut surcharger. La colonne 'droits appliqués' affiche le droit effectif pour le groupe sélectionné selon ce qui a été définit ici et aux niveaux supérieurs.

Les droits par composants

Une des grandes forces de la gestion de droits avec Joomla! reside dans son système de surcharge et d'héritage de la matrice de droits généraux composant par composant.

Ainsi pour le gestionnaire d'articles et de catégories (composant com_content) on retrouve cette matrice de droits au travers du bouton paramêtre
droits acl joomla droits articles


droits acl joomla droits articles detail


Ce même bouton Paramêtre se retrouve pour tous les composants (ou presque) de Joomla! Ainsi pour les menus on a aussi la matrice des droits par groupes.

droits acl joomla droits menus detail

Quand on regarde le détail de chaque droit pour chaque groupe on voit que plusieurs valeurs sont possibles :

  • Hérité - les droits globaux (depuis le menu Système / configuration) ou ceux des groupes parents seront utilisés.
  • Refusé - prévaut toujours, quels que soient les droits globaux ou ceux des groupes parents, et s'applique aux éléments enfants.
  • Autorisé - le groupe concerné pourra effectuer cette action dans ce composant sauf si les droits globaux sont différents.
droits acl joomla droits valeurs

Les niveaux d'accès (ou ACL)

Les niveaux d'accès contrôle ce qui peut être vu par les utilisateurs de tel ou tel groupe. On doit les comparer à des badges qu'on remet à des visiteurs ou employés d'une entreprise sensible dans laquelle toutes les salles ne sont pas accessibles par tout le monde.

Au départ un niveau d'accès n'est qu'un nom qui est attribué à un ou plusieurs groupes:

droits acl joomla niveaux

Dans Joomla! toutes les ressources (articles, catégories, lien de menu, module, etc...) est affectée d'un ACL. A l'affichage de chaque page Joomla! compare les ACLs de chaque ressource (ou élément de la page) avec le niveau d'accès attribué à l'internaute au travers des groupes auxquels il appartient. Par exemple pour les modules :

droits acl joomla acl modules

ou pour les articles:

droits acl joomla acl articles

Remarque importante: On distingue l'accès PUBLIC qui désigne en fait tout le monde (qu'il soit enregistré ou non) de l'accès INVITE qui désigne les internautes uniquement non enregistrés.

Ainsi selon l'appartenance à tel ou tel groupe un internaute se vera présenté un affichage différent de la même page (même url).

SEBLOD pour aller plus loin

Comme toujours SEBLOD permet d'étendre le CMS Joomla! tout en le respectant, c'est à dire sans le remplacer. Les notions de droits et de niveaux d'accès vont donc être identiques avec SEBLOD mais avec une granularité beaucoup plus fine.

Les droits avec SEBLOD

On a vu précédemment que la matrice de droits générale était surchargée par composant: chaque composant peut redéfinir les droits qui s'appliquent aux éléments qu'il contrôle (menus, mmodules, articles, etc...).

Avec SEBLOD on étend ce principe à un niveau supplémentaire : En effet chaque type de contenu hérite des articles Joomla! standards. Pour chaque type de contenu on va donc pouvoir modifier la configuration des droits qui hérite de celle de la gestion des articles qui hérite elle-même de la configuration générale.

droits acl joomla droits cck


droits acl joomla droits cck detail

Les ACLS avec SEBLOD

Chaque contenu SEBLOD (c'est à dire un super article Joomla!) dispose naturellement d'un niveau d'accès mais on peut descendre au niveau de chaque champ. Ainsi un même contenu affichera ou masquera des champs à un utilisateur selon son appartenance à tel ou tel groupes. Cela s'effectue au niveau de chaque champ auquel on affecte un niveau d'accès:

droits acl joomla droits acls champs




Gestion multisites avec les ACLs

Les ACLs sont aussi utilisé par SEBLOD pour gérer les projets multisites.

 Sites seblod

Si les domaines ont été définis en mode 'avancé': 

Nouveau site seblod

alors on se retrouve avec les ACLs suivantes :
ACL sites seblod
Ainsi pour chaque site SEBLOD définit un jeu d'ACL. Le niveau d'accès PUBLIC d'un projet Joomla! standard se transforme ici en un niveau d'accès 'public' pour chaque site.

Commentaires 5

 
Guest - Denis le jeudi 8 septembre 2016 21:24

Très bon rappel général sur la gestion des droits qui rend fou.

Une question simple, mais importante :
Supprimer définitivement un article dans la poubelle est ce possible sans être Super User?

Je suis obligé de donner le droits SU pour l'utilisateur pour qu'il puisse faire cette action ! (config Joomla)

Je gère ensuite tout l' affichage avec les niveaux d'accès pour que mon client n'ait pas le tableau de bord complet de Joomla, mais juste 2 simples boutons (création d'un module d'admin cpanel). Pour certain, éléments (les sliders Flexicontents par exemple) le niveau d'accès ne marche pas et " display: none " devient le seul moyen pour interdire l'accès.

Merci

Adieu Flexicontent, vive Seblod !

Très bon rappel général sur la gestion des droits qui rend fou. Une question simple, mais importante : [b]Supprimer définitivement un article dans la poubelle est ce possible sans être Super User?[/b][u][/u] Je suis obligé de donner le droits SU pour l'utilisateur pour qu'il puisse faire cette action ! (config Joomla) Je gère ensuite tout l' affichage avec les niveaux d'accès pour que mon client n'ait pas le tableau de bord complet de Joomla, mais juste 2 simples boutons (création d'un module d'admin cpanel). Pour certain, éléments (les sliders Flexicontents par exemple) le niveau d'accès ne marche pas et " display: none " devient le seul moyen pour interdire l'accès. Merci Adieu Flexicontent, vive Seblod !
cyril le vendredi 9 septembre 2016 13:05

Bonjour Denis

En front on peut très bien donner les droits de suppression d'un article d'un autre auteur à un groupe qui n'est pas SU. En back c'est possible aussi (acces gestionnaire) et effectivement SEBLOD nous donne un contrôle bien plus fin sur les config Joomla, principalement car on maîtrise le stockage des champs en base de données.

Cyril

Bonjour Denis En front on peut très bien donner les droits de suppression d'un article d'un autre auteur à un groupe qui n'est pas SU. En back c'est possible aussi (acces gestionnaire) et effectivement SEBLOD nous donne un contrôle bien plus fin sur les config Joomla, principalement car on maîtrise le stockage des champs en base de données. Cyril
Guest - Denis le vendredi 9 septembre 2016 13:50

Merci, Cyril

Effectivement sur un Joomla de base, en gestionnaire tout rentre dans l'ordre et je peux afin supprimer. (j'ai un peu honte)
Après bien des tests, je m'aperçois que c'est Flexicontent qui bloque cette action ! (ce CKK est vraiment spécial)

PS sur la mise à jour en Front ou Back :
Utilisation Back ou front. Tous mes utilisateurs/clients font leur mise à jour en back-office. Pourquoi ?
Mise à jour en front : à chaque fois que vous voulez voir « en réel » vos modifs, vous êtes obligé de faire « sauvegarde et fermer ». Cela oblige à un aller-retour incessant de cette action.
Mise à jour en Back : Vous modifier, vous sauvegarder sans quitter la page et voyez en direct sur la page du site en faisant une simple actualisation.

Je laisse ce choix de mise à jour à mes clients et, bien devinez quoi ? Ils laissent tous tomber la mise à jour Front !

Merci, Cyril Effectivement sur un Joomla de base, en gestionnaire tout rentre dans l'ordre et je peux afin supprimer. (j'ai un peu honte) Après bien des tests, je m'aperçois que c'est Flexicontent qui bloque cette action ! (ce CKK est vraiment spécial) PS sur la mise à jour en Front ou Back : Utilisation Back ou front. Tous mes utilisateurs/clients font leur mise à jour en back-office. Pourquoi ? Mise à jour en front : à chaque fois que vous voulez voir « en réel » vos modifs, vous êtes obligé de faire « sauvegarde et fermer ». Cela oblige à un aller-retour incessant de cette action. Mise à jour en Back : Vous modifier, vous sauvegarder sans quitter la page et voyez en direct sur la page du site en faisant une simple actualisation. Je laisse ce choix de mise à jour à mes clients et, bien devinez quoi ? Ils laissent tous tomber la mise à jour Front !
Guest - Aurelie le vendredi 28 décembre 2018 13:08

Bonjour

Petite question : Je suis actuellement à la recherche d'une solution pour limiter la visibilité (en front office) pour mes super user des blocs dépubliés. En effet aujourd'hui lorsque je suis connecté en tant que super user sur joomla et sur mon front et bien je vois la totalité des blocs présents sur une page, même ceux plus anciens ou en attente que j'ai dépublié. Cela me pose probléme car mes super user doivent faire une relecture du site en version espagnole et du coup il visualise une version qui n'est pas conforme ... Existe il une solution ??

Bonjour Petite question : Je suis actuellement à la recherche d'une solution pour limiter la visibilité (en front office) pour mes super user des blocs dépubliés. En effet aujourd'hui lorsque je suis connecté en tant que super user sur joomla et sur mon front et bien je vois la totalité des blocs présents sur une page, même ceux plus anciens ou en attente que j'ai dépublié. Cela me pose probléme car mes super user doivent faire une relecture du site en version espagnole et du coup il visualise une version qui n'est pas conforme ... Existe il une solution ??
cyril le vendredi 28 décembre 2018 13:44

Bonjour

il existe plusieurs voies:
* creer un groupe d'utilisateurs avec les droits necessaires à ces personnes sans que ce soit des super users. un super user n'a de sens qu'en back office
* avec un CCK comme SEBLOD il est très facile de présenter des gestionnaires de contenus filtrés qui masquent les articles non publiés. C'est ce que nous faisons régulièrement.

cordialement

cyril

Bonjour il existe plusieurs voies: * creer un groupe d'utilisateurs avec les droits necessaires à ces personnes sans que ce soit des super users. un super user n'a de sens qu'en back office * avec un CCK comme SEBLOD il est très facile de présenter des gestionnaires de contenus filtrés qui masquent les articles non publiés. C'est ce que nous faisons régulièrement. cordialement cyril
Guest
vendredi 15 novembre 2019

Image Captcha

Contactez-nous

et parlons de vos projets
Les champs marqués d'un * sont obligatoires.

Trouvez-nous

Paris, Hauts de France et dans le monde

Coordonnées de l'agence

Société Pulsar Informatique
25, rue du Cerf
95270 - LUZARCHES

Tel : 01 30 35 05 06
Fax : 01 30 35 00 56

Email : info(at)pulsar-informatique.com

Ce site utilise des cookies