DokuWiki は、ほとんどの Wiki と同様に、デフォルトでは非常にオープンです。誰でもページを作成、編集、および削除することができます。しかし、時には特定の、もしくはすべてのページへのアクセスを制限したほうがよいこともあるでしょう。アクセス制御リスト (ACL: Access Control Lists) が役に立つのはこのような時です。このページでは、DokuWiki において ACL がどのように動作するのか、また、ACL をどのように設定するのかについて、概要を説明します。

警告: DokuWiki の ACL 機能はかなりの期間 DokuWiki の一部に含められており、非常に安定しているものと考えられます。しかし、もし権限の無いユーザーがあなたの Wiki 上の情報にアクセスするリスクを心配されているのであれば、そのような情報はインターネットからアクセスできる場所に置かないほうが良いでしょう。

ACL はインストーラー上で有効化することができ、そこで ACL の初期設定も行われます。手作業で ACL を有効化するには、設定項目: useacl を有効にした後、設定ファイルのサンプルである conf/acl.auth.php.dist と conf/users.auth.php.dist を、それぞれ conf/acl.auth.php と conf/users.auth.php としてコピーしてください。

この他にも、認証、ユーザー登録および ACL の設定に関するいくつかの設定項目と機能があります。さらなる情報を得るには、以下に示すそれぞれの Wiki ページを確認してください。

• 設定項目: useacl – ACL 機能を有効化する
• 設定項目: superuser – ACL の設定権限を持つスーパーユーザーを設定する
• 設定項目: disableactions – ユーザー登録機能を無効化する
• 設定項目: defaultgroup – 新規ユーザーが追加された場合のデフォルトのグループ
• ユーザー管理用プラグイン – ユーザーを管理する
• 認証バックエンド – ユーザーを異なるデータベースを用いて識別する
• よくある質問: ユーザーを自由に登録できなくする方法

アクセス制限はページと名前空間に結びつけて設定することができます。「権限なし」、「読取」、「編集」、「作成」、「アップロード」、「削除」、そして「管理」という 7 つの権限が用意されています。権限は、一番下位が読取権限、一番上位が削除権限であり、上位の権限は下位の権限を含みます。なお、作成権限、アップロード権限、削除権限を設定できるのは名前空間だけであることに注意してください。

名前空間に設定されたルールは、ページ用の名前空間と同様にメディア用の名前空間にも適用されます。

DokuWiki がユーザーに対してどの権限を与えるかをチェックする際は、ユーザー名もしくはそのユーザーが所属するグループにマッチするすべてのルールが使用されます。ユーザーの権限を規定するルールは、以下の手順に従って選択されます。

• アクセスした namespace:page (名前空間:ページ) に対してより近くでマッチするルールのほうが、より遠くでマッチするルールよりも優先して選択されます。私たちはこれを「明確なマッチング (Specific matching)」と呼んでいます。
• 同一のレベルで 1 つ以上のルールがマッチした場合は、その中で一番上位の権限を与えるルールが優先して選択されます。

ユーザーは、ユーザー管理画面 (もしくは認証バックエンド) で割り当てられたグループに所属しています。しかし、少し特殊な 2 つのグループがあります。

• @ALL – 誰でも (たとえログインしていないユーザーでも) “ALL” グループのメンバーとなります。このグループは、(デフォルト設定として) すべてのユーザーへのアクセスを制限した後に、一部の限定されたユーザーに対して制限を緩和する用途で利用することができます。
• @user – 自分で自分を登録したすべての登録ユーザーは、デフォルトで自動的に “user” というグループのメンバーとなります。このグループは、「ログイン中の」ユーザーに対して権限を与える際に使用してください。このグループの名前は、設定項目: defaultgroup で設定することができます。plain 認証バックエンドを利用している場合、“user” グループは仮想的な “ALL” グループとは異なり、ユーザーが自動的に追加される実在のグループとなります。もし異なる認証バックエンドを使用している場合は、その認証バックエンドによって提供されるグループを使用する必要があります。

グループは、内部的に、そしてアクセスコントロール管理画面上で、グループ名の前にアットマーク @ を置くことによって表現されます。

新規ルールの追加もしくは既存ルールの変更を簡単に行うには、管理用メニューから利用可能なアクセスコントロール管理用プラグインを利用すべきです。このプラグインのインターフェースの詳しい説明については、プラグインのページにまとまっています。

