DokuWiki – kiel plej multaj vikioj – estas tre malferma dekomence. Ĉiu rajtas krei, modifi kaj forigi paĝojn. Tamen foje havas sencon limigi aliron al iuj aŭ eĉ ĉiuj paĝoj. Tie AlirKontrolaj Listoj (AKL) eniras la ludon. Tiu paĝo devus doni al vi ideon kiel AKLoj funkcias en DokuWiki, kaj kiel ili estas agorditaj.

AVERTO: AKLoj de DokuWiki ekzistas nun kelkan tempon kaj devus esti sufiĉe stabilaj. Tamen, se vi timas la riskon, ke nerajtigito povus aliri informojn en via vikio, vi neniam metu ĝin en komputilon alireblan tra la interreto…

Por ebligi AKL en DokuWiki vi bezonas almenaŭ unu defaŭltan alirkontrolan liston. Simple kopiu la ekzemplajn dosierojn conf/acl.auth.php.dist kaj conf/users.auth.php.dist al conf/acl.auth.php respoektive conf/users.auth.php, kaj la ensaluta paĝo devus funkcii. Se vi ricevas erarmesaĝon “Ankoraŭ neniu AKL-agordo! Aliro al ĉiuj malpermesite.”, certigu, ke la komenca teksto en la dosiero acl.auth.php estas “acl.auth.php”, kaj ne “users.auth.php”. Vi ankaŭ devas plenigi iujn config-opciojn. Ni rigardu specimenon, kiun vi povas kopii al via local.php por ebligi la defaŭltan plentekstan aŭtentikadon kun publika registrado:

Bonvolu atenti, ke ĉiuj sekvaj agordoj povas esti farataj per la konfigurada asistanto en la administra menuo!

  $conf['useacl']       = 1;        // tio aktivigas AKL
  $conf['superuser']    = '@admin'; // grupo 'admin' estas la administranto

useacl aktivigas AKL. Kiam ĝi estas enŝaltita, butono “Ensalutu” aperas sub ĉiu vikipaĝo, kaj uzantoj povas registri sin mem. La opcio administranto difinas, kiu rajtas fari ĉion en DokuWiki (inkluzive aldoni novajn AKL-limigojn) - ĝi povas esti aŭ unusola uzanto aŭ grupo (markita per komenca @). Kiam vi agordas DokuWiki kun AKL de nulo pere de foliumilo, klaku la “Ensaluti”-butonon, sekvu la ligilon “registri”, kaj registru minimume unu uzanton. (Se vi ne vidas registran ligilon, la rajtoj de conf/users.auth.php aŭ conf/acl.auth.php estas malĝustaj, kaj neniuj novaj datenoj povas esti aldonitaj al ĝi.) Tiam modifu conf/users.auth.php kaj avancigu minimume unu uzanton de “user” al “admin”. Ekde tiam haveblas aldona butono “Administri”, se vi ensalutis kiel uzanto apartenanta al la administra grupo “admin”.

Tiupunkte aldona sekureca trajto povas esti aktivata. Por malpermesi, ke uzantoj mem registras sin, aldonu 'register' al la opcio 'disableactions':

  $conf['disableactions'] = 'register';        // uzantoj ne plu povas 
                                               // registri sin mem

La malnova maniero por tio estis en la arkaiĝinta opcio openregister.

Se tiu konduto estas dezirata, uzantoj povas esti aldonataj nur de administranto (aŭ tra la administra menuo aŭ tra rekta modifo de conf/users.auth.php).

Ekzistas aldonaj opcioj kontroli aspektojn de AKL, sed por multaj la standardaj agordoj sufiĉos.

$conf['autopasswd']  = 1;         // aŭtomate kreu pasvortojn kaj sendu retpoŝte
$conf['passcrypt']   = 'smd5';    // Uzu kaŝigan metodon 
                                  // (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';    // standarda grupo, al kiu novaj uzantoj aldoniĝas
