SomeGroup is a page name matching page_group_regex (see #Configuration) with some lines in the form " * Member" (see #Groups).

Trusted is a special group containig all authenticated users (like when using password login).

Known is a special group containing all valid users (like when using the cookie).

All is a special group containing all users (known and anonymous users).

Default is a special entry which inserts at the given place the entries from acl_rights_default (see #Default).

right may be an arbitrary word like read, write, delete, revert, admin. Only words in acl_rights_valid are accepted, others are ignored. It is allowed to specify no rights, which means that no rights are given.

4. Available rights

These are the available rights you can use in an ACL entry:

read

Given users will be able to read text of this page.

write

Given users will be able to write (edit) text of this page.

delete

Given users will be able to delete this page and its attachments.

revert

Given users will be able to revert this page to an older version.

admin

Given users will have admin rights for this page. It means users will be able to change ACL settings, including granting "admin" to others and revoking "admin" from others.

5. Processing logic

When some user is trying to access some ACL-protected resource, the ACLs will be processed in the order they're found. The first matching ACL will tell if the user has access to that resource or not.

Due to that first match algorithm, you should sort your ACLs: first single usernames, then special groups, then more general groups, then Known and at last All.

For example, the following ACL tells that SomeUser is able to read and write the resources protected by that ACL, while any member of SomeGroup (besides SomeUser, if part of that group) may also admin that, and every other user is able to read it.

#acl SomeUser:read,write SomeGroup:read,write,admin All:read

To make the system more flexible, there are also two modifiers: the prefixes '+' and '-'. When they are used, the given ACL entry will only match if the user is requesting the given rights. As an example, the above ACL could also be written as:

#acl -SomeUser:admin SomeGroup:read,write,admin All:read

Or even:

#acl +All:read -SomeUser:admin SomeGroup:read,write,admin

Notice that you probably won't want to use the second and third examples in ACL entries of some page. They're very useful on the site configuration entries though.

6. Inheriting from defaults

Sometimes it might be useful to give rights to someone without affecting too much the default rights. For example, let's suppose you have the following entries in your configuration:

Now, you have some page where you want to give the "write" permission for SomeUser, but also want to keep the default behavior about All and TrustedGroup. You can easily do that using the Default entry:

#acl SomeUser:read,write Default

This will insert the entries from acl_rights_default in the exact place where the Default word is placed. In other words, the entry above, with the given configuration, is equivalent to the following entry:

A page named AdminGroup (matching config.page_group_regex) could define a group of that name and could be also protected by ACLs:

#acl AdminGroup:admin,read,write All:read
* SomeUser
* OtherUser
* This is currently ignored.
Any other text not in first level list will be ignored.

You can configure which page names are considered as group definition pages (e.g. for non-english wikis):

page_group_regex = '.*Group$' # this is the default

9. Usage cases

9.1. Public community Wiki on the Internet

The most important point here is to use ACLs only in cases where really needed. Wikis depend on openness of information and free editing. They use soft security to clean up bad stuff. So there is no general need for ACLs. If you use them too much, you might destroy the way wiki works.

This is why either ACLs should not be used at all (default) or, if used, the moin_config.py should look similar to that:

A good advice is to have only a few and very trusted admins in AdminGroup (they should be very aware of how a wiki works or they would maybe accidently destroy the way the wiki works: by its openness, not by being closed and locked!).

If using AdminGroup, you should make a page called AdminGroup and use it to define some people who get admin rights.

Specifing BadGuy like shown above basically locks him out - he can't read or edit anything with that account. That makes only sense if done temporarily, otherwise you also could just delete that account. Of course, this BadGuy can also work anonymously, so this is no real protection (this is where soft security will apply).

9.2. Wiki as a simple CMS

If you want to use a wiki to easily create web content, but if you don't want edits by the public (but only by some webmasters), you maybe want to use that in your moin_config.py:

So everyone can read, but only the Webmasters can do anything else. As long as they still work on a new page, they can put

#acl All:

on it, so nobody else will be able to see the unready page. When being finished with it, don't forget to remove that line again, so that acl_rights_default will be used.

Some page(s) could also allow public comments (like one being called PublicComments), so you give more rights on that page:

#acl All:read,write

9.3. Wiki on Intranet

If you want to use a wiki on your intranet and you trust your users (not doing hostile stuff like locking others out or hijacking pages) to use the admin functionality in a senseful way, you maybe want to use that:

So everyone can read, write and change ACL rights, WikiAdmin and BigBoss are enforced to be able to do anything, known users get admin rights by acl_rights_default (so they get it as long as no other ACL is in force for a page).

Consequences:

on a new page, the page creator can put any ACLs he wants

on existing pages, not having ACLs yet, any known user can set up any ACLs he wants

all people (except WikiAdmin and BigBoss) can be locked out by anybody ("known") else on pages without ACLs

9.4. Wiki as a public company page

If you want to use a wiki as the company page, and don't want every user being able to change the company page content, you may want to use something like this: