アクセスコントロール

DokuWikiや多くのWikiはデフォルトで非常にオープンになっています。すべての訪問者がページを作成、編集、削除することができます。しかしながら、一部のページや全ページに対してアクセスを制限したいときもあるでしょう。そんなときは、アクセスコントロールリスト(ACL)を使ってください。このページでは、DokuWikiのACLの動作や設定について、説明します。

さらに多くの情報や質問は、こちらへ –> discussion:acl(英語)

:!: 警告: DokuWikiのACLの機能は、長い間機能として内蔵され、かなり安定しています。しかしながら、もし権限のないユーザーがWikiの情報にアクセスするリスクを心配するなら、コンピュータをインターネットからアクセスできないようにするべきです。

設定

DokuWikiのACLを有効にするには、最低一つのデフォルトが必要です。単純に手本となるファイルをコピーしてもよいでしょう。 conf/acl.auth.php.distconf/users.auth.php.distをそれぞれconf/acl.auth.phpconf/users.auth.phpにコピーすれば、ログインページが動作するはずです。

設定オプションも設定する必要があります。デフォルトのプレーンテキストの認証を有効にするため、local.phpに追加する例を見ていきましょう。

  $conf['useacl']       = 1;        // ACLの機能を有効化します。
  $conf['superuser']    = '@admin'; // 管理グループは、スーパーユーザーです。

ユーザー管理は、ACLの機能を有効にします。この機能を有効にすると、すべてのWikiページの下にログインボタンが現れ、ユーザーは自分自身で登録することができます。スーパーユーザーオプションは、DokuWikiのすべてを実行できるようにします(新しいACLの制限を追加するなど)。単独のユーザーまたはグループ(@を先頭に付加して指定)を指定します。ブラウザを使って、ACLを使うようにDokuWikiをインストールした場合、“ログイン”ボタンをクリックし、“登録”のリンクをたどり、最低1つのユーザーを登録してください。 (もし登録のリンクがない場合は、conf/users.auth.phpの設定が間違っています。新しいデータが書かれていません。) そして、conf/users.authを編集し、最低一つは“ユーザー”から“管理者”にしてください。 そうすると、“管理者”グループに属するユーザーでログインすると、“管理”ボタンが追加され、有効になります。

この時点で、追加してセキュリティ機能が有効になります:

  $conf['openregister'] = 0;        // ユーザーは自分自身で登録できません(デフォルトは1)

この動作を有効とする場合、ユーザーは管理者によって追加されるのみです(ウェブ上の管理画面または、conf/users.auth.phpを直接編集)。

さらにいくつかの設定オプションがあります。デフォルトの設定で満足するものでなければ、他にもACLの詳細を設定できます。

$conf['autopasswd']  = 1;                //パスワードを自動生成し、ユーザーへパスワードをメールで送る
$conf['passcrypt']   = 'smd5';           //暗号化の方法 (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';           //新しく追加されたユーザーのデフォルトのグループ
$conf['profileconfirm'] = '1';           //ユーザープロファイルで、変更の確認に現在のパスワードを必要とする
$conf['authtype']     = 'plain';         //認証方法(デフォルトはプレーン)
  • autopasswd(パスワードの自動生成)を0にすると、登録時にパスワードをユーザー自身が決められるようになります。そうすると正当なメールアドレスで登録しているかどうかの保証がなくなってしまいます。
  • passcrypt(暗号化の方法)は、格納されるパスワードの暗号化の方法を指定します。
  • defaultgroup(デフォルトグループ)は、一目瞭然ですが、すべての新規ユーザーがデフォルトで所属するグループです。
  • profileconfirm(プロファイルの確認)を0にすると、現在のパスワードで確認することなしに、ログインしているユーザーにプロファイル(氏名・パスワード・メールアドレス)の変更が可能になります。
  • DokuWikiは、ユーザーやグループのデータへのアクセスに様々な方法を使うことが可能です。デフォルトでは、plaintextのバックエンドを使います。バックエンドは、authtypeオプションの設定で選択されます。どのオプションが使えるかは、backendsのページをご覧ください。

ユーザー管理

ユーザー管理で、ユーザーの追加、削除、編集が可能です。公開登録が有効であれば、同様にユーザー自身でユーザーの登録ができます。手動でユーザーを登録するときの情報は、単純なバックエンドのドキュメントにある詳細をご覧ください。

アクセス制限

アクセス制限は、ページ名名前空間で制限します。読取書込編集作成アップロード削除の5つの権限があります。読取の権限が低く、削除の権限が高くなっていて、高い権限は低い権限を包括します。作成、アップロード、削除の権限は、名前空間に割り当てられることに注意してください。