$conf['profileconfirm'] = '1';    // bezonas aktualan pasvorton por konfirmi
                                  // ŝanĝojn en la uzanta profilo
$conf['authtype']     = 'plain';  // plenteksta bazo (standarda)

• Ŝanĝu autopasswd al 0 por ebligi al uzantoj elekti propran pasvorton dum registrado. Kiel flankefiko ne plu estas garantio, ke la uzanto uzas validan retpoŝtadreson.
• passcrypt difinas la enkriptan metodon por savitaj pasvortoj.
• defaultgroup klarigas sin mem: ĉiuj novaj uzantoj estos standarde aldonitaj tien.
• Metu profileconfirm al 0, se uzantoj rajtu ŝanĝi sian profilon (plena nomo, pasvorto kaj retpoŝtadreso) sen konfirmi sian aktualan pasvorton.
• DokuWiki povas uzi diversajn manierojn uzantajn kaj grupajn datenojn. Standarde ĝi uzas sian propran plentekstan bazon. La bazo estas elektita per la opcio authtype. Rigardu la bazo-paĝon por vidi haveblajn elektojn.

….

Uzantoj povas esti aldonataj, forigataj kaj modifataj per la uzantoadministrilo. Rigardu la priskribojn en plain backend por aldoni uzantojn permane. Standarde uzantoj povas registri sin mem.

Rigardu ankaŭ: FAQ: How to disable open user registration

Ekde rc2008-04-11 nova AKL 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 or she is in. The rule that provides a users permission is chosen according to the following process:

• rules which match closer to the namespace:page are preferred over rules which match further away.
• when more than one rule matches at the same level, the rule giving the highest access level is preferred.

To help understand this process, consider the ACL listing below, and some people trying to access private:bobspage

*                  @ALL     1      #1 grant all users read access to the wiki
*                  @users   2      #2 grant logged in users edit access to existing pages throughout the wiki
*                  @staff   16     #3 allow members of the staff group full access  to the wiki
private:*          @ALL     0      #4 prevent access to everyone, including logged in users
private:*          @staff   16     #5 counter rule #4 above, to allow staff members access to this namespace
private:bobspage   bob      16     #6 allow bob to access his page

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 0
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 16
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 0
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 16

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.

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 useful 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

Note: The wildcard was recently changed from @ to % in the latest version.

If you are trying to create dynamic user pages (as opposed to user name spaces in the above example) and don't want to have to create the user's page after they register, you will need to modify the ACL plugin to allow CREATE permission for pages:

Allow create permissions for pages (non-existant pages):

1) EDIT: /lib/plugins/acl/admin.php (Allow ACL to save CREATE perms for page)

Line 662 within function _html_checkboxes(…), change:

if($ispage && $perm > AUTH_EDIT){

to

if($ispage && $perm > AUTH_CREATE){

2) EDIT: /inc/auth.php (Prevent encoding of user wildcard)

Line 521 in function auth_nameencode(…), insert the code as shown:

function auth_nameencode($name,$skip_group=false){
  global $cache_authname;
  $cache =& $cache_authname;
  $name  = (string) $name;
 
  // *** Insert the Below code:
  if($name == '%USER%'){
        return($name);
  }
  // *** Insert the Above code.
 
  if (!isset($cache[$name][$skip_group])) {
...

Without these changes, your wildcard auth rule like the following will constantly get overwritten by the ACL:

people:%USER% %USER% 4

The above rule creates a private user page for each user in the people namespace with the page name the same as the username. — Sherri 2009/02/25 15:22

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

It is impossible to use the values created by Apache authentification. -user 2008-12-10

Can't use comma separated user list for one ACL rule. Is something wrong? -Vovaz 2009-02-24

Could anyone comment on how the ACL system handles media files? I just can't figure out how this works!
To be more precise: How isread/view access to media (/data/media) files handled? Is this always “in sync” with wiki files (/data/pages)? -user 2009-03-09

Is it possible at all, to set a minimum password-length, to prevent that users just go to their user-profile and set themselves a new password with only one letter or so?-user 2009-07-22