SpamikazeWiki:

Les listes de contrôle d'accès (ACL)

Les listes de contrôle d'accès (ACL) vous permettent de gérer les permissions d'utilisateurs individuels ou de groupes d'utilisateurs (que vous aurez créés, cf. l'AideDesGroupes). Vous pouvez définir des permissions sur l'ensemble du wiki ou sur des pages individuelles.

L'utilisation d'ACL permet, par exemple, de paramétrer le wiki pour être en lecture seule pour les utilisateurs anonymes. Vous pouvez également créer des pages qu'il ne sera pas possible de lire tant qu'elles ne seront pas prêtes à être publiées. Vous pouvez aussi limiter les droits de modification des pages à certains utilisateurs.

Pour utiliser les listes de contrôle d'accès, vous aurez besoin, soit d'avoir accès au fichier wikiconfig.py (pour définir les droits d'accès au site complet), soit de disposer des droits admin sur les pages dont vous souhaitez créer ou modifier les ACL.

Comprendre les permissions et les groupes

Permissions élémentaires

Les droits d'accès utilisables dans une ACL sont :

Il n'existe pas de droit séparé de renommage d'une page. Renommer une page nécessite de disposer des droits le lecture (read), d'écriture (write) et de suppression (delete).

Les utilisateurs anonymes (i. e. les utilisateurs ne s'étant pas identifié) ne pourront ni supprimer de pages, ni renommer de pages (même si les droits nécessaires sont donnés au groupe All, qui contient tous les utilisateurs).

Les pièces jointes sont protégées par la liste de contrôle d'accès de la page à laquelle elle sont rattachées.

Vous devez disposer de la permission admin pour ajouter ou modifier une ligne d'ACL à une page. Si vous êtes administrateur du wiki, assurez-vous de disposer des droits d'administration sur l'intégralité du wiki (cf. Paramétrage global ci-dessous).

La liste des permissions utilisables peut être réduite en utilisant le paramètre acl_rights_valid de votre fichier wikiconfig.py. Par exemple, inclure toutes les permissions sauf delete (supprimer) permet de s'assurer qu'aucune page du wiki ne pourra être supprimée (cf. Paramétrage global ci-dessous).

Groupes par défaut

Les permissions peuvent être données à des utilisateurs individuels, à des groupes (que vous définissez) ou à des groupes spéciaux (des groupes systèmes définis par défaut) :

Syntaxe et utilisation

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 doit être la première ligne de la page et ressembler à ceci :

#acl [+-]Utilisateur[,UnGroupe,...]:[permission[,permission,...]] [[+-]UnAutreUtilisateur:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]

Utilisateur, UnGroupe et permission (des permissions comme read, write, delete, revert, admin) sont définis dans les sections précédentes.

'Default' est une entrée spéciale qui ajoute à l'endroit donné les entrées de acl_rights_default. Reportez-vous à la section #Default ci-dessous pour plus d'information.

Ne placez pas d'espace entre le nom et les permissions. Par exemple All: write,read est incorrect.

Un exemple simple d'ACL pourrait être :

#acl JeanDupont:read,write,delete,revert,admin GroupeÉditeur:read,write,revert All:read

Dans cet exemple, JeanDupont peut lire, écrire ansi que réaliser tout autre action sur la page. Tout membre du GroupeÉditeur pourra lire, écrire et revenir à une version précédente. Tous les autres utilisateurs ne pourront que lire la page. (Attention, gardez à l'esprit que les paramètres de votre wikiconfig.py peuvent prendre le pas sur les ACL de certaines pages). Reportez-vous également aux exemples d'utilisation ci-dessous.

Paramétrage global

Les options suivantes sont utilisées pour paramétrer les listes de contrôle d'accès d'une manière globale à tout le site et sont définies dans le fichier wikiconfig.py (voir aussi l'AideDeParamétrage).

(!) Dans la table ci-dessous, les valeurs par défaut trop logue sont affichées sous la forme de points de suspension (« ... »). Déplacez votre souris sur ces points affichera la valeur par défaut dans une bulle d'aide.

Variable name Default Description
acl_hierarchic False True to use hierarchical ACLs
acl_rights_after u'' ACL that is processed after the on-page/default ACL
acl_rights_before u'' ACL that is processed before the on-page/default ACL
acl_rights_default ... ACL used if no ACL is specified on the page
acl_rights_valid ... Valid tokens for right sides of ACL entries.

Ce tableau vous indique le rôle de chaque paramètre, mais pas ce qu'il signifie :

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 caractères Unicode. Leur utilisation est impérative.

Traitement des listes de contrôle d'accès

Cette section est applicable à une page contenant une ACL mais peut également s'appliquer au wiki tout entier si l'ACL est incluse dans le paramétrage du wiki (cf. l'AideDeParamétrage).

Ordre de traitement des listes de contrôle d'accès

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 dans l'ordre suivant : 1) les noms d'utilisateurs individuels, 2) les groupes spécialisés, 3) les groupes plus généraux, p4) Known et enfin 5) 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 uniquement le droit de la lire.

#acl UnUtilisateur:read,write GroupeExemple:read,write,admin All:read

Préfixes modificateurs

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.

L'héritage via « Default »

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 — 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.

Traitement hiérarchique des listes de contrôle d'accès

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 la page en cours ne contient pas de ligne #acl, la liste de contrôle d'accès de la page du niveau supérieur est utilisée à la place (ou sa page mère, et cætera, jusqu'à ce qu'il n'y ait plus de page de niveau supérieur).

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 ou A/B/C ou A/B ou A ou [acl_rights_default], acl_rights_after

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.

{i} Attention — les versions de MoinMoin antérieures à la version 1.8.4 se comportaient différemment pour le traitement des ACL hiérarchiques : l'ACL de la page mère n'est plus ajoutée à la fin le l'ACL de la sous-page. Tous les droits relatifs à la sous-page doivent maintenant être explicitement indiqué dans celle-ci.

Exemples d'utilisation

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).

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 

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 :

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 :

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.

Références