====== アクセスコントロール ====== [[DokuWiki]]や多くのWikiはデフォルトで非常にオープンになっています。すべての訪問者がページを作成、編集、削除することができます。しかしながら、一部のページや全ページに対してアクセスを制限したいときもあるでしょう。そんなときは、//アクセスコントロールリスト//(ACL)を使ってください。このページでは、DokuWikiのACLの動作や設定について、説明します。 さらに多くの情報や質問は、こちらへ --> [[doku>wiki:discussion:acl|discussion:acl]](英語) :!: **警告:** DokuWikiのACLの機能は、長い間機能として内蔵され、かなり安定しています。しかしながら、もし権限のないユーザーがWikiの情報にアクセスするリスクを心配するなら、コンピュータをインターネットからアクセスできないようにするべきです。 ===== 設定 ===== DokuWikiのACLを有効にするには、最低一つのデフォルトが必要です。単純に手本となるファイルをコピーしてもよいでしょう。 ''conf/acl.auth.php.dist''と''conf/users.auth.php.dist''をそれぞれ''conf/acl.auth.php''と''conf/users.auth.php''にコピーすれば、ログインページが動作するはずです。 [[config|設定オプション]]も設定する必要があります。デフォルトのプレーンテキストの認証を有効にするため、''local.php''に追加する例を見ていきましょう。 $conf['useacl'] = 1; // ACLの機能を有効化します。 $conf['superuser'] = '@admin'; // 管理グループは、スーパーユーザーです。 [[config#useacl|ユーザー管理]]は、ACLの機能を有効にします。この機能を有効にすると、すべてのWikiページの下にログインボタンが現れ、ユーザーは自分自身で登録することができます。[[config#superuser|スーパーユーザー]]オプションは、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'; //認証方法(デフォルトはプレーン) * Change [[config#autopasswd]] to 0 to allow users to select their own password when registering. This has the side-effect of removing the guarantee that the user has registered with a valid email address. * [[config#passcrypt]] determines the method of encryption used for storing passwords. * [[config#defaultgroup]] is fairly self-explanatory: all new users will be added to this group by default. * Set [[config#profileconfirm]] to 0 to allow a logged in user to change their profile (full name, password and email address) without having to confirm their current password. * DokuWiki can use different ways to access user and group data. By default it uses its own [[.auth:plain|plaintext]] backend. The backend is chosen by setting the [[config#authtype]] option. Have a look at the [[.auth:backends]] page to see which options are available. ===== User management ===== Users can be added, removed and edited through the [[plugin:usermanager]]. When [[config#openregister]] is enabled users can register themselves as well. For info on manually adding users see the descriptions in the [[.auth:plain|plain backend]] documentation. ===== Access Restrictions ===== Access restrictions can be bound to [[pagename]] 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 is in. The rule which gives the highest permission is used. Permissions are checked for the page first, then all upper namespaces are checked until a matching rule is found. 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 [[config#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. {{wiki:acladmin.png|Example of an ACL-Restriction}} 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 ((the top-most namespace is called ''*'')). 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 effectivly 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. Someone who has upload permissions but no delete permissions can not overwrite existing media files anymore. === Special Groups === **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 [[config#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. ===== Background Info ===== 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. 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. ^ Name ^ Level ^ applies to ^ Permission ^ DokuWiki constant ^ | none | 0 | pages, namespaces | no permission -- complete lock out | AUTH_NONE | | read | 1 | pages, namespaces | read permission | AUTH_READ | | edit | 2 | pages, namespaces | existing pages may be edited | AUTH_EDIT | | create | 4 | namespaces | new pages can be created | AUTH_CREATE | | upload | 8 | namespaces | mediafiles may be uploaded | AUTH_UPLOAD | | delete | 16 | namespaces | mediafiles may be overwritten or deleted | AUTH_DELETE | | admin | 255 | admin plugins | superuser((see [[config#superuser]])) can change admin settings | AUTH_ADMIN | 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): - This sets permission for the main namespace. Allowing everybody to edit and create pages. However upload is not allowed. - User //bigboss// is given full rights - The permissions for the start page are restricted to readonly for everyone - 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. - Now the access for the ''devel'' namespace is restricted. Nobody is allowed to do anything. - Well not nobody really -- we give members of the //devel// group full rights here - And of course //bigboss// is allowed, too -- and he's the only who can delete uploaded files - However the devel guys don't want their boss to see the ''funstuff'' page -- remember exact pagematches override namespace permissions - And the //marketing// team may read everything in the ''devel'' namespace, too - 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 [[.auth: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 --- [[mailto:maurice@irit.fr|Pierre Maurice]]