DokuWiki is – zoals de meeste wiki's — standaard erg open. Het is iedereen toegestaan om pagina's aan te maken, te bewerken, en te verwijderen. Soms is het nuttig om de toegang te beperken tot bepaalde of alle pagina's. Hier komen de Access Control Lists (ACL) om de hoek kijken. Deze pagina moet je een overzicht geven van hoe ACLs werken in DokuWiki en hoe ze ingesteld worden.

ACLs kunnen aangezet worden in de installer en een initieel ACL-beleid kan daar meteen gekozen worden. Om handmatig ACLs aan te zetten, schakel je de useacl-optie in en kopieer je de voorbeeldbestanden conf/acl.auth.php.dist en conf/users.auth.php.dist naar conf/acl.auth.php en conf/users.auth.php respectievelijk.

Er zijn nog een aantal configuratieopties en functies die gerelateerd zijn aan authenticatie, gebruikersregistratie en ACL-instellingen. Bekijk de bijhorende wikipagina's voor meer informatie:

• Config optie useacl – inschakelen van ACL gebruik
• Config optie superuser – instellen superusers met ACL-toekenrechten
• Config optie disableactions – staat toe om de open registratie uit te schakelen
• Config optie defaultgroup – de standaardgroep waaraan nieuwe gebruikers worden toegevoegd
• User Manager – beheren van gebruikers
• Authentication Backends – identificeren van gebruikers vanuit verschillende databronnen
• FAQ: Hoe schakel je open gebruikersregistratie uit

WAARSCHUWING: DokuWiki's ACL functie is een tijd geleden toegevoegd en zou vrij stabiel moeten zijn. Als u zich zorgen maakt over de risico's van niet-geautoriseerde gebruikers die toegang krijgen tot informatie uit uw wiki, dan moet u die informatie nooit op een computer zetten die toegankelijk is vanaf internet.

Toegangsbeperkingen kunnen worden gekoppeld aan pagina's and namespaces. Er zijn zeven permissies: geen, lezen, bewerken, aanmaken, uploaden, verwijderen en beheer. Elke hogere permissie bevat ook de lagere permissies, waar lezen de laagste is en verwijderen de hoogste. Merk op dat het aanmaken, uploaden en verwijderen van permissies alleen toegekend kunnen worden aan namespaces.

Regels die ingesteld zijn voor namespaces gelden zowel voor media-namespaces als voor paginanamespaces.

Als DokuWiki controleert welke rechten het aan een gebruiker moet geven, zal het alle regels gebruiken die overeenkomen met de gebruikersnaam of de groepen waarin gebruiker zich bevindt. De regel die de permissie bepaalt voor de gebruiker wordt gekozen met het volgende proces:

• Regels die preciezer overeenkomen met de namespace:page hebben de voorkeur boven regels die ruimer overeenkomen – we noemen dit “specific matching”.
• Als er meer dan één regel overeenkomt op hetzelfde niveau, heeft de regel met het hoogste toegangsniveau de voorkeur.

Gebruikers zitten in de groepen waarin ze via de gebruikersmanager zijn geplaatst (of via de auth backend). Er zijn echter twee bijzondere groepen:

• @ALL. Iedereen, ook niet-ingelogde gebruikers, is lid van de ALL groep. Je kunt deze groep gebruiken om de toegang voor iedereen te beperken (als een basisinstelling) en om dan voor specifieke gebruikers de toegang weer wat vrijer in te stellen.
• @user. Alle zelf-geregistreerde gebruikers zijn standaard automatisch lid van de groep 'user'. Gebruik dit om permissies toe te kennen aan 'ingelogde' gebruikers. De naam van deze groep wordt ingesteld via de defaultgroup-optie. In tegenstelling tot de virtuele “ALL”-groep, is de “user”-groep een echte groep, waaraan alle gebruikers automatisch worden toegevoegd als de plain auth backend wordt gebruikt. Als je een andere backend gebruikt is het nodig om de groepen te gebruiken die geleverd worden door die backend.

Groepen worden intern en in de ACL manager weergegeven door de groepsnaam te laten beginnen met een @ (bijv. @user ).

Je kunt makkelijk nieuwe regels toevoegen of bestaande regels wijzigen, als je de ACL Manager gebruikt. Deze is beschikbaar via het Beheerdermenu. Een gedetailleerde beschrijving van de interface kan je hier vinden.

