DokuWiki - comme la plupart des wikis - est très ouvert par défaut. Chacun peut y créer, éditer et effacer des pages. Toutefois il est compréhensible parfois de limiter l'accès à certaines ou à toutes les pages. C'est alors que les listes de contrôle d'accès (ACL) jouent leur rôle. Cette page vous livre une vue d'ensemble du fonctionnement des ACLs dans DokuWiki et sa configuration.

Les ACLs peuvent être activés à l'installation et une politique initiale minimale est créée à ce moment là. Tout peut être dorénavant configuré par interface graphique dans le gestionnaire de la liste des contrôles d'accès. Cependant, vous pouvez activer manuellement les ACL dans DokuWiki. Pour cela, veuillez configurer le paramètre useacl dans le gestionnaire des paramètres de configuration. Puis renommez ou copiez simplement les fichiers d’exemple conf/acl.auth.php.dist et conf/users.auth.php.dist en respectivement conf/acl.auth.php et conf/users.auth.php. et la page de procédure de connexion devrait fonctionner.

Il y a quelques options supplémentaires de configuration qui permettent le contrôle d'autres aspects des ACLs mais beaucoup trouveront les configurations par défaut satisfaisantes.

• Paramètre de configuration useacl – active les ACL. Un bouton S'identifier apparaît.
• Paramètre de configuration superuser – active le super-utilisateur avec tous les droits ACL.
• Paramètre de configuration disableactions – interdit l’enregistrement des utilisateurs.
• Paramètre de configuration defaultgroup – Groupe par défaut dans lequel les nouveaux utilisateurs. sont ajoutés.
• User Manager – gestionnaire des utilisateurs.
• Authentication Backends – identifie les utilisateurs depuis différents connecteurs d'authentification.
• FAQ: Comment désactiver l'inscription libre des utilisateurs ?

Sécurité: La fonctionnalité des ACL est présente dans DokuWiki depuis longtemps et s'avère plutôt stable. Pour la sécurité de vos données, ne mettez jamais des informations sensibles dans votre wiki qui sont, malgré la robustesse des ACL, potentiellement accessibles par internet.

Des restrictions d'accès peuvent être liées aux pages et aux espaces de noms. Il y a sept permissions : aucune (none), lire (read), modifier (edit), créer (create), téléverser sur le serveur (upload), effacer (delete) et administrer (admin). Les permissions de niveau plus élevé contiennent celles des niveaux inférieurs, aucune étant le niveau le plus bas et administrer le plus haut. Mais dans l'usage du wiki pour les utilisateurs lire est le plus bas et effacer est le plus haut niveau. Notez que les permissions de créer, télécharger et effacer ne sont assignées qu’aux espaces de noms.

Les règles définies aux espaces de noms s'appliquent aussi bien pour les médias et pour les pages des espaces de noms.

Quand DokuWiki contrôle les droits qu’il doit attribuer à un utilisateur, il utilise toutes les règles contenant le nom d’utilisateur ou de groupe.

La règle qui donne la permission la plus élevée est utilisée selon ce processus :

• Les règles qui correspondent aux permissions en proximité proche du namespace:page sont en priorité examinées (correspondance explicite spécifique à une page). Ensuite tous les espaces de noms supérieurs sont contrôlés jusqu'à ce qu'une règle soit trouvée.
• Quand plusieurs règles correspondent au même niveau, la règle donnant le plus de droits est retenue.

Les utilisateurs sont assignés dans des groupes via le gestionnaire d'utilisateurs ou depuis différents connecteurs d'authentification. Toutefois, deux groupes sont, d'une certaine manière, spéciaux :

• @ALL. Tout le monde, même les utilisateurs non connectés, est membre du groupe ALL. Vous pouvez utiliser ce groupe pour limiter l'accès à tous les utilisateurs (comme configuration par défaut) et autoriser certaines permissions pour quelques utilisateurs choisis.

• @user. Tous les utilisateurs qui se sont enregistrés sont automatiquement membres du groupe « user » par défaut. Utilisez-le pour attribuer des privilèges aux utilisateurs connectés. Le nom de ce groupe est configuré avec l'option defaultgroup. Contrairement au groupe virtuel « ALL » , le groupe « user » est un vrai groupe auquel tous les utilisateurs sont ajoutés automatiquement en utilisant l’authentification en mode texte. Si vous utilisez un autre mode d’authentification vous aurez besoin d'utiliser les groupes fournis par ce mode.