DokuWikiがユーザーに与えられた権限をチェックするとき、ユーザー名や所属グループに該当するすべてのルールが適用されます。高い権限が与えられているルールが使われます。権限は最初にページでチェックされます。次に上位の名前空間がチェックされます。該当するルールが見つかるまで、上位の名前空間が続きます。

制限のルールを追加するには、制限したいページを開き、管理と書かれたボタンをクリックし、管理画面に入ってください(スーパーユーザーのみが可能です)。そこで、アクセスコントロールリスト管理を選択し、表示しているページへの該当する制限が表示されます。

ACL制限の例

制限は、表の一番上の行に追加されます。現在のページ自体か、上位の名前空間など、範囲を選択する必要があります(最上位の名前空間は*と表現します)。また、アクセスを与える(または拒否する)かを選択する必要があります。これはグループでもユーザーでも可能です。そして最後に、実際の制限を指定します。選択しないことで、効果的に特定のユーザーやグループをページや名前空間から締め出すことができます。

注意:削除権限はメディアファイルにのみ影響します。ページは全員から削除(復活)が可能です。アップロードの権限を有して、削除権限がない場合、存在するメディアファイルに上書きはできません。

特別なグループ

ALL。ログインしていないユーザーを含めて全員がALLグループのメンバーになります。すべてのユーザーをアクセス制限し(デフォルトの設定)、特定のユーザーには規制を緩めるといった使い方ができます。例えば、上のスクリーンショットでは、アップロードは誰にも許可されていませんが、uploadグループのメンバーにだけは許可されています。

user。自分で登録したユーザーすべては、デフォルトで'user'グループのメンバーに自動的になります。ログインユーザーに権限を与えるときに使います。このグループの名称は、 defaultgroupオプションで設定可能です。事実上の“ALL”グループ以外、“プレーン認証バックエンドを使うとき、user”グループは自動で追加されるユーザすべてが属するグループになります。もし、別のバックエンドを使うなら、そのバックエンドが提供するグループを使ってください。

バックグラウンド情報

アクセス制限は、conf/acl.auth.phpというファイルに保存されます。ACL管理画面で使うのならウェブサーバーから書き込み可能にしてください。

空行とシェルの書式のコメントは、無視されます。それぞれの行は、半角スペースで3つのフィールドに分けられます:

  • 制限するリソース。ページ名または名前空間になります。名前空間は、アスタリスクが付きます(上の例を参照)。
  • グループまたはユーザー名。グループ名は@で始まります。
  • 許可のレベル(上の例を参照)。

7つの許可レベルが数値によって示されます。高いレベルは下位のレベルを含みます。もし編集できるなら、読むこともできるでしょう。

名前 レベル 適用 許可 DokuWikiの不定変数
none 0 pages, namespaces 許可なし – 完全締め出し AUTH_NONE
read 1 pages, namespaces 読み取りを許可 AUTH_READ
edit 2 pages, namespaces 存在するページの編集 AUTH_EDIT
create 4 namespaces 新規ページの作成 AUTH_CREATE
upload 8 namespaces メディアファイルのアップロード AUTH_UPLOAD
delete 16 namespaces メディアファイルの上書きや削除 AUTH_DELETE
admin 255 admin plugins スーパーユーザー1)は管理設定を変更可 AUTH_ADMIN

例として:

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

行ごとに見ていきましょう(下記に詳細)

  1. メインの名前空間に許可を与えています。全員にページの編集と作成を許可しています。しかしアップロードは許可されていません。
  2. bigbossユーザーは、すべての権利を与えられています。
  3. startページに対する許可は、全員に「読み取りのみ」に制限されています。
  4. そして名前空間marketingに対する許可が与えられています。すべての marketingグループのメンバーは、そこにアップロードの権限が許可されています。他のユーザーは1行目で条件に一致するので、作成と編集だけです。bigbossは、2行目の権利を受け継ぐので、ファイルのアップロードや削除が可能です。
  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.

Note: the ACL code doesn't quite work the way that description might suggest – if you wanted to have a “superusers” group that had full access to everything, you couldn't just put

*                     @superusers       16

at the end of the ACL file and have that override everything that went before. A page's access is defined by the most closely matching line in the ACL – so, even though theoretically superusers have access to everything, that wouldn't actually happen because the devel:* and marketing:* lines are a closer match, so they're the ones that are used. To get the effect desired here, you'd have to add

marketing:*           @superusers       16
devel:*               @superusers       16

and so on for every other namespace (and subnamespace, and page, etc) that had been restricted.


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.

In versions> 2006 if the username user_id, then acl.auth.php is recognizing it as user%5fid. Is it only with me or I am missing something? It was working for me in previous versions. —Ankit Rajvansh

I have the same problem with dokuwiki-2006-03-09 ; moreover, user-id must be written user%2did in acl.auth.php — Pierre Maurice