DokuWiki – 正如其他wiki — 默认是很开放的。 每个人都能创建、编辑、删除页面。 但是有时候对一些页面甚至所有页面作个限制也是合理的。 这时候我们就要用到 访问控制列表 (ACL) 了。 本页面将介绍怎么使用ACL和怎么配置它。
警告: Dokuwiki 的 ACL 特性已经存在了相当一段时间,应该是非常稳定的。然而,如果你担心未授权用户能访问维基内容这一风险,就绝不要把它放到可通过网络访问的计算机上。
ACL 可以在安装向导里被激活,同时会初始化一个 ACL 策略。如果要手动激活 ACL,打开 useacl 选项并把 conf/acl.auth.php.dist
、conf/users.auth.php.dist
这两个文件重命名为 conf/acl.auth.php
、conf/users.auth.php
。
还有一些额外的选项和特性与授权、用户注册以及 ACL 设置有关。请参考它们相应的维基页面来获取更多信息:
访问控制可以针对页面或者命名空间。共有7种权限:无、读取、编辑、创建、上传、删除以及管理。高权限会包含低权限,其中读取是最低的权限,删除是最高的权限。需要注意的是,创建、上传和删除权限只能应用于命名空间。
为命名空间设置的规则也会应用到其下的媒体文件和页面1)。
当 Dokuwiki 检查它应该给用户何种权限时,它会使用所有匹配该用户及其所在组的规则。最终应用的权限规则由以下方式选出:
在用户管理(或者验证后端)中,用户总是属于某个组。然而,有两个组 groups 有点特别:
在内部以及 ACL 管理器中,组由“@”前缀和组名来表示。
想方便地添加新规则或更改已存在的规则,你需要使用“管理”菜单中的 ACL 管理器。关于它的更多描述可以在这里找到。
基本上,增加一条新的 ACL 规则有三个步骤:
已有规则可以在 ACL 管理器下面的表格中修改或者删除。
在这个部分,我们举例说明访问规则是怎么工作的:
我们一行一行地看:
devel:marketing
页。marketing
也设置了. marketing 组的成员都被允许upload - 其他用户因为规则1的授权,能够创建、编辑,但是不能upload. bigboss 则因为规则2 的授权,他能upload 并 delete 文件.下面这个例子可以让你更好地理解 specific matching: (俺就不翻译了)
This time we look what rules will match for different users when trying to access the page private:bobspage
.
Note rule #5, which appears to duplicate rule #3. Without it, staff members wouldn't be able to access the private namespace as rule #4 would keep them out.
这段是背景知识,告诉你ACL文件存在哪里,但是不建议你直接修改,所以俺不翻译了。
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 described above. It is not recommended to edit this file manually. Use the admin interface instead.
Empty lines and shell-style comments are ignored. Each line contains 3 whitespace separated fields:
@
character.
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 can not be used in the conf/acl.auth.php
file. It is only used internally by matching against the superuser option.
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 | superuser4) can change admin settings | AUTH_ADMIN |
Here is an example setup matching the first example given above:
* @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
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.
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.
Note: When using $conf['authtype'] = 'ad'; and groups names with spaces needing to be written in the acl.auth.php with a “%5f” replacing the spaces instead of “%20”. This is because Group names with spaces are first converted into underscores “_” which are “%5f”.
Note: The delete permission affects media files only. Pages can be deleted (and restored) by everyone with at least edit permission. Someone who has upload permissions but no delete permissions can not overwrite existing media files anymore.
这段是说如果你的wiki有非常多的注册用户的话,你可以用通配符。 这段也不翻译了。
It is possible to use user wildcards in the ACLs. This can be useful for Wikis with many registered users, if you want to give each user a personal namespace where only he/she has write access, and you don't want to edit the ACLs for each user. To accomplish that %USER% is replaced by the username of the currently logged in user.
In the following example a logged in user gains full access (upload/delete) permissions for the user's namespace users:<username>:*
and revoke all access from other namespaces located in users:*
In this case logged in user has access to own namespace only and have not access to users namespaces (even view names of namespaces) of other users.
# # Grant full access to logged in user's namespace users:%USER%:* %USER% AUTH_DELETE # # Allow to browse own namespace via INDEX users: %USER% AUTH_READ # # Allow read only access to start page located in <users> namespace users:start %USER% AUTH_READ # # Disable all access to user's home namespaces not owned by logged in user (include view namespaces via INDEX) users:* @user AUTH_NONE
Note: current version 2009-12-25c “Lemming” has some caveat. If you add, update or remove ACL from GUI admin interface then DokuWiKi engine will replace %USER% in the second field of ACL to %25USER%25 that is a bug FS#1955. To avoid it, - change permissions manually only (file:
conf/acl.auth.php
) or correct them manually after each operations with ACL from GUI because mask %25USER%25 does not work as expected, only %USER% should be used in the conf/acl.auth.php
.
Note: The wildcard was recently changed from @ to % – if you are upgrading from an older version you need to adjust your ACL setup accordingly.