In principe kun je een nieuwe ACL-regel in drie stappen toevoegen:

1. Selecteer de namespace of pagina die beperkt moet worden van de navigatieboom linksboven.
2. Kies op wie de ACL-regel van toepassing is:
   • door een bekende groep of gebruik uit het keuzemenu te selecteren, of
   • door “Gebruiker:” of “Groep:” te selecteren en een groep of gebruikersnaam in te vullen in het veld.
3. Kies de juiste permissie.

Bestaande regels kunnen aangepast of verwijderd worden in de tabel onderaan de ACL manager.

In deze alinea willen we uitleggen hoe toegangsregels werken, door een verzonnen voorbeeld situatie die er als volgt uit ziet in de ACL manager:

Laten we elke lijn even apart bekijken:

1. Dit bepaalt de permissies voor iedereen in de hoofdnamespace, het staat iedereen toe om pagina's bewerken en aan te maken. Uploaden is wel niet toegestaan.
2. Gebruiker bigboss zijn alle rechten gegeven.
3. De toegang tot de devel namespace is ingeperkt. Niemand mag iets doen.
4. Hoewel eigenlijk niet niemand – hier worden de leden van devel-groep bijna alle rechten gegeven.
5. En natuurlijk is bigboss ook welkom – en hij is ook de enige die geüploade bestanden mag verwijderen.
6. En het marketing team mag alles lezen in devel namespace, maar dus alleen lezen.
7. De devel-jongens willen wel niet dat hun baas de pagina funstuff ziet – herinner dat exact overeenkomende paginanamen algemenere namespace permissies overschrijven.
8. En tot slot mogen de marketing-jongens de pagina devel:marketing bewerken.
9. Vervolgens worden de permissies voor de namespace marketing ingesteld. Alle leden van de marketing-groep mogen hier uploaden – andere gebruikers komen overeen met regel 1, dus zij mogen alleen aanmaken en bewerken. bigboss erft zijn rechten van regel 2 dus hij mag uploaden en bestanden verwijderen.
10. De laatste regel beperkt uiteindelijk de permissies voor de startpagina tot leesrechten voor iedereen. Alleen superusers mogen deze pagina aanpassen.

Bekijk het tweede voorbeeld om beter te begrijpen hoe specific matching werkt:

Nu kijken we welke regels passen voor de verschillende gebruikers als zijn proberen toegang te krijgen tot de pagina private:bobspage.

1. abby, een gewone gebruiker
   • drie regels zijn actief, #1, #2, #4
   • regel #4 is het meest nauwkeurig, het komt overeen op namespace-niveau en gaat dus voor op andere twee regels
   • abby's permissieniveau is 0
2. bob, een gewone gebruiker
   • vier regels zijn actief, #1, #2, #4, #6
   • regel #6 wint omdat die exact overeenkomt
   • bob's permissieniveau is 16
3. bob vergeet om in te loggen en probeert toegang te krijgen tot zijn pagina
   • twee regels zijn actief, #1 & #4
   • regel #4 is het meest nauwkeurig, die wint
   • bob's permissieniveau, nu hij niet is ingelogd, is 0
4. charlie, een staflid
   • vijf regels zijn actief, #1 - #5
   • twee regels komen overeen op namespace-niveau, #5 geeft charlie hogere permissies en wint dus
   • charlie's permissiesniveau is 16

Let op rule #5, deze lijkt een duplicaat van regel #3. Zonder deze regel, hebben stafleden geen toegang tot de private namespace omdat regel #4 hen uitsluit.

Toegangsbeperkingen worden opgeslagen in een bestand genaamd conf/acl.auth.php, deze moet beschrijfbaar zijn voor de webserver als je de hierboven beschreven ACL beheerinterface wilt gebruiken. Het wordt niet aanbevolen om dit bestand handmatig aan te passen. Gebruik hiervoor liever de beheerinterface.

Lege regels en shell-stijl commentaar worden genegeerd. Elke regel bevat 3 met spaties gescheiden velden:

• De bron die beperkt wordt. Dit een pagename of een namespace zijn. Namespaces worden gemarkeerd met een extra asterisk (zie de voorbeelden hieronder).
• Een groep of een gebruikersnaam. Groepsnamen worden gemarkeerd door te beginnen met een @-teken.
• Een permissieniveau (zie hieronder).

