À propos d’accès restreint, d’accès restreint par groupe, des groupes d’auteurs et de la gestion des droits

État des lieux à propos des restrictions d’accès

Le plugin accès restreint

Doc sur Contrib : http://www.spip-contrib.net/Le-plugin-Acces-Restreint

Les restrictions d’accès sont gérés par zones. Une zone est définie comme étant un ensemble de rubriques. Plus précisément, il s’agit d’une branche ou d’un ensemble de branches. Une branche correspond à l’ensemble d’une rubrique et de ses sous-rubriques.

Une zone est soit publique, soit privée, soit publique et privée. Dès lors qu’une zone est créée, l’ensemble de son contenu passe en accès restreint. L’ensemble des rubriques restreintes correspond donc à l’ensemble des rubriques appartenant à au moins une zone.

Dans un second temps, une fois les zones définies, des droits d’accès sont accordés aux auteurs en associant une ou plusieurs zones à chaque auteur. Le terme auteur correspond ici à son sens générique, à savoir tout individu enregistré dans la table spip_auteurs.

Dès lors qu’un auteur est associé à une zone, il a accès à l’ensemble du contenu de cette zone, indépendamment des autres zones.

Limites :

• Il n’est pas possible de définir une sous-zone au sein d’une zone. Prenons un exemple concret : une rubrique Conseil d’administration au sein d’une rubrique Espace membres ou bien un rubrique Espace enseignants ou sein d’une rubrique restreinte Classe de CE2. Dès lors qu’un auteur a accès à la rubrique Espace membres, il aura accès à la sous-rubrique Conseil d’Administration, même si une zone spécifique est créée. Il importe alors de modifier l’arborescence du site pour éviter d’avoir des sous-zones au sein d’une zone.
• Cela peut poser problème en cas de déplacement d’une rubrique. Si une rubrique restreinte est déplacée à l’intérieur d’une autre rubrique restreinte, les auteurs associés à la zone de la seconde rubrique auront accès de fait à la rubrique qui vient d’être déplacée.
• Si l’on doit gérer des droits différents selon l’espace public et l’espace privé, il faut créer autant de zones que nécessaires puis les associer convenablement aux auteurs. Dès lors que l’on gère des droits complexes, cela induit un grand nombre de zones et de nombreuses manipulations pour chaque auteur.
• Il peut être difficile d’avoir une vue d’ensemble des restrictions d’accès dès lors que le nombre de zones devient important.

Le plugin accès restreint par groupes

Doc sur contrib : http://www.spip-contrib.net/Le-plugin-acces-restreint-par

L’accent est mis ici sur des groupes d’auteurs. Les membres d’un groupe peuvent être définis directement, par statut et/ou par sous-groupes.

À chaque groupe peuvent être associés des propriétaires de groupes.

Un groupe peut restreindre l’accès du site à certaines rubriques. Les dites rubriques ne seront alors visibles que par les membres du groupes. Une rubrique est restreinte soit dans l’espace public, soit dans l’espace privé, soit dans les deux. Il semble qu’il soit possible de définir des sous-restriction d’accès : une sous rubrique pouvant être restreinte par un autre groupe.

Il n’y a pas de définitions explicites de zones restreintes. Elles sont implicites en fonction des restrictions posées par les différents groupes.

Les administrateurs de rubriques (admins restreints) ne peuvent modifier QUE les groupes qu’ils ont eux-même créés (= propriétaires). Cela permet de rester cohérent avec le fonctionnement de l’administration des rubriques : ils ne peuvent interdire l’accès qu’a l’intérieur de leurs rubriques. Ils peuvent utiliser des groupes créés par d’autres admins mais ne peuvent les modifier.

Limites :

• L’interface fournie la liste des rubriques gérées par chaque groupe. Cependant, il n’est pas toujours évident d’avoir une vue d’ensemble des restrictions d’accès. D’une part les rubriques sont affichées sans leur arborescence. D’autre part, il n’y a pas d’affichage clair pour repérer l’ensemble des groupes ayant accès à une rubrique donnée (par exemple concernant les rubriques communes à plusieurs groupes).
• Sur la page de modification d’un auteur, la liste des groupes auxquels il appartient n’est pas visible.
• Héritage des droits : si un auteur a accès à une sous-rubrique sans avoir accès à la rubrique parente, il aura accès à la sous-rubrique à condition d’entrer directement la bonne url puisque dans la navigation il ne verra pas la rubrique parente.

