User Tools

Site Tools


wiki:acl

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
wiki:acl [2007/08/24 09:33] jaswiki:acl [2007/08/24 09:51] (current) jas
Line 73: Line 73:
 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. 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.
  
-ACLs can be added in two ways.  DokuWiki comes with the ''Access Control List Management'' plugin which allows you to add restrictions to namespaces, and pages, but you must be on a page in the namespace that you wish to restrict in order to add restrictions to it.  Alternatively, our local DokuWiki installation has another plugin installed called "SuperACL" which lets you handle ACL restrictions for any page or namespace from one plugin, no matter where you are in the Wiki.  **SuperACL is the recommended plugin to use for Access Control List management. **  The rest of these instructions will focus on using the SuperACL plugin.+ACLs can be added in two ways.  DokuWiki comes with the ''Access Control List Management'' plugin which allows you to add restrictions to namespaces, and pages, but you must be on a page in the namespace that you wish to restrict in order to add restrictions to it.  Alternatively, our local DokuWiki installation has another plugin installed called "SuperACL" which lets you handle ACL restrictions for any page or namespace from one plugin, no matter where you are in the Wiki.  **SuperACL is the recommended plugin to use for Access Control List management. **  The rest of these instructions will focus on using the Super ACL plugin.
  
-To add a restriction rule, enter the administration interface by pressing the ''Admin'' button. There select //SuperACL View//. You're then presented with a table like the following, showing you all restrictions relevant to the current page.+To add a restriction rule, enter the administration interface by pressing the ''Admin'' button. Next, select //Super ACL View//. You are then presented with a table like the following, showing you all restrictions relevant to the current page.
  
 {{wiki:acladmin.jpg|Example of an ACL-Restriction}} {{wiki:acladmin.jpg|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..+Under ''Select namespace to administrate'', select the namespace that you will be configuring.  The top-most namespace is called ''*''  
  
-Note: The delete permission affects media files onlyPages 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.+After you have selected a namespace, under ''Permissions for Namespace'', you will see all the permissions that have been defined for the select namespace Here, you can change the permissions or delete them.  If you change the permissions without clicking the ''Update'' button, the permissions will not be saved.  If you wish to delete permissions, click the ''Delete'' button on the line of the permissions that you wish to delete.
  
 +If you wish to add an ACL entry to the selected namespace, go to the ''Add new Entry'' field.  Select ''User'' or ''Group'', enter the user/group in the field provided (eg. ''ALL'') , select the permissions, and click the ''Save'' button.  Selecting no permission effectively locks out the specified user or group from the page or namespace.
  
-^ Name   ^ Level ^ applies to        ^ Permission                               ^ DokuWiki constant ^ +Please note the following:
-| 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:+  * 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.
  
-<file> +  * **order does not matter** in the ACL. The ACL 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.
-                    @ALL        4 +
-                    bigboss    16 +
-start                 @ALL        1 +
-marketing:          @marketing +
-devel:              @ALL        0 +
-devel:              @devel      8 +
-devel:              bigboss    16 +
-devel:funstuff        bigboss     0 +
-devel:              @marketing +
-devel:marketing       @marketing +
-</file>+
  
-Lets go through it line by line (though see below for more): +  * The admin of the site has access to everything on the site, no matter what the ACL says.
- +
-  - 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. +
- +
-Please note that **order does not matter** in the ACL. The ACL 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 [[.auth:plain]] one is used -- the plain backend does not allow any special chars anyway. +
- +
-The DokuWiki manual describes the ACL system.  Basically +
-DokuWiki has been configured to  +
-In order to allow/disallow users on your site, you +
-DokuWiki has  +
-  * authentication of CSE users +
-  * built-in "cse" group for cse users, and "wiki" group for plaintext users +
-  * "users" group is the default group added when no group is specified on adding an account +
-  * groups can contain CSE users, system groups, or distribution lists +
-    * include:system:group +
-    * include:dist:session:term:course +
-    * include:wiki:name  +
- +
- +
- +
-By default, any user in the world has the ability to view all the content in your Wiki.  Administrators have access to edit content.  If you are satisfied with this setup, you don't need to change a thing. +
- +
-If you need to restrict content on your site, you will be able to restrict content to groups that you create.  These groups can include system groups (eg. tech, faculty, ugrad), class lists, or even other wiki groups. +
- +
-ALL cse users are automatically registered with your Wiki and have the ability to login.   What they will see when they login differs based on how you setup the Access Control List +
  
 +  * By default, nobody has access to the ''group'' namespace (except admins).  **For security reasons, please be careful to ensure that you do not remove this restriction.**
 +  
wiki/acl.1187962410.txt.gz · Last modified: 2007/08/24 09:33 (external edit)