Les groupes sont représentés en interne et dans le gestionnaire des contrôles d'accès (ACL) par un préfixe, le caractère: @ suivi du nom du groupe. Par exemple: @user

Pour facilement ajouter ou changer des permissions dans la liste de contrôles d'accès, rendez-vous via le menu Administrer dans la Gestion de la liste des contrôles d'accès (ACL) dont vous trouverez le détail ici.

Pour ajouter une nouvelle règle, il y a essentiellement trois étapes:

1. sélectionner l'espace de noms ou la page, en navigant en haut à gauche dans l'arborescence de votre wiki.
2. choisisser à qui doit s'appliquer la règle :
   • en sélectionnant un groupe ou un utilisateur connu dans le menu déroulant ou,
   • en sélectionnant “User:” ou “Group:” et en entrant le nom d'un groupe ou d'un utilisateur dans le champ.
3. paramétrer la permission appropriée.

Les règles existantes peuvent être modifiées ou supprimées en bas dans le tableau du gestionnaire de la liste des contrôles d'accès (ACL).

Dans cette partie, nous allons voir comment les règles d'accès fonctionnent, en utilisant un exemple fictif tel qu'il peut apparaître dans le gestionnaire de la liste des contrôles d'accès (ACL).

Et les explications ligne par ligne :

1. Fixe la permission pour l’espace de nom principal. Permet à tout le monde d'éditer et de créer des pages. Cependant, on ne permet pas le téléversement.
2. l’utilisateur bigboss a tous les droits.
3. Restriction pour l’espace de nom devel. Personne n'est autorisé à y faire quoi que ce soit.
4. En fait pas vraiment personne - tous les droits sont donnés aux membres du groupe devel.
5. Et naturellement on donne les autorisations à l’utilisateur bigboss aussi, qui est le seul à pouvoir supprimer des fichiers téléversés.
6. Cependant, l'équipe “devel” ne veut pas que leur boss voit la page funstuff. Rappelez-vous que l'exacte correspondance explicite en droits d'une page surpasse les permissions supérieures d'un namespace.
7. Et pour finir, l'équipe marketing ont l'autorisation de modification de la page devel:marketing également.
8. Les permissions pour l’espace de nom marketing sont fixées. Tous les membres du groupe marketing sont autorisés à télécharger vers le serveur dans cet espace - les autres utilisateurs sont assignés par la ligne 1, ils sont limités à la création et à l’édition. L’utilisateur bigboss hérite de ses droits de la ligne 2 et peut aussi télécharger.
9. La dernière ligne concerne la page start qui est autorisée en lecture seule pour tout le monde. Seuls, les super-utilisateurs seront toujours capables de modifier cette page.

Essayons avec un deuxième exemple pour bien comprendre la correspondance explicite spécifique à une page.

Cette fois, nous allons examiner quelles sont les règles qui s'appliquent à différents utilisateurs qui veulent accéder à la page : private:bobspage.

1. abby, une utilisatrice normale, sans droits particuliers (regular user)
   • trois règles correspondent, #1, #2, #4
   • la règle #4 est la plus proche, elle correspond au niveau du namespace, donc, elle prend le dessus sur les trois règles précédentes.
   • le niveau d'autorisation de abby est Aucune (None)
2. bob, un utilisateur normal (regular user)
   • quatre règles correspondent, #1, #2, #4, #6
   • la règle #6 l'emporte comme correspondance explicite spécifique
   • le niveau d'autorisation de bob's est Effacer (Delete)
3. bob oublie de s'identifier et essaie d'accèder à sa page
   • deux règles correspondent, #1 & #4
   • la règle #4 est la plus proche, elle l'emporte
   • le niveau d'autorisation de bob quand il est non identifié est Aucune (None)
4. charlie, un membre du staff
   • cinq règles correspondent, #1– #5
   • deux règles correspondent au niveau du namespace, la #5 donne à charlie la plus haute permission et donc elle l'emporte
   • le niveau d'autorisation de charlie est Effacer (Delete)

Note: la règle #5 semble dire la même chose que la règle #3. Pourtant, sans elle, les membres du staff se verraient interdire d'accès au private namespace à cause de la règle #4.