Autres limites et demandes générales à propos des restriction d’accès :

• Restriction des documents lorsque l’URL directe du document est entrée dans le navigateur.
• Définition de restriction d’accès à un objet particulier (un article précis par exemple), éventuellement par mot-clé
  – * Accès par adresse IP.
• Gestion d’autres types de droits selon le rubriquage du site (droit de rédaction, admins restreints, ...) Nécessite un interfaçage avec le plugin Autorité
• Gestion des flux RSS et iCal prenant en compte les restrictions d’accès
• Pouvoir tenir compte des restrictions d’accès dans les mails envoyés par Spip Listes
• Compatibilité avec le plugin Recherche étendue
• Compatibilité avec SPIP 1.9.3

À propos des groupes d’auteurs

Dès lors que l’on gère des restrictions d’accès, il semble nécessaire de pouvoir attribuer des droits à des groupes d’auteurs afin de faciliter leur gestion. La notion de groupes d’auteurs n’est pas spécifique à la question des accès restreints. Elle est plus générique.

De plus, la notion de groupes d’auteurs renvoie à l’oganisation sociale d’un collectif : nombre de structures sont organisées en groupes de travail.

Autres plugins ou fonctionnalités pouvant avoir besoin de groupes d’auteurs :

• SPIP-Listes pour envoyer des mails aux membres d’un groupe. La notion de liste privée renvoie implicitement à des groupes d’auteurs.
• PIM Agenda gère des groupes d’auteurs stockés dans une table spip_groupes
• Envoi de messages à des groupes dans la messagerie privée
• à compléter

Termes pour désigner des groupes d’auteurs :

Plusieurs noms ont déjà été employés pour qualifier des groupes d’auteurs dans le cadre des discussion sur la zone ou sur contrib :

• Groupes : peut prêter à confusion avec les groupes de mots-clés.
• Groupes d’auteurs : a priori le nom le plus explicite pour tous.
• Profils : inadéquat car ce terme désigne usuellement un ensemble d’informations concernant un individu donné.
• Cercles : en référence à la notion de cercle de travail, cercle militant etc. Terme permettant d’éviter toute confusion avec les groupes de mots-clés. Par contre, terme non intuitif pour une majorité.

Proposition : un plugin autonome

Dans la mesure où la notion de groupes d’auteurs est générique et peut être exploitée par plusieurs plugins, il semble pertinent que les fonctionnalités de gestion des groupes (définition, appartenance des auteurs, etc...) soit gérées par un plugin autonome sur lequel viendraient se brancher les différents plugins ayant besoin d’interagir avec des groupes. Ainsi, cela permet d’une part de mutualiser du code mais surtout de ne pas avoir à multiplier inutilement les définitions de groupes. Par exemple, il suffirait de définir une seule fois un groupe membres puis les droits d’accès de ce groupe seraient définis et spip-listes permettrait d’envoyer un mail à ce groupe sans avoir besoin de déclarer deux fois les membres du groupes.

Fonctionnalités :

S’inspirer d’accès restreint par groupes et à compléter.

• Définition directe des auteurs membres d’un groupe.
• Possibilité d’associer tous les individus ayant un certain statut.
• Notion de sous-groupe : les membres d’un groupe peuvent être automatiquement membres d’un autre groupe.
• Définition par mot-clés si le plugin mots-partout est activé (à discuter)
• Définition d’administrateur de groupes (appelés propriétaires du groupe dans accès restreint par groupe). Ces derniers sont autorisés à ajouter ou à retirer un auteur d’un groupe.
• Notion d’inscription publique, sur demande ou privée. Si inscription publique, les visiteurs peuvent directement s’inscrire à un groupe. Si sur demande, formulaire pour envoyer un mail de demande à l’admin du groupe. Si privée, groupe non visible dans les formulaires.
• Un groupe doit avoir un nom et un descriptif.
• La page de gestion d’un groupe d’auteurs doit fournir la liste complète des auteurs membres du groupe en précisant pour chacun la manière dont il est membre (définition directe, sous-groupe, statut...)
• Sur la page de gestion d’un auteur, il faut pouvoir visualiser la liste des groupes auxquels il appartient.
• Rajouter dans la messagerie privée du site la possibilité d’envoyer un message directement aux membres d’un groupe (voir s’il faut proposer tous les groupes ou seulement les groupes dont l’individu est membre).

