DokuWiki — як і більшість вікі — за замовчуванням є дуже відкритою. Кожен має право створювати, редагувати та видаляти сторінки. Проте іноді має сенс обмежити доступ до певних або всіх сторінок. У таких випадках використовується Список керування доступом (ACL). Ця сторінка надає огляд того, як працюють ACL в DokuWiki та як їх налаштовувати.

ACL можна увімкнути в інсталяторі, і там також встановлюється початкова політика ACL. Для вручного увімкнення ACL увімкніть параметр useacl та створіть копії прикладових файлів conf/acl.auth.php.dist та conf/users.auth.php.dist. Перейменуйте файли в conf/acl.auth.php та conf/users.auth.php відповідно.

Приклад мінімального файлу conf/users.auth.php для користувача admin з паролем admin. Якщо ви використовуєте це, обов'язково змініть пароль пізніше.

conf/​users.auth.php

# login:passwordhash:Real Name:email:groups (comma[,] separated)

admin:$2y$10$P5YH8uIM2uAE9snRq32yAuHMb4/XAzksFd5Cakqqtsw9BWeSsyLZq:admin:admin@admin.com:admin,user

Є ще кілька параметрів конфігурації та функцій, що стосуються аутентифікації, реєстрації користувачів та налаштування ACL. Будь ласка, перевірте їх відповідні сторінки вікі, щоб отримати більше інформації:

• Опція конфігурації useacl – увімкнення використання ACL
• Опція конфігурації superuser – налаштування суперкористувачів з правами на надання ACL
• Опція конфігурації defaultgroup – група за замовчуванням, до якої додаються нові користувачі
• Менеджер користувачів – керування користувачами
• Механізми аутентифікації – ідентифікація користувачів з різних джерел даних
• ЧаП: Як вимкнути відкриту реєстрацію користувачів – замінює $conf[openregister]

УВАГА: Функція ACL DokuWiki існує вже деякий час і повинна бути досить стабільною. Однак, якщо ви стурбовані ризиком неповноважного доступу до інформації у вашому вікі, ніколи не розміщуйте його на комп'ютері, доступному з Інтернету.

Обмеження доступу можуть бути застосовані до сторінок та просторів імен. Існує сім дозволів: немає, читати, редагувати, створювати, завантажувати, видаляти та адмініструвати. Кожен вищий дозвіл включає в себе нижчі, з читанням як найнижчим і видаленням як найвищим. Варто зазначити, що дозволи на створення, завантаження та видалення можуть бути надані лише для просторів імен.

Правила, встановлені для просторів імен, застосовуються також до просторів імен медіа, а також до сторінкових просторів імен.

Коли DokuWiki перевіряє, які права вона повинна надати користувачеві, вона використовує всі правила, які відповідають імені користувача або групам, до яких він належить. Правило, яке надає дозвіл користувачеві, вибирається відповідно до наступного процесу:

• Правила, які відповідають ближче до простору імен:сторінки, переважають над правилами, які відповідають далі — це ми називаємо “конкретним збігом”.
• Коли більше одного правила відповідає на тому ж рівні, вибирається правило, яке надає найвищий рівень доступу.

Користувачі належать до груп, до яких їх було призначено в менеджері користувачів (або в автентифікаційній системі). Однак є дві групи, які дещо особливі:

• @ALL — Всі, навіть користувачі, які не увійшли в систему, є членами групи ALL. Ви можете використовувати цю групу, щоб обмежити доступ для всіх користувачів (як параметр за замовчуванням), а потім розширити дозволи для деяких обраних користувачів.
• @user — Усі самостійно зареєстровані користувачі за замовчуванням автоматично є членами групи 'user'. Використовуйте це для надання дозволів зареєстрованим користувачам. Назва цієї групи налаштовується через параметр defaultgroup. На відміну від віртуальної групи “ALL”, група “user” є реальною групою, до якої всі користувачі автоматично додаються при використанні простої системи аутентифікації. Якщо ви використовуєте інший механізм, вам потрібно використовувати групи, надані цим механізмом..

Групи представлені внутрішньо і в менеджері ACL за допомогою попереджувального символу @ перед назвою групи.

To easily add new or change existing access rules, you should use the ACL Manager which is available from the Administration menu. A detailed description of its interface can be found here.

