welcome: please sign in

The following 597 words could not be found in the dictionary of 7 words (including 7 LocalSpellingWords) and are highlighted below:
able   about   above   acceptable   accepted   access   Access   accessed   accidentally   accidently   account   acl   actions   add   Add   Admin   admin   admins   advantage   advice   affecting   after   algorithm   all   All   allow   allowed   allowing   allows   already   Also   also   among   an   Anchor   and   And   anonymous   anonymously   another   Any   any   anybody   anything   appended   applied   apply   arbitrary   are   arwdr   as   As   assuming   asterisk   at   attached   attachments   Attachments   authenticated   authentication   Auto   automatically   Available   available   aware   back   Bad   bad   based   Basic   basically   Basics   Be   be   because   before   begins   behavior   being   besides   between   Big   bigger   Boss   but   by   cache   called   Camel   can   case   Case   cases   change   changed   changes   checked   checking   clean   closed   Comments   comments   community   company   concatenation   config   configuration   Configuration   configure   configured   Consequences   Consider   considered   contain   containing   contains   content   Contents   continue   continues   contrasts   control   Control   cookie   could   course   create   creating   creator   current   currently   data   Default   default   defaults   define   defined   definition   definitions   Delete   delete   deleting   denied   depend   described   Description   destroy   details   difference   direct   directory   disallow   Do   do   Doe   does   doesn   don   done   Due   during   each   easier   easily   easy   edit   editing   Editor   editors   edits   effect   either   else   enabled   Enables   end   enforced   engine   english   entries   entry   Entry   equivalent   etc   even   every   everyone   exact   exactly   example   examples   except   existing   extend   False   feature   few   files   finally   Finally   finished   first   flexible   followed   following   follows   For   for   force   forcing   forget   forgetting   form   found   free   Friends   friends   from   functionality   further   general   get   give   given   Given   giving   global   good   granted   granting   group   Group   groups   Groups   Guy   happen   has   have   having   he   Help   helps   here   hide   hierarchic   Hierarchical   hierarchical   hierarchy   higher   hijacking   him   hostile   how   if   If   ignored   important   in   In   Include   included   including   influence   information   inheriting   Inheriting   insert   inserts   instance   instead   Internet   intranet   Intranet   introduced   is   it   It   item   items   its   Joe   just   keep   know   known   Known   languages   last   left   let   Lets   lets   level   like   line   lines   list   Lists   locked   locking   locks   logic   long   look   looking   Ls   make   makes   Master   match   matched   matches   matching   may   maybe   mean   means   Member   member   merged   might   Miller   modifier   modifiers   modify   more   most   much   must   name   Name   named   names   necessary   need   needed   new   New   no   nobody   non   none   normal   Normally   not   notation   note   Note   nothing   Notice   Now   now   nutshell   occurs   Of   of   ok   old   older   On   on   once   one   Only   only   onto   openness   option   Or   or   order   Other   other   others   otherwise   out   over   overall   pack   page   Page   pages   parent   part   path   pattern   people   per   permission   permissions   place   placed   Please   point   pre   prefixes   probably   processed   processing   Processing   protected   protection   public   Public   publish   put   py   queried   rather   re   read   real   really   rebuild   recognize   regex   remove   removing   Rename   rename   renaming   replace   represent   representing   requested   requesting   requires   resolved   resource   resources   revert   revision   revoking   right   rights   root   rules   same   second   section   security   See   see   sense   sensible   separate   Sequence   served   server   set   settings   setup   should   shown   similar   simple   simply   single   site   sitewide   Smith   So   so   soft   Some   some   somebody   someone   something   Sometimes   sort   space   spaces   special   specific   specified   Specifing   specify   still   stop   stopping   stops   string   strings   sttill   stuff   subpage   subset   such   suppose   Syntax   syntax   system   Table   take   tell   tells   temporarily   text   than   that   That   The   the   their   them   then   There   there   these   These   they   They   thing   think   third   this   This   those   though   through   to   To   too   top   triggers   True   trust   Trusted   trusted   trying   two   understood   unfinished   unicode   unless   until   up   Usage   use   Use   used   useful   user   User   username   usernames   users   Using   using   valid   ve   version   very   want   wants   way   Web   web   webmasters   Webmasters   what   When   when   Where   where   which   While   while   whitespace   who   why   Wiki   wiki   wikiconfig   wikidicts   Wikis   wikis   will   with   without   won   word   words   work   working   works   would   writable   write   writing   written   yet   You   you   your   z0  