API pour les autres plugins

• Mise en place de pipelines sur les pages de gestions des groupes dans l’espace privé.
• Un fichier uniquement, par exemple inc/groupesauteurs_api.php que les autres plugins auront à charger pour interagir avec les groupes.
• Fonctions groupesauteurs_liste_auteurs_groupe($id_groupeauteur) renvoyant la liste des auteurs membres d’un groupe donné et groupesauteurs_liste_groupes_auteur($id_auteur) renvoyant la liste des groupes auxquels appartient un auteur.

Gestion des restrictions d’accès : évolutions possibles

À propos de l’héritage des droits

Dès lors que des droits d’accès sont gérés à partir de l’arborescence du site, les espaces les plus génériques doivent être situés à la racine et les droits spécifiques plus loin dans l’arborescence. Ceci est l’inverse de certains systèmes de droits dans des OS informatiques où un individu peut avoir tous les droits dans sa rubrique et aucun droit à la racine du disque.

La logique est différente lorsque l’on raison en terme de droits d’accès sur un site puisque (pour la plus grande majorité des sites) le point d’entrée est la racine du site, puis on entre dans un secteur puis dans une sous-rubrique... La navigation naturelle est donc de partir de la racine puis d’avancer progressivement dans l’arborescence du site. De ce fait, concernant le fait de voir le contenu d’une rubrique, il semble pertinent qu’une rubrique ne sera visible que si l’on a accès à l’ensemble des rubriques parentes (respect de l’arborescence du site).

Ce type d’héritage est spécifique à des droits de type voir. Si l’on réfléchit à des droits tels que administrer une partie du site ou pouvoir rédiger dans une partie du site, cet héritage des droits à partir de la racine n’est pas nécessaire. C’est le cas des admins restreints par exemple. On peut être amené à pouvoir gérer un secteur donné sans avoir de droits sur la racine.

Accès restreint et groupes d’auteurs

Si l’on part du principe qu’il existe un plugin qui gère des groupes d’auteurs, deux possibilités peuvent être envisagées :

• ou bien le plugin de restriction des accès ne fonctionne qu’en complémentarité du plugin groupes d’auteurs,
• ou bien le plugin doit pouvoir fonctionner avec les groupes d’auteurs si celui-ci est activé et sans les groupes d’auteurs s’il n’est pas activé.

La première approche facilite le travail de programmation et évite de multiplier les tables dans la base de données. Il implique par contre que de maintenir le plugin groupes d’auteurs en parallèle de la maintance du plugin de gestion des accès restreint.

La seconde approche nécessite de prévoir dans le code les deux situations, de gérer ce qui se passe lorsque le plugin groupes d’auteurs est activé ou désactiver et ajoute plus de tables dans la base de données.

À titre personnel, je privilégierai la première approche.

Évolution 1 : simple interfacage avec les groupes d’auteurs

Le plugin accès restreint fonctionne de la même manière qu’aujourd’hui. Simplement, si le plugin groupes d’auteurs est activé sur le site, les zones sont associées à des groupes d’auteurs plutôt que directement à des auteurs. Cela ne résoud pas certaines des limites exposées précédemment.

La vérification de l’héritage des droits peut éventuellement être intégrée au plugin.

Évolution 2 : fonctionnement actuel avec petite modification de la règle d’accès

Une des solutions proposées sur la liste de discussion spip-zone (en mai juin de mémoire) consiste à poser que pour avoir accès à une rubrique, il faut avoir accès à toutes les zones auxquelles cette rubrique appartient (actuellement il suffit d’avoir accès à au moins une zone).