Basically there are three steps to add a new ACL rule:

1. select the namespace or page to restrict from the upper left tree navigation
2. choose to whom the ACL rule should apply
   • by selecting a known group or user from the dropdown menu
   • or by selecting “User:” or “Group:” and entering the group or user name in the field
3. set the appropriate permissions

Existing rules can be modified or deleted in the table at the bottom of the ACL manager.

In this section we will explain how access rules work, using a fictional example setup that looks like this in the ACL manager:

Let's have a look at each line:

1. This sets permission for everyone in the main namespace, allowing everybody to edit and create pages. However upload is not allowed.
2. User bigboss is given full rights.
3. Now the access for the devel namespace is restricted. Nobody is allowed to do anything.
4. Well not nobody really—we give members of the devel group almost full rights here. Deleting files however is not allowed.
5. User bigboss however is allowed full access to the devel namespace. He/she can even delete uploaded files.
6. The marketing group may read everything in the devel namespace, but cannot edit or create pages.
7. However the devel team doesn't want their boss to see the funstuff page—remember exact pagematches override namespace permissions.
8. And finally the marketing group is allowed to edit the devel:marketing page as well. (This page could however not have been created by them.)
9. Then the permissions for the namespace marketing are set. All members of the marketing group are allowed to upload there
   • other users will be matched by line #1 so they can still create and edit.
   • Rights for bigboss are inherited from line #2 so this user can still upload and delete files. (No wonder that everyone would like to be the bigboss.)
10. The last line finally restricts the start page to readonly for everyone. Even for bigboss. Only superusers will be able to ever edit that page.

Let's have a look at a second example to better understand specific matching:

This time we look what rules will match for different users when trying to access the page private:bobspage.

1. abby, a regular user
   • three rules match, #1, #2, #4
   • rule #4 is closest, it matches at the namespace level so it takes precedence over the other three
   • abby's permissions level is None
2. bob, a regular user
   • four rules match, #1, #2, #4, #6
   • rule #6 wins as its an exact match
   • bob's permission level is Delete
3. bob forgets to login and tries to access his page
   • two rules match, #1 & #4
   • rule #4 is closer, it wins
   • bob's permission level while not logged in is None
4. charlie, a staff member
   • five rules match, #1–#5
   • two rules match at namespace level, #5 gives charlie the higher permission so it wins
   • charlie's permission level is Delete

Note rule #5, which appears to duplicate rule #3. Without it, staff members wouldn't be able to access the private namespace as rule #4 would keep them out.

Access restrictions are saved in a file called conf/acl.auth.php, which should be writable by the webserver if you want to use the ACL admin interface described above. It is not recommended to edit this file manually. Use the admin interface instead.

Empty lines and shell-style comments are ignored. Each line contains 3 whitespace separated fields:

• The resource to restrict. This can either be a pagename or a namespace. Namespaces are marked by an additional asterisk (see examples below).
• A group or user name. Groupnames are marked by a leading @ character.
• A permission level (see below).

There are 7 permission levels represented by an integer. Higher levels include lower ones. If you can edit you can read, too. However the admin permission of 255 can not be used in the conf/acl.auth.php file. It is only used internally by matching against the superuser option.

Here is an example setup matching the first example given above:

*                     @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: 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 only overwrite existing media files if the media revisions option is enabled.

Because the ACL configuration uses a few special characters to denote special functionality (like @ prefixes, spaces, etc), user and group names need to be encoded when they contain certain characters to avoid clashes.

When you use the ACL Manager you don't have to think about this, it will do it automatically for you.

When manually editing ACLs, user and group names need to be encoded. Internally this is done using the auth_nameencode() method.

The encoding uses URL encoding for all non-letter/number ASCII chars (special chars in the lower 128 byte range). UTF-8 Multibytechars are not encoded.

Example: Herbert.Müller becomes Herbert%2eMüller

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%  16
#
# Allow to browse own namespace via the index
user:                  %USER%  1
#
# Allow read only access to start page located in "user" namespace 
user:start             %USER%  1
#
# Disable all access to user's home namespaces not owned by logged in user 
# (include view namespaces via the index) 
user:*                 @user   0
#
# 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 since %GROUP% will be replaced literally
%GROUP%:*               %GROUP% 2

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.