Er zijn 7 permissieniveau's weergegeven met een integer. Hogere niveau's omvatten ook de lagere. Als je kunt bewerken kun je ook lezen. De admin permissie van 255 kan niet gebruikt worden in het conf/acl.auth.php-bestand. Die is alleen om intern te kunnen controleren op de superuser optie.

Hier is een voorbeeld die hoort bij het eerste voorbeeld dat hierboven is gegeven:

*                     @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

Merk alsjeblief op dat volgorde niet uitmaakt in het bestand. Het bestand wordt in zijn geheel verwerkt, waarbij de perfecte overeenkomst tussen de huidige pagina en de gebruiker wordt gezocht. Wanneer een overkomst is gevonden wordt verdere controle gestopt. Als er geen overeenkomst wordt gevonden, worden de groeppermissies voor de huidige pagina gecontroleerd. Als er nog geen overkomst is gevonden wordt de volgende hogere namespace gecontroleerd.

Opmerking: Om gebruikers en groepen te configureren met speciale tekens (zoals spaties) heb je URL escaping nodig. Dit is alleen van toepassing op speciale karakters in de laagste 128 byte range. Het ACL bestand gebruikt UTF-8 encodering dus elke multibytekarakter kan worden geschreven zoals die is.

Opmerking: Als $conf['authtype'] = 'ad'; en er zijn groepnamen met spaties dan is het nodig om dit te schrijven in acl.auth.php als “%5f” in plaats van “%20”. Dit omdat groepnamen met spaties eerst worden omgezet in lagestrepen “_”, wat gelijk is aan “%5f”.

Opmerking: De verwijderpermissies heeft alleen effect op de mediabestanden. Pagina's kunnen worden verwijderd en hersteld door iedereen met minstens bewerkpermissies. Iemand met uploadpermissies, maar zonder verwijderpermissies kan niet de bestaande mediabestanden overschrijven.

Het is mogelijk om gebruikers wildcards te gebruiken in ACLs. Dit kan nuttig zijn voor Wiki's met veel geregistreerde gebruikers, waar je elke gebruiker een eigen namespace wil geven waar alleen hij/zij schrijfrechten heeft, maar dat niet per gebruiker wilt instellen. Omdat te bereiken wordt %USER% vervangen door de gebruikersnaam van de gebruiker die op dat moment is ingelogd.
In het volgende voorbeeld krijgt een ingelogde gebruiker alle rechten (uploaden en verwijderen) voor de namespace van de gebruiker users:<username>:* en heeft geen toegang tot alle andere namespaces in users:*
In dit geval hebben ingelogde gebruikers alleen toegang tot hun eigen namespace en geen toegang (ook niet lezen) tot de gebruikersnamespaces van alle andere gebruikers

#
# Verleent volledige toegang tot de namespace van de ingelogde gebruiker
users:%USER%:*          %USER%  AUTH_DELETE
#
# Staat toe om naar eigen namespace te bladeren via de INDEX
users:                  %USER%  AUTH_READ
#
# Staat lezen toe op de startpagina in de <users> namespace 
users:start             %USER%  AUTH_READ
#
# Schakelt alle toegang uit tot gebruikers namespaces die niet van de ingelogde gebuiker zijn (inclusief het bekijken van namespaces via INDEX) 
users:*                 @user   AUTH_NONE

Opmerking: versie 2009-12-25c “Lemming” heeft een afwijking. Als je ACL toevoegd, bijwerkt of verwijderd met de GUI beheerinterface zal de DokuWiki-engine %USER% in het tweede veld van ACL vervangen door %25USER%25. Dit is een bug FS#1955. Om dit te vermijden, - moet je permissies alleen handmatig aanpassen (bestand: conf/acl.auth.php) of handmatig corrigeren na elke bewerking van ACL met de GUI omdat het patroon %25USER%25 niet werkt zoals verwacht, alleen %USER% moet gebruikt worden in conf/acl.auth.php. De bug is gerepareerd in de huidige versie.

Opmerking: De wildcard is recent gewijzigd van @ naar % – als je upgrade van een oudere versie moet je jouw ACL-instellingen ook wijzigen.