Cette modification permet de gérer la situation d’une rubrique Conseil d’administration au sein d’un secteur Membres (voir exemples précédents).

Cependant, conceptuellement, les notions d’accès et de zones deviennent dissociées. Une zone reste un ensemble de rubriques. Mais les rubriques restreintes ne correspondent plus à une zone. Elles deviennent implicitement définies en fonction des zones les unes par rapport aux autres.

Si l’on doit gérer des restrictions complexes, l’usage d’un tel système n’est pas forcément aisé puisqu’il faut multiplier le nombre de zones définies et garder en tête l’ensemble des zones définies.

Comme pour la proposition précédente, il est possible d’envisager un double fonctionnement (avec ou sans les groupes d’auteurs) et y ajouter la notion d’héritage des droits (il faut avoir accès à toutes les rubriques depuis la racine pour voir une rubrique données).

Évolution 3 : des verrous et des clés

Ce système repose sur l’analogie d’un immeuble dont la porte d’entrée principale serait la racine du site. Chaque rubrique correspond à une porte donnant sur une salle dans laquelle sont rangés les différents éléments du site. Une salle peut proposer d’autres portes (sous-rubriques) pour entrer plus avant dans l’immeuble.

Sur certaines portes, il existe des verrous. On ne peut donc franchir une porte verrouillée, sauf si l’on dispose de la clé adéquate.

Dans cette approche, les droits d’accès public et les droits d’accès privé sont définis séparément. Il y a donc des verrous publics et des verrous privés.

Dans un premier temps, il faut définir les verrous. Ils sont définis globalement pour le site. Lorsqu’un verrou est posé sur une rubrique, son contenu et ses sous-rubriques sont dès lors retirés des rubriques accessibles par défaut (visiteur non authentifié). L’ensemble des restrictions d’accès sont donc visibles globalement pour le site.

Les restrictions sont posés séparément pour l’espace public et pour l’espace privé. Pour restreindre une rubrique dans les deux espaces, il faut donc lui poser deux verrous : un verrou public et un verrou privé.

Dans un second temps, il faut attribuer des clés à chaque groupe. Dans la page de gestion d’un groupe, l’arborescence du site est affichée deux fois, une première fois pour attribuer des clés publiques et une seconde pour des clés privées. Seules les rubriques pour lesquelles un verrou a été défini offrent une case à cocher permettant de délivrer une clé à ce groupe.

Ce type d’approche permet de gérer sans problème la situation d’une sous-rubrique Conseil d’Administration au sein d’un secteur Espace membres.

Conceptuellement, alors que dans l’approche actuelle d’accès restreint, on définit explicitement des zones ce qui définit implicitement des verrous, on définit ici explicitement des verrous ce qui définit implicitement des zones. Les zones ne sont alors plus nécessairement des branches.

Afin de faciliter la gestion des droits pour l’utilisateur, sur la page de définitions des verrous, à côté de chaque verrou serait afficher la liste des groupes disposant de la clé correspondante.

Cette approche n’a d’intérêt qu’en interaction avec des groupes d’auteurs. Tout l’information peut être stockées dans une seule table, par exemple spip_verrous qui ne nécessite que trois champs : id_groupeauteur, id_rubrique et type. Les verrous correspondent aux cas où id_groupeauteur=0. Le champs type permet de distinguer les restrictions publiques et privées. Elle évite par ailleurs de multiplier les objets. En effet, dans une approche zones + groupes, il faut définir d’un côté des zones, de l’autre des groupes, puis les associer.

Par ailleurs, le fonctionnement est suffisamment général pour pouvoir élargir facilement ce système à d’autres types de droits. Par exemple restreindre les droits de rédaction à certaines rubriques (plutot que ne pas afficher les rubriques où un auteur n’a pas le droit de rédiger). La question des administrateurs restreints peut aussi être gérée par ce système. Seule différence, pour ce type de droits il n’est pas nécessaire de vérifier les droits depuis la racine (ce type de vérification étant spécifique aux autorisations de type voir).

Concernant les droits d’admins restreints, quand ils seraient gérés par le plugin, ils seraient appliqués aux admins du groupe concerné. Ainsi, il sera possible de faire correspondre la notion de gestion d’un groupe de travail avec celle de gestion éditoriale des articles produits par ce même groupe.