Clear message
Page Locked


Access Control Lists

Access Control Lists (ACLs) can be used to give specific users or groups the right to do specific actions. They can be used to:

To use ACLs, you need either access to the wiki config (to set global ACLs) or the admin right on the specific page where you want to set (or change) ACLs.

1. Contents

2. Basics

The ACL rights available are:

Using ACLs in moin is as easy as including a control line at the top of the page you want to control, like the following one:

#acl SomeUser:read,write All:read

This will allow SomeUser to read and write on that page, while every other user will be able to read but not edit it (unless you've done some special setup in the site configuration).

Attachments are also protected by the ACLs of the page they are attached to, when served through the moin wiki engine.

/!\ Attachments are not protected when the server is configured for direct access to the attachments (i.e. when the attachments option in wikiconfig.py is used).

3. Configuration

These are the configuration items used to setup ACLs on a moin site.






applied before page or default ACLs



applied after page or default ACLs


u"Trusted:read,write,delete,revert \
Known:read,write,delete,revert \

only used when no other ACLs are given on the page being accessed


["read",  "write",  "delete",  "revert",  "admin"]

These are the acceptable (known) rights (and the place to extend, if necessary).



Enables hierarchical ACL processing, see #hierarchical

So you know now what it does, but what does it mean?

It helps if you think of them as before, during, and after processing of page based ACLs.

(!) That u"" notation used for the configuration strings means unicode and must be there - see HelpOnConfiguration for details.

/!\ If you don't use CamelCase names for your group definitions e.g. PROJECTGroup you need to change the page_group_regex to u'[a-z0-9,A-Z]Group$'

4. Syntax

The syntax for each line is as follows:

#acl [+-]User[,SomeGroup,...]:[right[,right,...]] [[+-]OtherUser:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]


/!\ Do not put whitespace between the name and the rights - Allwrite,read is not a valid ACL string.

5. Available rights

These are the available rights you can use in an ACL entry. Be aware that DeletePage and RenamePage are not allowed if the user is not Known, even if a delete right is granted.

Given users will be able to read text of this page.
Given users will be able to write (edit) text of this page.
Given users will be able to delete this page and its attachments.
Given users will be able to revert this page to an older version.
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.

/!\ There is no separate rename right: renaming a page requires that a given user has the read, write and delete rights.

6. Processing logic on a single page

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

(!) 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, processing will only stop when requested right for some specific user matches the user and right(s) in the given ACL entry, but will continue if you are looking for another right (or another user). In case of '+' the right will be given, in case of '-' the right will be denied (for the stopping case).

As an example, assuming that SomeUser is a member of SomeGroup, the above ACL could also be written as:

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

This example is only special for SomeUser, because when admin right is queried for SomeUser, it will be denied and processing stops. In any other case, processing continues.

Or even:

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

+All:read means that when any user is requesting read right, it will be given and processing stops. In any other case, processing will continue. If admin right is queried for SomeUser, it will be denied and processing stops. In any other case, processing will continue. Finally if a member of SomeGroup is requesting some right it will be given if specified there and denied, if not. All other users have no other rights, except when given by configuration.

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.

7. Inheriting from defaults

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

acl_rights_default = u"TrustedGroup:read,write,delete,revert All:read"
acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

Now, you have some page where you want to give the "write" permission for SomeUser, but also want to keep the default behavior for 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:

#acl SomeUser:read,write TrustedGroup:read,write,delete,revert All:read

Lets look at the first example in this section:

acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

ACLs are processed in the order of "before" then "page/default" and then "after", "left to right".

So it begins at the left of "before" with AdminGroup:... - this matches if you are a member of admin group. If it matches, you get those rights (arwdr) and ACL processing STOPS.

If it does not match, ACL processing continues with +TrustedGroup:admin - this matches if you are a member of TrustedGroup.

If it matches, you get the rights (a) and - now the difference because of the modifier, - ACL processing CONTINUES! So if there is another match for that group or your user or Known: or All: you will get those rights, too.

If it does not match, ACL processing continues - with the page ACLs (if there are any) or with default ACLs (if there are no pages ACLs) and finally with the "after" ACLs.

While they represent the same thing, inheriting from the defaults has the advantage of automatically following any further change introduced in the defaults.

8. Hierarchical ACL processing

{i} New feature in version 1.6

If you have enabled acl_hierarchic (see above), then the pages are understood as a hierarchy and permissions set on higher-level pages may influence the user's permissions.

In a nutshell, if a permission is not resolved by the current page, then the parent page's ACL is checked, and then its parent, and so on until there are no parent pages.

All normal ACL rules are followed, as described above, but instead of checking the ACL from only the current page, the page's #acl line is appended with all the ACL from each page in the hierarchy, back to the root page. Consider the following examples for a page named A/B/C/D, that contrasts the how processing occurs with and without the feature enabled:


Processing Sequence


acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after


acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_after

Note that acl_rights_before, acl_rights_default, and acl_rights_after are not applied once per page in the hierarchy, but rather once overall during the processing of page A/B/C/D. As for the default rights, they sttill work as before, but instead of being included when the current page contains no ACL, it is only used if none of the pages in the hierarchy contain any ACL. So in a very real sense, the hierarchical ACL does nothing more than replace the current page's ACL with a concatenation of all #acl lines found in that page's hierarchy.

9. Groups

User groups make it easier to specify rights for bigger groups. Normally, the name of the group page has to end with Group like FriendsGroup. This lets MoinMoin recognize it as a list of usernames. This default pattern could be changed (e.g. for non-english languages etc.), see HelpOnConfiguration.

Only SomeUser's friends can read and edit this page:

#acl SomeUser:read,write SomeUser/FriendsGroup:read,write

SomeUser/FriendsGroup would be a page with each top-level list item representing a wiki username in that group:

#acl SomeUser:read,write,admin,delete,revert
 * JoeSmith
 * JoeDoe
 * JoeMiller

A page named AdminGroup 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.

/!\ A first level list is one with only one space before the asterisk (and there also has to be one space after the asterisk). The following won't work:

  * some user
-- two spaces like so and it doesn't work

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

page_group_regex =  u'[a-z]Group$'    # this is the default

/!\ If changes to the group page do not take effect, let MoinMoin rebuild the cache by simply removing all files in the directory path_to_your_wiki_instance/data/cache/wikidicts/

(!) Please note that after creating some group page(s), you maybe want to use those groups in some ACLs in your wiki configuration or on your pages (or nothing will happen - moin does not use something like pre-defined groups).

10. Usage cases

10.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 wikiconfig.py should look similar to that:

acl_rights_before = u'WikiEditorName:read,write,admin,delete,revert +AdminGroup:admin BadGuy:' 

The default acl_rights_default option should be ok for you:

acl_rights_default = u'Known:read,write,delete,revert All:read,write' 

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).

10.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 wikiconfig.py:

acl_rights_default = u'All:read' 
acl_rights_before  = u'WebMaster,OtherWebMaster:read,write,admin,delete,revert' 

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

#acl All: 

on it, so nobody else will be able to see the unfinished page. When finished, don't forget to remove that line, 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 

10.3. Wiki on Intranet

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

acl_rights_default = u'Known:admin,read,write,delete,revert All:read,write'
acl_rights_before  = u'WikiAdmin,BigBoss:read,write,admin,delete,revert' 

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).


10.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:

acl_rights_default = u"TrustedGroup:admin,read,write,delete,revert All:read"
acl_rights_before  = u"AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

This means that:

10.5. Comments on read-only page

You can easily add a comments section to a read-only page by using a writable subpage, and allowing users to write on it. For example, you can define SomePage like this:

#acl SomeUser:read,write All:read
'''Some read-only content'''


''' User comments '''

And SomePage/Comments like this:

#acl All:read,write
Add your comments about SomePage here.

11. See Also