====== Списки керування доступом (ACL) ====== [[DokuWiki]] --- як і більшість вікі --- за замовчуванням є дуже відкритою. Кожен має право створювати, редагувати та видаляти сторінки. Проте іноді має сенс обмежити доступ до певних або всіх сторінок. У таких випадках використовується //Список керування доступом// (ACL). Ця сторінка надає огляд того, як працюють ACL в DokuWiki та як їх налаштовувати. ===== Конфігурація та налаштування ===== ACL можна увімкнути в [[:installer|інсталяторі]], і там також встановлюється початкова політика ACL. Для вручного увімкнення ACL увімкніть параметр [[config: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''. Якщо ви використовуєте це, обов'язково змініть пароль пізніше. # login:passwordhash:Real Name:email:groups (comma[,] separated) admin:$2y$10$P5YH8uIM2uAE9snRq32yAuHMb4/XAzksFd5Cakqqtsw9BWeSsyLZq:admin:admin@admin.com:admin,user ==== Також дивіться ===== Є ще кілька параметрів конфігурації та функцій, що стосуються аутентифікації, реєстрації користувачів та налаштування ACL. Будь ласка, перевірте їх відповідні сторінки вікі, щоб отримати більше інформації: * Опція конфігурації [[config:useacl]] -- увімкнення використання ACL * Опція конфігурації [[config:superuser]] -- налаштування суперкористувачів з правами на надання ACL * Опція конфігурації [[config:defaultgroup]] -- група за замовчуванням, до якої додаються нові користувачі * [[plugin:usermanager|Менеджер користувачів]] -- керування користувачами * [[:auth|Механізми аутентифікації]] -- ідентифікація користувачів з різних джерел даних * [[faq:regdisable|ЧаП: Як вимкнути відкриту реєстрацію користувачів]] -- замінює $conf[openregister] :!: **УВАГА**: Функція ACL DokuWiki існує вже деякий час і повинна бути досить стабільною. Однак, якщо ви стурбовані ризиком неповноважного доступу до інформації у вашому вікі, ніколи не розміщуйте його на комп'ютері, доступному з Інтернету. ===== Обмеження доступу ===== Обмеження доступу можуть бути застосовані до [[:pagename|сторінок]] та [[:namespaces|просторів імен]]. Існує сім дозволів: //немає//, //читати//, //редагувати//, //створювати//, //завантажувати//, //видаляти// та //адмініструвати//. Кожен вищий дозвіл включає в себе нижчі, з читанням як найнижчим і видаленням як найвищим. Варто зазначити, що дозволи на створення, завантаження та видалення можуть бути надані лише для просторів імен. Правила, встановлені для просторів імен, застосовуються також до просторів імен медіа, а також до сторінкових просторів імен. Коли DokuWiki перевіряє, які права вона повинна надати користувачеві, вона використовує всі правила, які відповідають імені користувача або групам, до яких він належить. Правило, яке надає дозвіл користувачеві, вибирається відповідно до наступного процесу: * Правила, які відповідають ближче до простору імен:сторінки, переважають над правилами, які відповідають далі --- це ми називаємо "конкретним збігом". * Коли більше одного правила відповідає на тому ж рівні, вибирається правило, яке надає найвищий рівень доступу. Користувачі належать до груп, до яких їх було призначено в менеджері користувачів (або в автентифікаційній системі). Однак є дві **групи**, які дещо особливі: * **@ALL** --- Всі, навіть користувачі, які не увійшли в систему, є членами групи ALL. Ви можете використовувати цю групу, щоб обмежити доступ для всіх користувачів (як параметр за замовчуванням), а потім розширити дозволи для деяких обраних користувачів. * **@user** --- Усі самостійно зареєстровані користувачі за замовчуванням автоматично є членами групи 'user'. Використовуйте це для надання дозволів зареєстрованим користувачам. Назва цієї групи налаштовується через параметр [[config:defaultgroup]]. На відміну від віртуальної групи "ALL", група "user" є реальною групою, до якої всі користувачі автоматично додаються при використанні простої системи аутентифікації. Якщо ви використовуєте інший механізм, вам потрібно використовувати групи, надані цим механізмом.. Групи представлені внутрішньо і в менеджері ACL за допомогою попереджувального символу ''@'' перед назвою групи. ==== Editing ACLs ==== To easily add new or change existing access rules, you should use the [[plugin:acl|ACL Manager]] which is available from the Administration menu. A detailed description of its interface can be found [[plugin:acl|here]]. Basically there are three steps to add a new ACL rule: - select the namespace or page to restrict from the upper left tree navigation - 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 - set the appropriate permissions Existing rules can be modified or deleted in the table at the bottom of the ACL manager. ==== ACLs by Example ==== In this section we will explain how access rules work, using a fictional example setup that looks like this in the ACL manager: {{:aclexample.png}} Let's have a look at each line: - This sets permission for everyone in the main namespace, allowing everybody to edit and create pages. However upload is not allowed. - User //bigboss// is given full rights. - Now the access for the ''devel'' namespace is restricted. Nobody is allowed to do anything. - Well not nobody really---we give members of the //devel// group almost full rights here. Deleting files however is not allowed. - User //bigboss// however is allowed full access to the ''devel'' namespace. He/she can even delete uploaded files. - The //marketing// group may read everything in the ''devel'' namespace, but cannot edit or create pages. - However the devel team doesn't want their boss to see the ''funstuff'' page---remember exact pagematches override namespace permissions. - 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.) - 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//.) - 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**: {{:aclexample2.png}} This time we look what rules will match for different users when trying to access the page ''private:bobspage''. - 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'' - 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'' - 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'' - 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. ===== Background Info ===== 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 [[config:superuser]] option. ^ Name ^ Level ^ applies to ^ Permission ^ DokuWiki constant ^ | none | 0 | pages, namespaces | no permission---complete lock out | AUTH_NONE | | read | 1 | pages, namespaces | read permission | AUTH_READ | | edit | 2 | pages, namespaces | existing pages may be edited | AUTH_EDIT | | create | 4 | namespaces | new pages can be created | AUTH_CREATE | | upload | 8 | namespaces | mediafiles may be uploaded | AUTH_UPLOAD | | delete | 16 | namespaces | mediafiles may be overwritten or deleted | AUTH_DELETE | | admin | 255 | admin plugins | superuser((see [[config:superuser]])) can change admin settings | AUTH_ADMIN | 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 [[config:mediarevisions|media revisions]] option is enabled. ==== User/Group Encoding ==== 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 [[xref>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'' ==== User Wildcards ==== 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::*'' 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 [[https://bugs.dokuwiki.org/index.php?do=details&task_id=1955|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.