Cette approche consiste donc à faire évoluer accès restreint vers un outil de gestion générique des droits en fonction de l’arborescence du site. Une page de configuration du plugin permettrait à l’admin général d’activer ou de désactiver la gestion, par le plugin, de chaque type de droits.

Dès lors, il faut envisager la question de l’interfacage avec le plugin Autorité. Ce plugin permet en particulier de gérer les droits des individus en fonction du statut. On peut alors envisager un fonctionnement commun des deux plugins. Par exemple, Autorité pour définir ce que peut faire un rédacteur (par exemple un rédacteur peut modifier tout article proposé même s’il n’en est pas un des auteurs) tandis qu’avec les verrous on définit dans quelles rubriques un individu peut exercer ses droits de rédacteur. Ainsi, il devient possible de couvrir une grande variété de situations, plus ou moins complexes, en fonction des besoins de chaque site (intranet, revues, site perso...). Une des possibilités d’interaction entre les deux plugins consiste à ce qu’ils vérifient mutuellement s’ils sont activés. Par exemple, si acces_par_verrous est activé, autorité ne surcharge pas autotiser_article_modifier et dans le même temps, lorsque autorité est activé, acces_par_verrous vérifie si l’auteur a les droits de rédaction dans la rubrique puis applique les droits définis par autorité.

Faut-il aller vers un ou plusieurs plugins ?

La question qui se pose est de savoir s’il faut privilégier une approche par zones ou une approche par verrous. Il est également possible de considérer que ces deux types d’approches correspondent à deux types de besoins différents, auquel cas la co-existence de deux plugins peut être justifiée.

De même, certains souhaitent gérer des restrictions d’accès par objets et non selon l’arborescence du site. Il s’agit d’un autre type de besoin. À mon sens, il n’est pas pertinent d’avoir un plugin fourre tout qui gérerait à la fois des restrictions par l’objet et selon l’arborescence du site. Ce serait à mon avis un vrai casse-tête. Cela correspond à deux logiques de fonctionnement ou d’organisation et donc à mon sens à deux plugins séparés.

Si plusieurs plugins de restriction d’accès, selon des logiques différentes, devaient co-exister, il importe néanmoins faciliter leur suivi. Or, concernant la restriction d’accès, une partie du code serait commune aux différents plugins. En effet, ces différents plugins ne se distingueraient que par leurs fonctions listant les objets accessibles. Autrement dit, il est possible d’envisager que le code gérant la surcharge des boucles du site et celui filtrant l’espace privé soit centralisé au même endroit dans chaque plugin. Ainsi, les bugs observés et corrigés sur l’un des plugins pourront facilement être corrigés sur les autres plugins.

Ce code commun correspond à peu près, concernant le plugin accès restreint, aux fichiers acces_restreint_prive.php, acces_restreint_options.php et acces_restreint.php.

À propos des autres limites présentées plus haut et autres points de discussion

Restrictions par objet :

Il s’agit de pouvoir, par exemple, restreindre l’accès à un article particulier au sein d’une rubrique. Il me semble que cela nécessite un plugin autonome (à discuter), à besoin spécifique, plugin spécifique.

Qui peut accorder des droits à un auteur ?

Dans le forum de discussion de accès restreint, reviens régulièrement le problème concernant la capacité pour un admin restreint d’associer des zones à des auteurs. Dans le cadre de l’approche par groupes d’auteurs, la question est directement gérée par la notion d’admin de groupes. L’administrateur définit les administrateurs d’un groupe. Ces derniers peuvent dès lors associer ou retirer un auteur d’un groupe.

Flux RSS, iCal et autres :

Concernant le problème de récupérer dans un lecteur de flux un flux RSS prenant en compte les droits de l’individu, l’astuce actuelle consiste à utiliser une authentification http: http://login:motdepasse@monsite.net/spip.php?action=cookie&essai_auth_http=oui&url=spip.php?page=backend.

