Access Controls

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 Access Control Lists (ACL) come to play. This page should give you an overview how ACL works in DokuWiki and how they are configured.

WARNING: DokuWiki's ACL feature has now been included for some time and should be pretty stable. However, if you are concerned about the risk of unauthorized users accessing information in your wiki, you should never put it on a computer accessible from the Internet…

To enable ACL in DokuWiki, you need at least one default ACL. Simply copy the example files conf/acl.auth.php.dist and conf/users.auth.php.dist to conf/acl.auth.php and conf/users.auth.php respectively and the login page should work. If you get “No ACL setup yet! Denying access to everyone.” then make sure that the text in the beginning of the file acl.auth.php reads acl.auth.php and not users.auth.php.

You also need to set some config options. Let's have a look at a sample you could add to your local.php to enable the default plaintext authentication with public registration:

Please note that all the following config options can be set with the configuration manager in the admin menu!

  $conf['useacl']       = 1;        // this enables the ACL feature
  $conf['superuser']    = '@admin'; // admin group is superuser

useacl enables the ACL feature. Once this feature is enabled, a Login button appears at the bottom of every wiki page, and users can register themselves. The superuser option specifies who is able to do everything in DokuWiki (including adding new ACL restrictions) - this can either be a single user or a group (marked by a leading @). When you install a DokuWiki with ACL from scratch, using the browser, click the “Login” button, follow the “register” link, and register at least one user. (If you don't see a register link the permissions of conf/users.auth.php or conf/acl.auth.php are incorrect and no new data can be written to it.) Then, edit conf/users.auth.php and promote at least one user from “user” to “admin”. From then on there is an additional “Admin” button available if you are logged in as a user who belongs to the “admin” group.

At this point, an additional security feature can be enabled. To disallow users to register themselves add 'register' to the disableactions option:

  $conf['disableactions'] = 'register';        // users are no longer allowed to 
                                               // register themselves

The old way of doing this was the openregister option which is deprecated.

If this behaviour is desired, users can only be added by an admin (either through the admin web interface or by editing conf/users.auth.php directly).

There are some additional configuration options which allow control over other aspects of ACL but for which many will find the default settings satisfactory.

$conf['autopasswd']  = 1;         // autogenerate passwords and email them to user
$conf['passcrypt']   = 'smd5';    // Used crypt method 
                                  // (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';    // Default groups new Users are added to
$conf['profileconfirm'] = '1';    // Require current password to confirm changes to
                                  //  user profile
$conf['authtype']     = 'plain';  // plaintext backend (default)

• Change autopasswd to 0 to allow users to select their own password when registering. This has the side-effect of removing the guarantee that the user has registered with a valid email address.
• passcrypt determines the method of encryption used for storing passwords.
• defaultgroup is fairly self-explanatory: all new users will be added to this group by default.
• Set profileconfirm to 0 to allow a logged in user to change their profile (full name, password and email address) without having to confirm their current password.
• DokuWiki can use different ways to access user and group data. By default it uses its own plaintext backend. The backend is chosen by setting the authtype option. Have a look at the backends page to see which options are available.

….

Users can be added, removed and edited through the usermanager. For info on manually adding users see the descriptions in the plain backend documentation. By default users can register themselves as well.

See also: FAQ: How to disable open user registration

Since rc2008-04-11, a new ACL manager is shipped with DokuWiki. it uses radiobuttons instead of checkbuttons, and it is quite confusing how to apply the below logic to the new widget. Note: as mentioned below, higher access rights include all access rights below. So a radio button activates all rights from the left. For the new widget, it is probably better to read the next paragraph, Background Info.

Access restrictions can be bound to pages and namespaces. There are five permissions: read, edit, create, upload and delete. Each higher permission contains the lower ones, with read being the lowest and delete the highest one. You should note that create, upload and delete permissions can only be assigned to 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 is in. The rule which gives the highest permission is used. Permissions are checked for the page first, then all upper namespaces are checked until a matching rule is found.

To add a restriction rule, browse to the page you want to restrict and enter the administration interface by pressing the Admin button (only available to the superuser). There select Access Control List Management. You're then presented with a table like the following, showing you all restrictions relevant to the current page.

Restrictions are added in the top row of the table. You need to select the scope, which can be either the current page itself, or one of the namespaces it is in ¹⁾. You also need to choose who you want to give (or deny) access to; this can either be a group or a user. And finally, you need to select the actual permissions you want. Selecting none effectively locks out the specified user or group from the page or 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 not overwrite existing media files anymore.

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. For example, in the screenshot above, no one is allowed to upload, except members of the upload group.

user. All self-registered users are by default automatically a member of the group 'user'. Use this to give permissions to 'logged-in' users. The name of this group is configured through the defaultgroup option. Other than the virtual “ALL” group, the “user” group is a real group to which all users are added automatically when using the plain auth backend. If you use another backend you need to use the groups provided by this backend.

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. It is not recommended to edit this file manually. Use the admin interface instead.

Empty lines and shellstyle 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 should never be used in the conf/acl.auth.php file. It is only used internally by matching against the superuser option.

Here is an example:

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

Lets go through it line by line (though see below for more):

1. This sets permission for the main namespace. Allowing everybody to edit and create pages. However upload is not allowed.
2. User bigboss is given full rights
3. The permissions for the start page are restricted to readonly for everyone
4. 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. bigboss inherits his rights from line 2 so he can upload and delete files.
5. Now the access for the devel namespace is restricted. Nobody is allowed to do anything.
6. Well not nobody really – we give members of the devel group full rights here
7. And of course bigboss is allowed, too – and he's the only who can delete uploaded files
8. However the devel guys don't want their boss to see the funstuff page – remember exact pagematches override namespace permissions
9. And the marketing team may read everything in the devel namespace, too
10. And finally the marketing guys are allowed to edit the devel:marketing page as well.

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.

You can see this in the above example on the permissions for user bigboss. He is given full access in line 2, but needs to get full access for the devel:* namespace in line 7 again. If this line weren't there, the first match for user bigboss for a page inside the devel namespace would be line 5, because bigboss is member of the magic ALL group.

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. This only applies when a backend different from the plain one is used – the plain backend does not allow any special chars anyway.

As of the 2007-96-26b DokuWiki version it's possible to use Group wildcards in the ACLs. This can be usefull for Wikis with many registered users, if you want to give each user a personal namespace where only he/she has write access, and you don't want to edit the ACLs for each user. To accomplish that @USER@ is replaced by the username of the currently logged in user. In the following example a logged in user gains upload/delete permissions for the people:<username> page and the people:<username> namespace.

people:@USER@    @USER@    16
people:@USER@:*  @USER@    16

The ACL system currently doesn't trigger any events. Please consider this for future versions. -jmiller 2008-11-14