Listas de Control de Acceso

Cuando las listas de control de acceso(ACL) se activan, es posible controlar qué puede hacer quién en cada página del wiki.

1. Contenidos

Contents

Contenidos
Lo básico
Configuración
Sintaxis
Derechos posibles
Lógica de procesamiento
Inheriting from defaults
Groups
Usage cases

2. Lo básico

En cada nueva instalación las acl están inactivas por defecto. Para saber cómo activarlas Vea Configuración.

El uso de ACLs en moin es tan sencillo como colocar una línea de control de acceso en la parte superior de la página que está editando, como por ejemplo:

#acl CiertoUsuario:read,write All:read

$/!\$ Usted requiere tener derchos de admin para poder adicionar o modificar tal línea

Esto le permitirá a CiertoUsuario leer y escribir en tal página, mientras que todo el resto podrá leer pero no editarla (a menos que se haya hecho una configuración especial en el sitio).

Los adjuntos también se protegen con las ACLs de la página a la cual están vinculados cuando se ofrecen a través de los mecanismos de moin.

$/!\$ Los adjuntos no están protegidos cuando el servidor está configurado con acceso directo para ellos (esto es, cuando se usa la opción attachments en wikiconfig.py).

3. Configuración

Estos son los elementos que se pueden configurar las ACLs de un sitio moin.

Atributo	Default(Valor inicial)	Descripción
acl_enabled	`0`	Habilita ACL cuando es verdadero
acl_rights_before	`""`	se aplica antes que los de la página o los valores por defecto
acl_rights_after	`""`	se aplica después que los de la página o los valores por defecto
acl_rights_default	`"Trusted:read,write,delete,revert \` `Known:read,write,delete,revert \` `All:read,write"`	Se usanúnicamente si no se ha establecidoningún otro ACL a la página
acl_rights_valid	`["read",` `"write",` `"delete",` `"revert",` `"admin"]`	Estos son los derechos válidos (conocidos) (y el lugar para extenderlos, en caso de ser necesario).

Ahora que ya sabe lo que es, pero qué significa?

"antes" significa forzar (esto debido al algoritmo de elección) Úselo para su página de administradores del sitio o páginas de editores.
"Default" significa lo que se hace en caso de que no haya ACLs establecidos para la página. Es equivalente a haber escrito estos ACLs en una página. Son los que también se mezclan en caso de que haya un Default dentro de los ACL de la página.
"después" significa sin olvidar algo accidentalmente (como por ejemplo dar permiso de lectura para todos.)

Ayuda mucho pensar en el procesamiento de las ACLs en las etapas : antes, durante y después.

4. Sintaxis

La sintaxis para cada línea es de la siguiente forma:

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

Donde:

User is es un nombre de usuario y se procesa solamente si coincide el usuario.
SomeGroup es un nombre de página que concuerda page_group_regex con algunas línea de la forma " * Member" (ver Grupos).
Trusted es un grupo especial que contiene todos los usuarios autenticados que han usado la autenticación-Básica.
Known es un grupo especial que contiene todos los usuarios válidos (como cuando se usan las cookie).
All es un grupo especial que incluye a todos los usuarios (los usuarios conocidos y anónimos).
Default Es una opción especial que inserta en el sitio especificado las entradas de acl_rights_default (ver Por defecto).
right puede ser cualquier palabra de las siguientes : read, write, delete, revert, admin. Solamente se aceptan las palabras de acl_rights_valid, se ignora cualquier otra. Puede no especificarse nada, que significa que no se otorga ningún derecho.

$/!\$ No coloque espacios en blanco entre el nombre y los derechos - All: write,read no es una línea ACL válida.

5. Derechos posibles

Estos son todos los derechos disponibles que se puede usar en las ACLs. Tenga en cuenta que no se permite DeletePage ni RenamePage si el usuario no es Conocido, incluso si se otorga un derecho delete.

read: Se otorga a los usuarios para permitir el derecho a leer la página.
write: Se otorga a los usuarios que van a escribir (editar) textos en la página.
delete: Se otorga a los usuarios que pueden borrar la página y sus adjuntos.
revert: Se otorga a los usuarios que pueden revertir la página a una versión anterior.
admin: Se otorga a los usuarios que tienen derechos de administración para la página. Significa aquellos que pueden cambiar los ACL de una página, incluso dando "admin" a otros o eliminando "admin" de los que sea.

$/!\$ No hay un derecho rename separado: para renombrar una página se requiere que el usuario tenga derechos read, write y delete.

6. Lógica de procesamiento

Cuando un usuario trata de acceder a un recurso protegido por ACLs, estas se procesan en el orden en que aparecen. la primera ACL que coincide con el usuario determinará si puede acceder o no al recurso y terminará el procesamiento una vez que haya coincidencia con una entrada las ACL.

Debido a este algoritmo de la primera coincidencia es indispensable que ordene sus ACLs: primero los usuarios, después los grupos especiales, a continuación los grupos más generales, siguiendo los Known(conocidos) y finalmente All (todos).

Por ejemplo, la siguiente ACL dice que CiertoUsuario puede leer y escribir en los recursos protegidos por tal ACL, miemtras que cualquier miembro de CiertoGrupo (excepto CiertoUsuario, si es parte del grupo) puede además administrarlo, y cualquier otro puede leerlo.

#acl CiertoUsuario:read,write CiertoGrupo:read,write,admin All:read

Hay dos modificadores adicionales para hacer el sistema más flexible: los prefijos '+' y '-'. Cuando los usa, el procesamiento se detiene si y solo si un usuario específico coincide, asignándole los permisos dados por la ACL, pero continuará si está buscando otro permiso (u otro usuario). Con '+' se otorga el permiso, con '-' se niega (en caso de que se detenga).

Por ejemplo, si CiertoUsuario es miembro de CiertoGrupo, la ACL anterior se habría escrito como:

#acl -CiertoUsuario:admin CiertoGrupo:read,write,admin All:read

Este ejemplo es solamente especial para CiertoUsuario, porque cuando se busca el permiso admin para CiertoUsuario, se le negará y se detiene el procesamiento. En cualquier otro caso, continua.

O incluso:

#acl +All:read -CiertoUsuario:admin CiertoGrupo:read,write,admin

+All:read significa que cuando cualquier usuario solicita el permiso de lectura, le será otorgado y termina el procesamiento. En cualquier otro caso, el procesamiento continuará. Si el permiso de admin se solicita para CiertoUsuario, se negará y termina el procesamiento. En cualquier otro caso, el procesamiento continuará. Finalmente si un miembro de CiertoGrupo solicita algún permiso le será concedido si se epecificó, y le será negado si no. Todos los demás usuarios no tienen permisos, excepto los dados por la configuración.

Note que probablemente no desee usar el segundo o tercer ejemplo de las ACL para alguna página. Aunque son muy útiles en la configuración global.

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

Lets look at the first example in this section: acl_rights_before = "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. 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 recognise 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 so doesn't work

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

page_group_regex =  '[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/

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

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

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:

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:

by default known and anonymous users are only allowed to read pages
on a new page, users in TrustedGroup can put any ACLs they want
on existing pages, not having ACLs yet, any user in TrustedGroup user can set up any ACLs he wants
all people, except people in AdminGroup, can be locked out by other admins or trusted users
people in TrustedGroup get to use their admin rights on any page they're able to write, even if there are specific ACLs

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 '''
[[Include(SomePage/Comments)]]

And SomePage/Comments like this:

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

CategoryAyuda

AyudaSobreListasDeControlDeAccesoAcl (last edited 2008-04-20 14:37:39 by localhost)