L’identifiant et le mot de passe apparaissent en clair dans l’url. Il semblerait que cette solution ne soit pas optimale. Cependant, cela concerne la problématique générale de l’authentification sur le site autrement que par un formulaire. Il faut voir s’il est prévu dans le core d’intérger un système générique d’identification par exemple avec low_id comme celui utilisé pour le flux iCal privé proposé en standard avec SPIP.

Concernant ce flux, une solution pour tenir compte des autorisations d’accès a été proposée au travers du plugin iCal privé étendu

Fonction autoriser_voir

Si plusieurs plugins de restriction d’accès existent, il importe qu’ils adoptent tous la même convention concernant le passage, via le paramètre $opt des fonctions autoriser_voir du champs publique ou privée.

Restrictions selon adresses IP

Cette demande revient régulièrement dans les forums. La question est de savoir si ce type d’authentification doit concerner uniquement les restrictions d’accès sur le site public ou bien s’il faut également tenir compte d’accès à l’espace privé auquel cas il faut pouvoir préciser à SPIP quels seront les droits (rédacteur, admin, etc...).

L’une des possibilités les plus génériques serait un plugin d’authentification par adresse IP qui, si la personne connectée sur le site n’est pas authentifié de manière classique, authentifiera la personne connectée, selon son adresse IP, à un auteur définit dans SPIP. Il pourra s’agir alors si besoin d’un auteur générique du type membre. Ainsi, ce type d’authentification sera compatible avec la gestion des accès restreint mais aussi de manière plus générique avec la gestion des autorisations diverses du site.

Il s’agit alors d’associer des adresses IP avec un auteur précis. A charge de ce plugin de venir surcharger les formulaires d’authentification en permettant à un individu authentifié par IP de s’identifier manuellement à un autre compte.

Restriction des documents

Il s’agit, lorsqu’un document est appelé directement par son URL, de vérifier ses droits avant de permettre de le télécharger. Il semble qu’il existe un tel système dans le core qu’il suffirait d’activer de manière adéquate.

Par ailleurs, reste la question d’un document associer à un article mais appelé dans un autre article via <doc123>. Le plus simple consiste à vérifier les droits du dits documents en fonction de l’article principal où il a été associé.

Cym prépare actuellement un petit plugin permettant d’associer un document à plusieurs articles. Pour se faire, le document est lié à plusieurs articles via plusieurs entrées dans la table spip_articles_documents. Il suffirait alors de vérifier simplement si le doc à charger est lié à au moins un article ou une rubrique visible par le visiteur.

Filtre accesgroupe_visualise

Ce filtre, proposé par le plugin accès restreint par groupes n’a pas d’équivalent dans le plugin accès restreint. Il convient de le reprendre.

Critère {id_acces_groupesauteurs} :

Nom du critère à améliorer probablement.

Si ce critère est passé à une boucle (en lui donnant via = ou IN un ou plusieurs id_groupesauteurs), la boucle renverra les objets visibles par le ou les groupes spécifiés dans le critère.

L’intérêt premier d’un tel critère est de permettre entre autres au plugin SPIP-Listes d’envoyer, par exemple, la liste des dernières nouveautés du site en tenant compte des droits de chaque destinataire.

Restrictions d’accès et outils de recherche :

Les fonctions de recherche sont en évolution actuellement. Il faudra vérifier si les restrictions d’accès sont correctement prises en compte. Par exemple, la nouvelle boucle créée par le plugin Recherche étendue ne prend pas en compte les restrictions d’accès (d’où problème pour compter le nombre de résultats et la pagination).

Rétro compatibilité

Quelque soit la ou les démarches retenues, il importe d’assurer une compatibilité à la fois avec la version SVN 1.9.3 en cours de stabilisation et avec la dernière version stable, à savoir la 1.9.2.

Deux possibilités de programmation :

• code en 1.9.2 et ajuster pour la compatibilité avec 1.9. 3
• code en 1.9.3 et, si version antérieure, charger un fichier de compatibilité.

En vu des suivis futurs, il me semble que la seconde approche est plus appropriée.

Enfin, une fois le développement stabilisé, il importe de fournir deux scripts permettant une MAJ de accès restreint ou de accès restreint par groupes vers les nouveaux plugins.