基本的に、新規ルールを追加するには以下の 3 ステップを踏みます。

1. 左上のツリー状のナビゲーションから、制限する名前空間もしくはページを選択します。
2. その ACL ルールを誰に適用するのかを選択します。
   • ドロップダウンメニューから既知のユーザーもしくはグループを選択することによって
   • または、「ユーザー:」もしくは「グループ:」を選択してから入力欄にユーザー名もしくはグループ名を入力することによって
3. 適切な権限を設定します。

既存のルールは、アクセスコントロール管理画面の下のほうにある表の中で編集または削除することができます。

このセクションではアクセスコントロール管理画面で以下のように見える架空の構成例を使用して、アクセスルールがどのように動作するのかを説明します。

それでは、それぞれの行について見ていきましょう。

1. この行では、ルート名前空間において、誰に対してもページの編集と作成を許可する権限を設定します。ただし、アップロードは許可されません。
2. ユーザー bigboss に対してすべての権限が与えられます。
3. 名前空間 devel へのアクセスが制限されます。誰も何もできない状態となります。
4. いや、実際には「誰も」ではないのです。– devel グループのメンバーに対しては、ここでアップロード権限を与えます。
5. そしてもちろんユーザー bigboss も許可します。さらに、彼はアップロードされたファイルを削除できる唯一のユーザーとなります。
6. そして marketing グループのメンバーは名前空間 devel 内のすべてを閲覧することができます。ただし閲覧のみです。
7. しかし devel グループのメンバーは彼らのボスにページ funstuff を見て欲しくありません。– ページ名に完全一致したルールは名前空間にマッチしたルールよりも優先されることを思い出してください。
8. そして最後に marketing グループのメンバーは、ページ devel:marketing の編集が許可されます。
9. それから名前空間 marketing に対する権限が設定されます。 marketing グループのすべてのメンバーはこの名前空間へのアップロードが許可されます。その他のユーザーは 1 行目のルールにマッチするため、なおページの作成と編集が可能です。ユーザー bigboss は 2 行目で設定された権限が継承されるため、ファイルのアップロードおよび削除が可能です。
10. 最後の行では、スタートページを誰に対しても閲覧のみに制限しています。スーパーユーザーだけがいつでもこのページを編集できます。

「明確なマッチング (Specific matching)」への理解を深めるため、2 つ目の例も見てみましょう。

今回は、ページ private:bobspage へのアクセスを試みる場合に、異なるユーザーに対してどのルールがマッチするのかを見ていきます。

1. abby – 通常のユーザー
   • 3 つのルール #1、#2、#4 がマッチします。
   • ルール #4 が最も近い名前空間レベルでマッチするため、3 つのうちで一番高い優先順位となります。
   • ユーザー abby の権限レベルは None となります。
2. bob – 通常のユーザー
   • 4 つのルール #1、#2、#4、#6 がマッチします。
   • ルール #6 が完全一致であるため、このルールが最優先されます。
   • ユーザー bob の権限レベルは Delete となります。
3. ログインするのを忘れた bob が彼のページにアクセスを試みる場合
   • 2 つのルール #1 と #4 がマッチします。
   • ルール #4 がより近くでマッチするため、このルールが優先されます。
   • ログインしていない状態の bob の権限レベルは None となります。
4. charlie – staff グループのメンバー
   • 5 つのルール #1 ～ #5 がマッチします。
   • 2 つのルール #4 と #5 が同じ名前空間レベルでマッチします。ルール #5 のほうが charlie に対してより上位の権限を与えるため、このルールが優先されます。
   • charlie の権限レベルは Delete となります。

なお、ルール #5 はルール #3 と重複しているように見えますが、ルール #5 が無いと staff グループのメンバーはルール #4 により名前空間 private にアクセスできなくなってしまいますので注意してください。

アクセス制限設定は、conf/acl.auth.php というファイルに保存されます。 上記で説明したアクセスコントロール管理画面を利用したい場合は、このファイルが Web サーバから書込み可能である必要があります。 このファイルを直接編集することは推奨されません。 代わりに管理画面を使用するようにしてください。

空行とシェル形式のコメントは無視されます。 それぞれの行には、空白文字区切りの３個の項目があります。

