acl
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
acl [2022-11-09 11:22] – d 185.24.184.214 | acl [2024-01-13 07:36] – removed 2001:8f8:153d:6d24:6551:761c:8300:c0ac | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Access Control Lists (ACL)s ====== | ||
- | [[DokuWiki]] --- like most wikis --- is very open by default. Everyone is allowed to create, edit and delete pages. However sometimes it makes sense to restrict access to certain or all pages. This is when the //Access Control List// (ACL) comes into play. This page gives an overview of how ACLs work in DokuWiki and how they are configured. | ||
- | |||
- | |||
- | ===== Configuration and Setup ===== | ||
- | |||
- | ACLs can be enabled in the [[installer]] and an initial ACL policy is set there as well. To manually enable ACLs, switch on the [[config: | ||
- | |||
- | |||
- | Example of a minimal '' | ||
- | |||
- | <file php conf/ | ||
- | # login: | ||
- | |||
- | admin: | ||
- | </ | ||
- | ==== See also ===== | ||
- | |||
- | There are a few more config options and features that relate to authentication, | ||
- | |||
- | * Config option [[config: | ||
- | * Config option [[config: | ||
- | * Config option [[config: | ||
- | * [[plugin: | ||
- | * [[auth|Authentication Backends]] -- identify users from different data sources | ||
- | * [[faq: | ||
- | |||
- | :!: **WARNING: | ||
- | |||
- | ===== Access Restrictions ===== | ||
- | |||
- | Access restrictions can be bound to [[pagename|pages]] and [[namespaces]]. There are seven permissions: | ||
- | |||
- | Rules that were set to namespaces apply on media namespaces as well as for page namespaces. | ||
- | |||
- | When DokuWiki checks which rights it should give to a user, it uses all rules matching the user's name or the groups he or she is in. The rule that provides a user's permission is chosen according to the following process: | ||
- | |||
- | * Rules which match closer to the namespace: | ||
- | * When more than one rule matches at the same level, the rule giving the highest access level is preferred. | ||
- | |||
- | Users are in the groups they were assigned to in the user manager (or the auth backend). However there are two **groups** that are somewhat special: | ||
- | |||
- | * **@ALL** Everyone, even users not logged in, is a member of the ALL group. You can use this group to restrict access for all users (as a default setting) and then relax the permissions for some selected users. | ||
- | * **@user** All self-registered users are by default automatically a member of the group ' | ||
- | |||
- | Groups are represented internally and in the ACL manager by a prepended '' | ||
- | |||
- | ==== Editing ACLs ==== | ||
- | |||
- | To easily add new or change existing access rules, you should use the [[plugin: | ||
- | |||
- | 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 " | ||
- | - 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: | ||
- | |||
- | {{: | ||
- | |||
- | 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 '' | ||
- | - 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 '' | ||
- | - The // | ||
- | - However the devel team doesn' | ||
- | - And finally the // | ||
- | - Then the permissions for the namespace '' | ||
- | * 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 // | ||
- | - The last line finally restricts the start page to readonly for everyone. Even for // | ||
- | |||
- | 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 '' | ||
- | |||
- | - 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 '' | ||
- | - bob, a regular user | ||
- | * four rules match, #1, #2, #4, #6 | ||
- | * rule #6 wins as its an exact match | ||
- | * bob's permission level is '' | ||
- | - 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 '' | ||
- | - 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' | ||
- | |||
- | Note rule #5, which appears to duplicate rule #3. Without it, staff members wouldn' | ||
- | |||
- | ===== Background Info ===== | ||
- | |||
- | Access restrictions are saved in a file called '' | ||
- | |||
- | 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 '' | ||
- | * 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 '' | ||
- | |||
- | ^ Name ^ Level ^ applies to ^ Permission ^ DokuWiki constant | ||
- | | none | 0 | pages, namespaces | ||
- | | read | 1 | pages, namespaces | ||
- | | edit | 2 | pages, namespaces | ||
- | | create | ||
- | | upload | ||
- | | delete | ||
- | | admin | ||
- | |||
- | Here is an example setup matching the first example given above: | ||
- | |||
- | < | ||
- | * | ||
- | * | ||
- | devel: | ||
- | devel: | ||
- | devel: | ||
- | devel: | ||
- | devel: | ||
- | devel: | ||
- | marketing: | ||
- | start | ||
- | </ | ||
- | |||
- | 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: | ||
- | |||
- | ==== User/Group Encoding ==== | ||
- | |||
- | Because the ACL configuration uses a few special characters to denote special functionality (like '' | ||
- | |||
- | 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> | ||
- | |||
- | The encoding uses URL encoding for all non-letter/ | ||
- | |||
- | Example: '' | ||
- | |||
- | |||
- | |||
- | |||
- | ==== 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 **'' | ||
- | |||
- | In the following example a logged-in user gains full access (upload/ | ||
- | |||
- | 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: | ||
- | # | ||
- | # Allow to browse own namespace via the index | ||
- | user: %USER% | ||
- | # | ||
- | # Allow read only access to start page located in " | ||
- | user: | ||
- | # | ||
- | # Disable all access to user's home namespaces not owned by logged in user | ||
- | # (include view namespaces via the index) | ||
- | user: | ||
- | # | ||
- | # Allow members of ' | ||
- | # BE CAREFUL, if you have a ' | ||
- | # will gain access to it since %GROUP% will be replaced literally | ||
- | %GROUP%: | ||
- | </ | ||
- | |||
- | :!: **Note:** version 2009-12-25c " | ||
- | |||
- | :!: **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. |
acl.txt · Last modified: 2024-08-28 09:14 by saggi