Les restrictions d'accès sont archivées dans le fichier conf/acl.auth.php, qui doit être accessible en écriture par le serveur web si vous voulez utiliser le gestionnaire de la liste des contrôles d'accès (ACL). Il n'est pas recommandé d'éditer ce fichier manuellement. Il est préférable de passer par le menu d'administration.

Les lignes vides ou commentées sont ignorées. Chaque ligne contient 3 zones séparées par des espaces :

• La ressource à limiter. Ceci peut être un nom de page ou un espace de nom. Les espaces de noms sont marqués par un astérisque supplémentaire (voir ses exemples ci-dessous)
• Un groupe ou un nom d'utilisateur. Les noms de groupe commencent par le caractère @.
• Un niveau de permission (voir ci-dessous)

Il y a 7 niveaux de permissions représentés par un nombre entier. Les plus hauts niveaux incluent ceux qui sont en dessous. Ainsi si vous avez l'autorisation de modifier, vous pouvez également lire. Cependant, l'autorisation admin de 255 ne peut pas être utilisée dans le fichier conf/acl.auth.php. C'est géré en interne selon l'option superuser.

Voici un exemple :

*                     @ALL        4
*                     bigboss    16
devel:*               @ALL        0
devel:*               @devel      8
devel:*               bigboss    16
devel:*               @marketing  1
devel:funstuff        bigboss     0
devel:marketing       @marketing  2
marketing:*           @marketing  8
start                 @ALL        1

Please note that order does not matter in the file. The file is parsed as whole, then a perfect match for the current page/user combo is searched for. When a match is found further matching is aborted. If no match is found, group permissions for the current page are checked. If no match is found the check continues in the next higher namespace.

Note: To configure users or groups with special chars (like whitespaces) you need to URL escape them. This only applies to specialchars in the lower 128 byte range. The ACL file uses UTF-8 encoding so any multibytechars can be written as is.

Note: When using $conf['authtype'] = 'ad'; and groups names with spaces needing to be written in the acl.auth.php with a “%5f” replacing the spaces instead of “%20”. This is because Group names with spaces are first converted into underscores “_” which are “%5f”.

Note: The delete permission affects media files only. Pages can be deleted (and restored) by everyone with at least edit permission. Someone who has upload permissions but no delete permissions can not overwrite existing media files anymore.

It is possible to use user and group wildcards in the ACLs. This can be useful for Wikis with many registered users, if you want to give each user or group a personal namespace where only he/she has write access, and you don't want to edit the ACLs for each of them. To accomplish that %USER% is replaced by the username of the currently logged in user and %GROUP% by all the groups of this user.

In the following example a logged-in user gains full access (upload/delete) permissions for the user's namespace user:<username>:* and revoke all access from other namespaces located in user:*.

In this case logged-in user has access to own namespace only and have not access to users namespaces (even view names of namespaces) of other users.

#
# Grant full access to logged in user's namespace
user:%USER%:*          %USER%  AUTH_DELETE
#
# Allow to browse own namespace via the index
user:                  %USER%  AUTH_READ
#
# Allow read only access to start page located in "user" namespace 
user:start             %USER%  AUTH_READ
#
# Disable all access to user's home namespaces not owned by logged in user 
# (include view namespaces via the index) 
user:*                 @user   AUTH_NONE
#
# Allow members of 'group' to edit pages in the 'group' namespace.
# be careful, if you have a user namespace, all members of the default group 
# will gain access to it
%GROUP%:*               %GROUP% AUTH_EDIT

Note: version 2009-12-25c “Lemming” has some caveat. If you add, update or remove ACL entries from the admin interface then DokuWiki will replace %USER% in the second field of the ACL to %25USER%25 (this is bug FS#1955). To avoid this, change permissions manually only (by editing: conf/acl.auth.php) or correct them manually after each operation in the admin interface because %25USER%25 does not work as expected, only %USER% should be used in the conf/acl.auth.php. This bug is fixed in newer versions.

Note: The wildcard changed from @ to % in December 2008 – if you are upgrading from an older version you need to adjust your ACL setup accordingly.

— Philippe LAPEYRIE 2006-05-19 00:12
— Digitalin 2016-02-20 15:23 Mise à jour