• 制限対象のリソース。これはページ名か名前空間です。名前空間はアスタリスク * の付加によってマーク付けされます（下記の例を参照してください）。
• ユーザー名もしくはグループ名。グループ名は @ の前置で区別します。
• 権限レベル (下記を参照してください)。

整数値によって表される 7 つの権限レベルがあります。 上位のレベルは下位のレベルを含みます。 「編集」が可能なら、「読取」も可能です。 ただし、255 の「管理」権限は conf/acl.auth.php ファイル内では使用できません。 この権限は、設定項目: superuserとの照合することで、内部のみで使用されます。

以下に、上述の最初の例に対応する設定例を示します：

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

このファイル内でのルールの記述順序は全く重要でないことに注意してください。 このファイルはまず全体が丸ごと解析され、その後、現在のページとユーザーの組み合わせによるルールの完全一致が探索されます。 マッチするルールが見つかった場合、その後のマッチングは中止されます。 もしマッチするルールが見つからない場合は、現在のページに対するグループの権限がチェックされます。 それでも見つからない場合は、1 つ上、また 1 つ上と名前空間に対する権限が順番にチェックされます。

注意：特殊な文字 (空白文字など) を使用したユーザー名もしくはグループ名を設定するには、それらを URL エスケープする必要があります。 これは ASCII の最初の 128 文字の範囲 (0x00 ～ 0x7F) に含まれる特殊文字だけに適用されます。 ACL ファイルでは UTF-8 エンコーディングを使用するため、マルチバイト文字であればそのまま記入することができます。

注意：$conf['authtype'] = 'ad' を使用し、スペースを含むグループ名の場合、acl.auth.php はスペースを “%20” ではなく “%5f” に置換える必要があります。 スペースを含むグループ名は最初にアンダースコア “_” つまりは “%5f” に変換されるからです。

注意：削除権限は、メディアファイルにだけ影響します。 ページについては、少なくとも編集権限を持つユーザーであれば誰でも削除 (および復元) できます。 削除権限を持たずアップロード権限を持つユーザーは、既存のメディアファイルを上書きすることはできません。

ACL の中でユーザーワイルドカードを使用できます。 これは多数の登録ユーザーを持つ Wiki において、各ユーザーに対してそのユーザーだけが編集権限を持つ個々の名前空間を割り当てたいが、各ユーザーごとに ACL を編集するのは避けたい場合に役立ちます。 これを実現するため、%USER% はログイン中のユーザーの名前に、%GROUP% はログイン中のユーザーが所属する全グループに置換されます。

以下に示す例では、ログイン中のユーザーは user:<username>:* というユーザーの名前空間に対して全アクセス（アップロード・削除）権限が与えられ、user:* 内の他の名前空間に対して権限なしとなります。
この場合、ログインしたユーザーには自分の名前空間へのアクセス権があるだけで、他のユーザーの名前空間へのアクセス権は（名前空間名の読取権すら）ありません。

#
# Grant full access to logged in user's namespace
user:%USER%:*          %USER%  AUTH_DELETE
#
# Allow to browse own namespace via the index
user:                  %USER%  AUTH_READ
#
# Allow read only access to start page located in "user" namespace 
user:start             %USER%  AUTH_READ
#
# Disable all access to user's home namespaces not owned by logged in user (include view namespaces via the index) 
user:*                 @user   AUTH_NONE
#
# Allow members of 'group' to edit pages in the 'group' namespace.
# becareful, if you have a user namespace, all members of the default group will gain access to it
%GROUP%:*               %GROUP% AUTH_EDIT

注意： 2009-12-25c “Lemming” バージョンには注意が必要です。 管理画面で ACL 登録を追加・変更・削除した場合、ACL の第二項目を %USER% から %25USER%25 に置換えます（これはbug FS#1955です）。 %25USER%25 は期待した動作をせず、conf/acl.auth.php 内では %USER% のみを使用すべきなので、この現象を回避するために、（conf/acl.auth.php を編集して）手動で権限変更するか、管理画面の操作後手動で修正して下さい。 このバグは新しいバージョンで修正されています。

注意： 2008/12 にワイルドカードが @ から % に変更されました。 古いバージョンの DokuWiki からアップグレードする場合、ACL の設定を調整する必要があります。