The following 432 words could not be found in the dictionary of 550 words (including 550 LocalSpellingWords) and are highlighted below:

able   about   above   acceptable   accepted   access   Access   accessed   accidently   account   acl   add   Add   Admin   admin   admins   advantage   advice   affecting   after   again   algorithm   all   All   allow   allowed   allowing   also   an   Anchor   And   and   anonymous   anonymously   Any   any   anybody   anything   applied   apply   arbitrary   are   as   As   at   attachments   authenticated   automatically   Available   available   aware   Bad   bad   basically   Basics   be   because   before   behavior   being   besides   Big   bigger   Boss   but   by   called   can   cases   change   clean   closed   Comments   comments   community   company   config   configuration   Configuration   configure   Consequences   considered   containig   containing   content   Contents   control   Control   cookie   could   course   create   creator   currently   Default   default   defaults   define   definition   delete   depend   Description   destroy   do   Doe   does   doing   don   done   Due   each   easier   easily   easy   edit   editing   Editor   edits   either   else   enable   enabled   enforced   entries   entry   Entry   equivalent   even   every   everyone   exact   exactly   example   examples   except   existing   extend   few   finished   first   flexible   following   follows   For   for   force   forcing   forget   forgetting   form   found   free   Friends   friends   from   functionality   further   general   get   give   given   Given   giving   good   granting   group   Group   groups   Groups   Guy   has   have   having   he   here   hijacking   him   hostile   how   if   If   ignored   important   in   In   Include   including   information   inheriting   Inheriting   insert   inserts   intranet   introduced   is   it   It   item   items   its   Joe   just   keep   know   known   Known   last   let   level   like   line   lines   list   Lists   locked   locking   locks   logic   login   long   look   Ls   make   makes   Master   match   matches   matching   maybe   mean   means   Member   member   might   Miller   modifiers   more   most   much   name   Name   named   names   necessary   need   needed   new   no   nobody   non   not   Notice   Now   now   Of   of   ok   older   on   one   Only   only   onto   openness   option   Or   or   order   Other   other   others   otherwise   out   page   Page   pages   part   password   people   permission   place   placed   point   prefixes   probably   processed   Processing   protected   protection   public   Public   put   re   read   real   really   regex   remove   represent   representing   requesting   resource   resources   revert   revoking   right   rights   same   second   section   security   see   sense   senseful   set   settings   setup   short   should   shown   similar   simple   single   site   Smith   So   so   soft   Some   some   someone   something   Sometimes   sort   special   specific   Specifing   specify   still   stuff   subpage   support   suppose   Syntax   syntax   system   Table   tell   tells   temporarily   text   that   That   The   the   their   them   then   there   these   These   they   They   thing   third   this   This   though   to   To   too   top   triggers   true   trust   Trusted   trusted   trying   turned   two   unless   unready   up   Usage   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   who   why   will   with   without   won   word   words   work   works   would   writable   write   writing   written   yet   You   you   your  

Clear message

Access Control Lists

When Access Control Lists, or ACLs for short, are turned on, you will be able to control who may do what on or with a wiki page.

1. Contents

  1. Contents
  2. Basics
  3. Syntax
  4. Available rights
  5. Processing logic
  6. Inheriting from defaults
  7. Configuration
  8. Groups
  9. Usage cases
    1. Public community Wiki on the Internet
    2. Wiki as a simple CMS
    3. Wiki on Intranet
    4. Wiki as a public company page
    5. Comments on read-only page

2. Basics

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

3. Syntax

The syntax for each line is as follows:
#acl [+-]User[,SomeGroup,...]:[right[,right,...]] [[+-]OtherUser:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]


4. Available rights

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

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:
acl_rights_default = "TrustedGroup:read,write,delete,revert All:read"
acl_rights_before  = "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 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:

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

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

7. Configuration

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

Entry Default Description
acl_enabled 0 If true will enable ACL support.
acl_rights_before "" applied before page or default ACLs
acl_rights_after "" applied after page or default ACLs
acl_rights_default "Trusted:read,write,delete,revert Known:read,write,delete,revert All:read,write" only used when no other ACLs are given on the page being accessed
acl_rights_valid ["read", "write", "delete", "revert", "admin"] These are the acceptable (known) rights (and the place to extend, if necessary).

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

8. Groups

User groups make it easier to specify rights for bigger groups.

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 (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 should look similar to that:

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

The default acl_rights_default option should be ok for you:

acl_default = '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).

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
acl_rights_default = 'All:read' 
acl_rights_before  = 'WebMaster,OtherWebMaster:read,write,admin,delete,revert' 

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:
acl_rights_default = 'Known:admin,read,write,delete,revert All:read,write'
acl_rights_before  = '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).


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:
acl_rights_default = "TrustedGroup:admin,read,write,delete,revert All:read"
acl_rights_before  = "AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

This means that:

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