Listes de contrôle d'accès (ACL)
Les listes de contrôle d'accès (ACL) permettent aux administrateurs du wiki de donner à certains utilisateurs ou groupes d'utilisateurs le droit d'effectuer certaines actions (lire, écrire, supprimer) sur des pages déterminées. Ces listes permettent :
de cacher certaines pages aux visiteurs ;
de ne rendre accessibles que certaines pages aux visiteurs ;
de donner à quelqu'un ou à un groupe précis l'accès en écriture à une ou plusieurs pages ;
d'autoriser ou d'interdire la suppression des pages ;
- de contrôler qui peut gérer les droits d'accès à une page.
Pour utiliser les listes de contrôle d'accès, vous aurez besoin soit d'avoir accès au paramétrage du wiki (pour définir les droits d'accès communs au site), soit d'avoir les droits d'administration (admin) sur les pages dont vous souhaitez créer ou modifier les listes de contrôle d'accès des pages.
1. Sommaire
Sommaire
2. Bases
Les droits d'accès qu'il est possible de contrôler sont :
lecture (read) — qui peut lire une page ;
écriture (write) — qui peut modifier une page ;
suppression (delete) — qui peut supprimer une page ;
restauration (revert) — qui peut restaurer une version antérieure ;
administration (admin) — qui peut modifier la liste de contrôle d'accès (#acl) d'une page ;
L'utilisation de listes de contrôle d'accès dans MoinMoin est très simple : il suffit d'ajouter une ligne de contrôle en haut de la page que vous désirez contrôler. Cette ligne de contrôle ressemble à ceci :
#acl UnUtilisateur:read,write All:read
Vous devrez posséder les droits d'administration (admin) pour avoir le droit d'ajouter ou de modifier une telle ligne — pour plus d'informations, consultez l'AideDeParamétrage et l'AideD'AutoAdmin.
Cela permettra à UnUtilisateur de lire et d'écrire sur cette page et à tous les autres de lire cette page sans pouvoir y écrire (à moins que vous n'ayez mis en place des paramètres spécifiques dans la configuration du site).
Les pièces-jointes, lorsque l'on y accède via le moteur du wiki, sont également protégées par la liste de contrôle d'accès de la page à laquelle elle sont rattachées.
3. Paramétrage
Les options suivantes sont utilisées pour paramétrer les listes de contrôle d'accès :
Option |
Valeur par défaut |
Description |
acl_rights_before |
u"" |
Liste de contrôle d'accès appliquée avant la liste de la page ou la liste par défaut. |
acl_rights_after |
u"" |
Liste de contrôle d'accès appliquée après la liste de la page ou la liste par défaut. |
acl_rights_default |
u"Trusted:read,write,delete,revert \ |
Utilisé uniquement si aucune liste de contrôle d'accès n'est donnée dans la page accédée. |
acl_rights_valid |
["read", "write", "delete", "revert", "admin"] |
La liste des droits valides (reconnus) — et l'endroit où ajouter des extensions si nécessaire. |
acl_hierarchic |
False |
Active le traitement hiérarchique des listes de contrôle d'accès, voir la section Traitement hiérarchique des listes de contrôle d'accès. |
Ce tableau vous indique le rôle de chaque paramètre, mais pas ce qu'il signifie :
« avant » (before) correspond à imposer des règles (à cause de l'algorithme de première correspondance) — utilisez ce paramètre pour définir des droits d'administration ou d'édition étendus à tout le site ;
« par défaut » (default) indique ce qu'il faut faire si aucune liste de contrôle d'accès n'est indiquée sur la page. Cela fonctionne comme si l'on écrivait cette liste de contrôle d'accès sur une page. Ces droits seront de plus inclus dans la liste de contrôle d'accès d'une page si celle-ci contient le mot-clef Default.
« après » (after) correspond à s'assurer de ne rien oublier (par exemple en donnant le droit de lecture à tous le monde) ;
Il peut être utile de penser à ces paramètres comme les listes de contrôle d'accès appliquées avant, pendant et après le traitement des listes de contrôle d'accès de la page.
La notation u"" utilisée dans le paramétrages des listes de contrôle d'accès indique l'utilisation de chaînes de caracères Unicode. Leur utilisation est impérative — consultez l'AideDeParamétrage pour plus d'informations.
Si vous utilisez le paramétrage par défaut (anglais) de définition des noms de goupes, et que vous souhaitez utiliser des noms de groupes n'étant pas en CasseAlternée (p. ex. : « PROJECTGroup »), vous devrez modifier la définition par défaut des groupes page_group_regex en lui donnant pour valeur : u'[a-z0-9,A-Z]Group$'
Attention, la version française de cette page suppose que vous ayez configuré les groupes comme indiqué à la fin de la section Groupes.
4. Syntaxe
Chaque ligne doit respecter la syntaxe suivante :
#acl [+-]Nom[,Groupe,...]:[droit[,droit,...]] [[+-]AutreNom:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]
Où :
Nom est un nom d'utilisateur. La règle s'appliquera si le nom correspond.
Groupe est un nom de page correspondant à l'expression rationnelle page_group_regex. Cette page doit contenir des lignes du type « * Membre » (Voir la section Groupes).
Trusted est un groupe spécial contenant tous les utilisateurs authentifiés via HTTP (HTTP-Basic-authentication).
Known est un groupe spécial contenant tous les utilisateurs identifiés (par exemple, les utilisateurs reconnus via un cookie).
All est un groupe spécial contenant tous les utilisateurs (connus ou anonymes).
Default est une règle spéciale qui ajoute à l'endroit indiqué les règles par défaut définies dans acl_rights_default (voir la section Hériter des valeurs par défaut).
droit est un mot-clef choisi parmi read, write, delete, revert, admin. Seuls les mots-clefs définis dans le paramètre acl_rights_valid sont reconnus. Les autres seront ignorés. Il est possible de n'indiquer aucun droit, ce qui indique qu'aucun droit ne sera accordé aux utilisateurs correspondants.
N'ajoutez pas de blancs entre le nom et les droits associés : « All: write,read » ne sera pas une liste de contrôle d'accès correcte.
5. Définition des droits
Voici la liste des droits que vous pouvez utiliser dans les règles composant votre liste de contrôle d'accès. Attention cependant, l'utilisateur doit être membre (implicite) du groupe Known pour avoir le droit de renommer ou de supprimer une page, même si le droit de suppression (delete) lui a été accordé.
- read
- Les utilisateurs indiqués pourront lire le texte de cette page.
- write
- Les utilisateurs indiqués pourront écrire (éditer) le texte de cette page.
- delete
- Les utilisateurs indiqués pourront supprimer cette page et ses pièces jointes.
- revert
- Les utilisateurs indiqués pourront restaurer une ancienne version de cette page.
- admin
- Les utilisateurs indiqués bénéficieront des droits d'administration sur cette page. Ce qui veut dire qu'ils pourront modifier la liste de contrôle d'accès de cette page, y compris en donnant ou en supprimant les droits d'administration à d'autres.
Il n'existe pas de droit correspondant au renommage d'une page. Pour renommer une page, l'utilisateur doit disposer des droits de lecture (read), d'écriture (write) et de suppression (delete).
6. Logique de fonctionnement pour une page isolée
Lorsqu'un utilisateur essaie d'accéder à une ressource protégée par une liste de contrôle d'accès, celle-ci sera appliquée selon l'ordre où elle a été écrite. La première règle pouvant s'appliquer à l'utilisateur servira a déterminer si l'utilisateur a accès ou non à la ressource. Le traitement de la liste de contrôle d'accès s'arrêtera dès qu'une règle correspondant à l'utilisateur aura été trouvée.
Du fait du choix d'utiliser la première correspondance, il est préférable de trier vos listes de contrôle d'accès en indiquant en premier les noms d'utilisateurs individuels, puis les groupes spécialisés, suivis des groupes plus généraux, puis Known et enfin All.
Par exemple, la liste de contrôle d'accès suivante indique que UnUtilisateur à le droit de lire et d'écrire la ressource protégée. Tous les membres du groupe GroupeExemple (sauf UnUtilisateur s'il en fait partie) auront également le droit d'administrer cette page. Enfin, tous les autres utilisateurs auront le droit de la lire.
#acl UnUtilisateur:read,write GroupeExemple:read,write,admin All:read
Pour rendre ce système plus souple, il existe également deux modificateurs : les préfixes « + » et « - ». Lorsque ces modificateurs sont utilisés, le traitement de la liste de contrôle d'accès ne s'arrêtera que lorsque le droit demandé pour un utilisateur correspond à la fois à l'utilisateur et au droit indiqué dans la règle donnée. Le traitement continuera si l'on recherche un autre droit (ou un autre utilisateur). S'il y a correspondance, dans le cas de « + », le droit sera accordé, dans celui de « - », il sera refusé.
Par exemple, en supposant que UnUtilisateur soit membre du groupe GroupeExemple, la liste de contrôle d'accès ci-dessus pourrait être reformulée comme ceci :
#acl -UnUtilisateur:admin GroupeExemple:read,write,admin All:read
Cet exemple n'est particulier que pour UnUtilisateur, car lors de la vérification du droit d'administration pour UnUtilisateur, le droit sera refusé et le traitement de la liste s'arrêtera. Dans tous les autres cas, le traitement continuera.
Ou même :
#acl +All:read -UnUtilisateur:admin GroupeExemple:read,write,admin
+All:read indique que lorsqu'un utilisateur quel qu'il soit demande le droit de lecture, il lui est accordé et le traitement s'arrête. Dans tous les autres cas, le traitement de la liste se poursuivra. Lors de la vérification du droit d'administration pour UnUtilisateur, ce droit sera refusé et le traitement s'arrêtera. Dans tous les autres cas, le traitement de la liste se poursuivra. Enfin, si un membre de GroupeExemple demande un droit, il sera accordé s'il est indiqué ici et refusé autrement. Aucun autre utilisateur n'aura d'autre droit, à moins que ceux-ci soient donnés par la configuration.
Remarquez que les deuxième et troisième exemples ne sont pas très indiqués comme liste de contrôle d'accès d'une page. Ils peuvent par contre être très utiles dans les paramètres de configuration d'un site.
7. Hériter des valeurs par défaut
Il est parfois utile de donner des droits à quelqu'un sans trop modifier les droits par défaut. Par exemple, supposons que votre configuration contienne les paramètres suivants :
acl_rights_default = u"GroupeAuteur:read,write,delete,revert All:read" acl_rights_before = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"
Maintenant, vous souhaitez accorder à UnUtilisateur le droit d'écrire (write) sur une page, mais vous souhaitez conserver les droits par défaut des groupes ALL et GroupeAuteur. Vous pourrez facilement le faire en ajoutant une règle Default :
#acl UnUtilisateur:read,write Default
Cette règle va ajouter le contenu du paramètre acl_rights_default à l'endroit exact où est placé le mot Default. En d'autres termes, la liste ci-dessus associée au paramétrage indiqué sera équivalente à la liste suivante :
#acl UnUtilisateur:read,write GroupeAuteur:read,write,delete,revert All:read
Examinez maintenant le premier exemple de cette section :
acl_rights_before = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"
Les listes de contrôle d'accès sont traitées dans l'ordre suivant : liste du paramètre « avant » (before), liste de la page ou liste par défaut (default) puis, pour terminer, liste du paramètre « après » (after). Les listes de contrôle d'accès sont traitées de gauche à droite.
Donc, nous commençons à gauche de la liste contenue dans le paramètre before avec GroupeAdmin:... — cette règle s'applique si vous êtes un membre du groupe admin. S'il y a correspondance, les droits indiqués vous sont accordés (arwdr) et le traitement des listes de contrôle d'accès s'arrête.
S'il ne correspond pas, le traitement des listes continue. La règle suivante est : +GroupAuteur:admin — cette règle s'applique si vous êtes un membre du groupe auteur.
S'il y a correspondance, le droit (a) vous est accordé et — le cas est différent car la règle utilise un modificateur — le traitement des listes de contrôle d'accès continue ! Donc, s'il y a une autre correspondance pour ce groupe, votre nom d'utilisateur ou Known ou All vous bénéficierez également de ces droits.
S'il n'y a pas correspondance, le traitement continue.
Le traitement se poursuit donc avec la liste de contrôle d'accès de la page (s'il y en a une) ou la liste de contrôle d'accès par défaut (sinon), puis enfin par la liste de contrôle d'accès contenue dans le paramètre after.
Bien que ces listes soient équivalentes, hériter de la liste par défaut présente l'intérêt d'intégrer automatiquement toutes les modifications apportées à la liste de contrôle d'accès par défaut.
8. Traitement hiérarchique des listes de contrôle d'accès
Nouvelle fonction de la version 1.6.
Si vous avez activé l'option acl_hierachic (voir ci-dessus), les pages seront gérées en tenant compte de leurs relations hiérarchiques. Les droits appliqués aux pages situées au-dessus pourront influencer les droits des utilisateurs.
Le principe est simple, si les droits ne peuvent être déterminés avec la page en cours, la liste de contrôle d'accès de la page du niveau supérieur est vérifiée. Si celle-ci ne suffit pas pour déterminer l'accès, on remonte encore d'un niveau. Et ainsi de suite.
L'algorithme de correspondance appliqué à chaque page, tel qu'il est expliqué ci-dessus, reste le même. Cependant, la ligne #acl de la page est complétée par les listes de contrôle d'accès de chacune des pages de la hiérarchie, jusqu'à la racine. Pour une page appelée A/B/C/D, voici ce que donneront les deux modes de fonctionnement :
acl_hierarchic |
Séquence de traitement |
false |
acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after |
true |
acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_after |
Les règles acl_rights_before, acl_rights_default et acl_rights_after ne sont pas appliquées pour chaque page de la hiérarchie, mais une fois pour toute au cours du traitement de la page A/B/C/D. Les droits par défaut fonctionnent de la même façon qu'auparavant, mais ne seront appliqués que si aucune des pages de la hiérarchie ne contient de liste de contrôle d'accès. Il est donc parfaitement exact de dire que la ligne #acl de la page est remplacée par la somme de toutes les lignes #acl de la page et de ses parents.
9. Les groupes
Les groupes d'utilisateurs facilitent la définition des droits pour de plus grand nombres d'utilisateurs.
La paramétrage par défaut, adapté à la langue anglaise, définit un groupe comme une page dont le nom se termine par Group, comme par exemple FriendsGroup. Ce qui permet à MoinMoin de savoir que cette page contient une liste de noms d'utilisateurs. Il est possible de modifier le motif utilisé (par exemple pour les autres langues), reportez-vous pour cela à l'AideDeParamétrage.
Pour un wiki en langue française, nous vous recommandons d'adopter le paramétrage ci-dessous :
page_group_regex = u'^Groupe' # paramètre conseillé pour le français
Les exemples de cette page supposent que ce paramétrage, adapté à la langue française, est utilisé.
Seul les amis de UnUtilisateur peuvent lire et modifier cette page :
#acl UnUtilisateur:read,write UnUtilisateur/GroupeDesAmis:read,write
UnUtilisateur/GroupeDesAmis est une page contenant une liste de premier niveau dont chacune des entrées indique un nom d'utilisateur appartenant à ce groupe :
#acl UnUtilisateur:read,write,admin,delete,revert * JeanDupont * PierreDurand * PaulMartin
Le groupe GroupeAdmin peut être défini par une page de même nom protégée par une liste de contrôle d'accès :
#acl GroupeAdmin:admin,read,write All:read * UnUtilisateur * UnAutreUtilisateur * Ce texte est actuellement ignoré. Tout autre texte non situé dans la liste de premier niveau sera ignoré.
Une liste de premier niveau est une liste avec une seule espace avant l'astérisque (et une seule espace après). L'exemple suivant ne marche pas :
* un utilisateur -- l'astérisque est précédée de 2 espaces, donc ça ne marche pas.
Vous pouvez définir quels noms de pages sont considérées comme des pages de définition de groupes (par exemple pour des wikis nom-anglophones).
page_group_regex = u'[a-z]Group$' # valeur par défaut adaptée à un wiki anglophone
Si les modifications que vous avez apporté à une page de groupe ne sont pas pris en compte, supprimez tous les fichiers contenus dans le répertoire chemin_vers_votre_wiki/data/cache/wikidicts/, afin que MoinMoin reconstruise son cache.
10. Exemples d'utilisation
10.1. Wiki d'une communauté publique sur internet
Pour ce type d'utilisation, il est important de n'utiliser les listes de contrôle d'accès que là où c'est réellement nécessaire. Les wikis dépendent de la liberté d'accès à l'information et de la liberté d'édition. Ils se basent sur une sécurité douce pour nettoyer les entrées malveillantes. Donc, en général, les listes de contrôle d'accès ne sont pas nécessaires ; si vous en abusez, vous risquez de détruire ce qui fait la force des wikis.
C'est pourquoi soit les listes de contrôle d'accès ne devraient pas être utilisées du tout (ce qui est le paramétrage par défaut), soit, si elle sont utilisées, des paramètres tels que les paramètres ci-dessous devraient être utilisés dans le fichier wikiconfig.py :
acl_rights_before = u'NomÉditeur:read,write,admin,delete,revert +GroupeAdmin:admin PersonneMalveillante:'
La valeur par défaut du paramètre acl_rights_default devrait vous convenir :
acl_rights_default = u'Known:read,write,delete,revert All:read,write'
Il est recommandé d'avoir un petit groupe d'administrateurs de confiance dans le GroupeAdmin (ils devront bien connaître le fonctionnement d'un wiki, sinon, ils risquent de détruire sans le vouloir l'ouverture qui est la richesse d'un wiki).
Si vous utilisez un GroupeAdmin, créez une page appelée GroupeAdmin et utilisez-là pour indiquer la liste des personnes recevant les droits d'administration.
Indiquer PersonneMalveillante comme ci-dessus revient à empêcher cet utilisateur d'utiliser le wiki — il ne peut plus rien lire ni éditer avec son compte. Cela n'a de sens que comme mesure temporaire, autrement il vaut mieux carrément supprimer le compte. Naturellement, cette PersonneMalveillante peut aussi travailler anonymement, donc ce n'est pas une réelle protection (c'est ici que la sécurité douce entre en jeu).
10.2. Un système simple de gestion d'informations (CMS)
Si vous souhaitez utiliser le wiki pour créer simplement des pages web, mais que vous ne souhaitez pas que le public puisse le modifier (autrement dit, que les modifications soient limitées à un petit groupe de webmestres), vous pouvez utiliser une configuration comme celle-ci :
acl_rights_default = u'All:read' acl_rights_before = u'WebMestre,AutreWebMestre:read,write,admin,delete,revert'
Donc, tout le monde peut lire, mais seuls les webmestres peuvent faire quoi que ce soit d'autre. Tant que ceux-ci sont encore en train de travailler sur une nouvelle page, il peuvent indiquer sur celle-ci :
#acl All:
Ce qui implique que personne d'autre ne sera capable de consulter une page avant qu'elle ne soit prête. Lorsque la page sera terminée, n'oubliez pas d'enlever cette ligne, afin que acl_rights_default soit à nouveau utilisé.
Quelques pages peuvent aussi être utilisée pour permettre des commentaires du public (par exemple, une page VotreAvis). Vous devrez donc accorder plus de droits sur ces pages :
#acl All:read,write
10.3. Wiki sur un réseau interne (intranet)
Si vous souhaitez utiliser un wiki sur votre réseau interne d'entreprise et que vous avez suffisamment confiance en vos utilisateurs pour leur donner accès aux droits d'administration (vous pensez qu'ils ne réaliseront pas d'actions hostiles comme bloquer l'accès à certains utilisateurs ou détourner certaines pages), vous pouvez utiliser quelque-chose comme ceci :
acl_rights_default = u'Known:admin,read,write,delete,revert All:read,write' acl_rights_before = u'AdminWiki,GrandChef:read,write,admin,delete,revert'
Ce qui veut dire que tout le monde peut lire, écrire et modifier les droits et que AdminWiki et GrandChef sont assurés de toujours avoir tous les droits. Les utilisateurs identifiés (Known) obtiennent les droits d'administration via le paramètre par défaut (acl_rights_default) — autrement dit, ils on les droits d'administration tant que la page ne contient pas de liste de contrôle d'accès.
Conséquences :
sur une nouvelle page, le créateur de la page peut choisir la liste de contrôle d'accès qui lui convient ;
sur les pages existante sans liste de contrôle d'accès, tout utilisateur identifié (Known) peut ajouter la liste de contrôle d'accès de son choix ;
tout le monde (sauf AdminWiki et GrandChef) peut être empêché d'accéder à une page sans liste de contrôle d'accès par n'importe quel utilisateur identifié.
10.4. Site public d'une société
Si vous souhaitez utiliser un wiki comme site internet d'une société et que vous ne souhaitez pas que n'importe-qui puisse modifier le contenu du site, vous pourrez faire quelque-chose comme ceci :
acl_rights_default = u"GroupeAuteur:admin,read,write,delete,revert All:read" acl_rights_before = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"
Ce qui veut dire que :
par défaut, les utilisateurs identifiés (Known) et anonymes ont uniquement le droit de lire les pages ;
sur une nouvelle page, les membres du GroupeAuteur peuvent définir la liste de contrôle d'accès de leur choix ;
sur les pages existante sans liste de contrôle d'accès, tout membre du GroupeAuteur peut définir la liste de contrôle d'accès de son choix ;
tout le monde, sauf les membres du GroupeAdmin, peut être empêché d'accéder à une page par n'importe quel membre du groupe admin ou auteur ;
les membres du GroupeAuteur bénéficient des droits d'administration sur toutes les pages sur lesquels ils peuvent écrire, même si ces pages ont leurs propres listes de contrôle d'accès.
10.5. Commentaires sur une page en lecture seule
Il est facile d'ajouter une section commentaires à une page en lecture seule en utilisant une sous-page ouverte en écriture et en permettant aux utilisateurs d'y écrire. Par exemple, on peut définir UnePage comme ceci :
#acl UnUtilisateur:read,write All:read '''Quelques informations en lecture seule''' ... '''Commentaires utilisateurs''' <<Include(UnePage/Commentaires)>>
Et UnePage/Commentaires ainsi :
#acl All:read,write Ajoutez ici vos commentaires relatifs à la page UnePage.
11. Références
AideD'AutoAdmin : la fonction AutoAdmin, permet de déléguer à certains utilisateurs les droits d'administration sur un sous-ensemble du wiki.