Bien sur, vous pouvez fixer des consignes d'écritures, de thèmes abordés lors de la rédaction des articles, une politique éditoriale. Mais ce n'est pas le propos de ce billet où je vais vous parler de la gestion des droits appliqués à la gestion et l'administration du site.

Un système de contrôle des droits permet de faire respecter l'autorisation (ou l'interdiction) d'effectuer certaines tâche sur certains objets. Traduit sous forme de code informatique appliqué à une gestion de contenu, nous devons après identification de l'utilisateur exécuter ou non, des portions de programme en tenant compte des objets manipulés et de leurs attributs.

Dans de nombreux systèmes, ces autorisations peuvent être gérées soit collectivement pour un groupe d'utilisateurs, soit individuellement pour chaque personne identifiée. Mais dans tout les cas, un système d'identification fiable doit être mis en place.

Aussi classiquement, on distingue pour chaque objet manipulé différentes tâches liées au cycle de vie de ce dernier. Ainsi pour un article, cela pourra être : la création, la rédaction, la mise en ligne, la modification, la suppression, ... Pour appliquer des restrictions ou autorisations sur ces objets, il faut que ceux-ci soit clairement identifiables et souvent leur adjoindre des informations de gestion (propriétaire, état, ...)

L'implantation des autorisations dans Dotclear

Le système Dotclear d'origine distingue quatre types d'utilisateurs :

  • les visiteurs, qui on le droit de visiter, de commenter, ou d'établir des tracback
  • les rédacteurs, qui outre les droit alloués aux visiteurs, peuvent rédiger des articles, les mettre en ligne ou les modifier.
  • les rédacteurs avancés, qui peuvent comme les 'simples' rédacteurs rédiger, mettre en ligne ou modifier leur articles, mais peuvent aussi exercer ce droit sur les article qu'ils n'ont pas eux même rédigés si ceux-ci ont été rédigés par de 'simples rédacteurs'.
  • le (ou les) administrateur(s), qui ont tous les droits.

Les rédacteurs et administrateurs sont référencés dans une table. Les visiteurs restent anonymes.

La gestion des autorisations, n'est prise en compte que dans la partie administration du site (en effet il n'y a pas d'identification pour la partie publique). Les restrictions portent :

  • sur l'exécution des outils d'administration du site. (définition des paramètres, sauvegarde,...)
  • sur la modification et la suppression des billets dont l'utilisateur n'est pas l'auteur.

Le tout est géré par l'objet $auth défini dans le code /inc/classes/class.auth.php. L'écran d'identification est codé dans /ecrire/auth.php.

La classe auth nous offre deux fonctions utiles pour vérifier que l'utilisateur courant possède les droits exigés pour poursuivre l'exécution des fonctions d'un niveau. La première force l'identification si celle si n'a pas encore été faite, la deuxième indique seulement l'accord ou le refus.

  boolean = check($level)
  boolean = userLevel($level)

Premières constatations

Le système permet plusieurs niveaux d'autorisation, mais ceux-ci restent fixés dans le code. Il n'est donc pas possible sans modification des sources d'origine de changer ces autorisations, ou d'ajouter des niveaux supplémentaires.

Si il existe une répartition des droits alloués entre les différents rédacteurs, celle-ci ne peut représenter une hiérarchie. Ainsi un 'rédacteur avancé' peut modifier, mettre hors ligne ou supprimer un billet de n'importe lequel des 'simples rédacteurs'. Cela ne correspond pas exactement au schéma où des 'rédacteurs' travaillent en groupes sous la responsabilité de 'rédacteurs chefs' n'ayant autorité que sur ce groupe.

Le système de gestion des droits n'est pas appliqué pour les fonctions issues des plugins (par défaut, les plugins ne sont accessibles qu'aux seuls 'administrateurs' ). Un 'simple rédacteur' ou un 'rédacteur avancé' ne peut donc pas utiliser le plugin galerie pour ajouter une série d'images, le plugin tags pour qualifié l'un de ses articles.

Seuls les objets de type 'articles' sont concernés par la gestion de droit sur dotclear. Les images ne sont pas contrôlées.

Dernière remarque mais celle-ci est de taille. Le système d'autorisations mis en place dans Dotclear gère les droits d'exécution de certaines parties de code sans tenir compte du contexte. Par exemple pour les fonctions de modification, mise en ligne et suppression de billet seul l'indication de l'auteur du billet est vérifié pour déterminer les autorisations. Les catégories, la présence de commentaires ou la mise en ligne n'entre pas dans les critères établissant les permissions.

Quelles idées en vrac pour des améliorations

Permettre d'adapter l'outil aux organisations en complétant les niveaux d'autorisation afin de séparer les tâches de rédaction, de validation et de mise en ligne pour adapter l'outil aux organisations des salles de rédactions ou des services de communication des entreprises.

Renforcer la notion d'appartenance des contenus gérés. En effet cette notion n'est présente que pour les billets. Les images et autres éléments multimédia n'appartiennent à personne. C'est à dire à tout le monde, ou seulement à l'administrateur selon le cas. De plus si relation entre les billets et les images sont explicitement définies dans le code des billets (par les liens), rien ne facilite la prise en compte de ce paramètre. Il est donc possible d'effacer une image alors que celle-ci reste utilisée dans un billet.

Tenir compte des informations de classement et lors de l'établissement des droits. Les billets sont actuellement classés dans des catégories. Pour calquer les organisations physique, on peut imaginer devoir attribuer des droits spécifiques à un rédacteur seulement pour les billets d'une catégorie.

Limiter la suppression, la modification, ou le remplacement des objets par des tiers non propriétaires. L'exemple des images : un 'rédacteur avancé' peut supprimer ou remplacer une image préalablement enregistrer servant d'illustration dans un billet auquel il n'a pas accès.

Étendre la gestion des droits aux objets autres que les billets. Pour cela permettre l'enregistrement de meta-données pour les images et autres éléments multimédia, ainsi que pour les catégories, établissant les notions d'identification et propriété.

Étendre la prise en compte du système de gestion des autorisations au codes externes fournis par les plugins.

Permettre de simplifier les contrôles pour les sites suivi par un seul rédacteur, ou par une équipe réduite.

Actuellement les autorisations sont contrôlées via un appel aux fonction check($level) ou userLevel($level). La version en cours de développement modifie légèrement ces appels en remplaçant le niveau d'autorisation requis, par la liste des droits nécessaires. C'est une avancée, mais je pense que ce système gardera son principal inconvénient, l'impossibilité de modifier le comportement du système sans modifier le code principal. En délégant le contrôle des droits à un module externe, les appels aux fonctions check() pourraient fournir un identificateur de checkpoint, qui pourrait être pris en compte par des règles établies par l'administrateur du site sans modification de code. Ces règles spécifieraient les rôles joués par les utilisateurs pouvant franchir le contrôle en fonction des éléments manipulés.

Distinguer les droits sur les objets publiés et les droits sur les modification du comportement de l'outil. Cela pourrai permettre l'intégration d'un moteur de workflow pour assurer la gestion des cycle de vie des documents.

En conclusion (provisoire)

Dotclear n'est pas un CMS, c'est un gestionnaire de Blog. Mais si d'aventure nous voudrions l'utiliser à plusieurs dans une organisation stricte, il doit être possible de modifier suffisamment le script pour lui intégrer des fonctions de contrôle et de gestion d'autorisations nécessaire.

D'ailleurs une simple modification, permet déjà de rendre possible l'utilisation des plugins par de simples rédacteurs.