DokuWiki – jak większość Wikis – jest domyślnie otwarty. Każdy może tworzyć, edytować i usuwać strony. Jednak czasami przydałoby się zabezpieczyć dostęp do niektórych lub wszystkich stron. W takim przypadku Access Control Lists (ACL) wchodzi do gry. Ta strona powinna dać ci ogólny pogląd na to, jak funkcjonuje ACL w DokuWiki i jak to sie konfiguruje.

Więcej informacji znajdziesz na –> discussion:acl

UWAGA: DokuWiki's ACL jest standardowo dołączany i powinien być stabilny. Jeśli jednak jesteś zaniepokojony ryzykiem dostępu to twoich informacji w wiki przez nieautoryzowanych użytkowników, nie powinieneś w ogóle umieszczać tych danych w Internecie …

Aby włączyć ACL w DokuWiki, potrzebujesz co najmniej jednego domyślnego ACL. Po prostu skopiuj przykładowe pliki conf/acl.auth.php.dist i conf/users.auth.php.dist odpowiednio do conf/acl.auth.php i conf/users.auth.php a logowanie powinno działać. Jeśli dostaniesz komunikat „No ACL setup yet! Denying access to everyone.” (ACL nie ustawiony, brak dostępu dla wszystkich) upewnij się, że tekst na początku pliku acl.auth.php czyta acl.auth.php a nie users.auth.php.

Musisz ustawić pewne opcje konfiguracyjne. Popatrz na przykład, który możesz dodać do local.php aby włączyć domyślny tekstowy sposób autoryzacji z publiczna rejestracją:

Pamiętaj że wszystkie te opcje konfiguracji mogą być ustawione w menu administracji uprawnieniami.

  $conf['useacl']       = 1;        // to włącza ACL 
  $conf['superuser']    = '@admin'; // admin group is superuser - admin jest grupą superuser

Opcja useacl włącza dodatek ACL. Dodatek staje się teraz aktywny, przycisk logowania pojawia się na dole każdej ze stron Wiki i użytkownicy mogą się rejestrować. Opcja superuser określa, kto może zrobić wszystko w DokuWiki (włączając w to dodawanie uprawnień ACL) - może to być pojedynczy użytkownik lub grupa (oznaczona na początku znakiem @). Kiedy instalujesz Dokuwiki od początku, wciśnij przycisk w przeglądarce „Zaloguj”, podążaj za linkiem „zarejestruj” i zarejestruj przynajmniej jednego użytkownika. (Jeśli nie widzisz linku rejestracyjnego, masz ustawione niepoprawne uprawnienia do plików conf/users.auth.php conf/acl.auth.php i nie mogą być do nich zapisywane nowe dane) Następnie edytuj conf/users.auth.php i zmień uprawnienia przynajmniej jednego użytkownia z „user” na „admin”. Odtąd powinien pojawiać się dodatkowy przycisk „Administracja” wtedy, gdy jesteś zalogowany jako użytkownik należący do grupy „admin”.

W tym momencie można włączyć dodatkową cechę bezpieczeństwa. Aby nie pozwolić użytkownikom rejestrować się samodzielnie dodaj 'register' do opcji disableactions:

  $conf['disableactions'] = 'register';        // użytkownicy nie mogą już rejestrować sami siebie

Jeśli jest to zachowanie pożądane, użytkownicy mogą być dodawani tylko przez administratora (albo przez administracyjny interfejs sieciowy albo bezpośrednią edycję conf/users.auth.php).

Jest również kilka dodatkowych opcji konfiguracyjnych pozwalających kontrolować inne aspekty ACL, których wartości domyślne zaspokajają życzenia większości administratorów.

$conf['autopasswd']  = 1;                //Automatyczne generowanie hasła i wysłanie go mailem użytkownikowi
$conf['passcrypt']   = 'smd5';           //Użyta metoda szyfrowania (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';           //Domyślna grupa, do której dodawani są nowi użytkownicy
$conf['profileconfirm'] = '1';           //Wymaganie bieżącego hasła by potwierdzić zmiany profilu użytkownika
$conf['authtype']     = 'plain';         // backend tekstowy (domyślny)

• Zmiana autopasswd na 0 zezwala użytkownikom wskazać hasło w czasie rejestracji. Ma to efekt uboczny usunięcia gwarancji, że użytkownik zarejestrował się podając poprawny własny adres email.
• passcrypt określa metodę szyfrowania używaną do przechowywania haseł.
• defaultgroup wszyscy nowi użytkownicy zostaną domyślnie dodani do tej grupy.
• Ustaw profileconfirm na 0 by zezwolić użytkownikom na zmianę swojego profilu (pełna nazwa, hasło i adres email) bez konieczności potwierdzenia przez wpisanie aktualnego hasła.
• DokuWiki może użyć różnych sposobów dostępu do danych użytkowników i grup. Domyślnie używa własnego backendu plaintext. Backend jest wybierany przez ustawienie opcji authtype. Przejrzyj stronę backends by sprawdzić, jakie opcje są dostępne.

…

Użytkowników można dodawać, usuwać i modyfikować przy pomocy menadżera użytkowników. Aby dowiedzieć się, jak ręcznie dodać użytkowników, przejrzyj w dokumentacji opis backendu plain. Domyślnie użytkownicy mogą się również rejestrować sami.

Zobacz również: FAQ: Jak wyłączyć możliwość samodzielnej rejestracji użytkowników

Ograniczenia dostępu mogą być przypisane do stron i przestrzeni nazw. Mamy mięć uprawnień: czytanie, zmiana, tworzenie, przesyłanie plików i usuwanie. Każde wyższe uprawnienie zawiera w sobie wszystkie niższe, z których czytanie jest najniższym, zaś usuwanie najwyższym. Zauważ, że uprawnienia tworzenie, przesyłanie plików i usuwanie mogą być przypisane tylko do przestrzeni nazw.

Gdy DokuWiki sprawdza jakie uprawnienia przyznać użytkownikowi, wykorzystuje wszystkie reguły pasujące do nazwy użytkownika lub grup, do których należy. Wykorzystywana jest reguła dająca największe uprawnienia. Sprawdzane są najpierw uprawnienia do strony, następnie wszystkich nadrzędnych przestrzeni nazw aż do odnalezienia pasującej reguły.

Aby dodać regułę ograniczającą, przejdź do strony do przyblokowania i przejdź do interfejsu administracji wciskając przycisk Administracja (dostępny tylko dla superuser). Tam wybierz Zarządzanie uprawnieniami. Zostanie wtedy wyświetlona poniższa tabela, pokazując wszystkie ograniczenia istotne dla bieżącej strony.

Ogranicznia dodawane są w pierwszym wierszu tabeli. Musisz wskazać zakres, którym może być sama strona lub jedna z przestrzeni nazw, w których ona leży ¹⁾. Musisz również wskazać komu chcesz przyznać (lub odebrać) dostęp; może to być użytkownik albo grupa. I na koniec musisz wskazać właściwy poziom uprawnień. Wybierając żadne blokujesz całkowicie dostęp użytkownikowi lub grupie do strony lub przestrzeni nazw..

Uwaga: Uprawnienie usuwania dotyczy tylko plików multimedialnych. Strony mogą być usuwane (i odtworzone) przez wszystkich posiadających uprawnienia co najmniej zmiany. Osoba posiadająca uprawnienie przesyłania plików bez usuwania nie może nadpisywać istniejących plików multimedialnych.

ALL. Wszyscy, nawet użytkownicy niezalogowani, są członkami grupy ALL. Możesz użyć tej grupy by zablokować dostęp wszystkim użytkownikom (jako ustawienie domyślne) a następnie poluźniać uprawnienia dla określonych użytkowników. Na przykład, na powyższym zrzucie ekranu, nikt nie ma prawa przesyłania plików poza członkami grupy upload.

user. Wszyscy zarejestrowani użytkownicy są domyślnie przypisywani do grupy 'user'. Użyj tej nazwy do nadania uprawnień 'zalogowanym' użytkownikom. Nazwa tej grupy jest konfigurowana przez opcję defaultgroup. Inaczej zatem niż wirtualna grupa „ALL”, grupa „user” jest rzeczywistą grupą do której użytkownicy są przypisywani automatycznie podczas użycia standardowego backendu autoryzacji. Jeśli używasz innego backendu musisz skorzystać z grup dostarczanych przez ten 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.