Listas de Controlo de Acesso

As Listas de Controlo de Acesso (ACLs) permitem ao administrador do wiki dar permissões de algumas acções (leitura, edição e eliminação) a utilizadores ou grupos, em páginas específicas. Elas permitem-lhe:

• ocultar algumas páginas do público.
• publicar apenas algumas páginas de livre acesso.
• dar permissões de edição a alguém ou a um grupo numa ou mais páginas.
• permitir ou não permitir a eliminação de páginas.
• controlar quem pode alterar as regras de administração de uma página.

1. Conteúdos

2. Conceitos Básicos

As acções gerais que estão disponíveis para controlo são:

• read (leitura) - quem pode ler uma página
• write (edição) - quem pode editar uma página
• delete (eliminação) - quem pode eliminar uma página
• revert (reposição) - quem pode repor um conjunto de páginas de uma versão anterior
• admin (administração) - quem pode alterar a linha "#acl" de uma página.

Utilizar ACLs no moin é tão fácil como incluir uma linha de controlo no topo da página que deseja controlar, como a seguinte:

#acl SomeUser:read,write All:read

• Tem de já ter permissões de admin para poder adicionar ou modificar uma linha de acl deste tipo - consulte os tópicos AjudaNaConfiguração e AjudaNaAutoAdministração.

Isto irá permitir que o SomeUser possa ler e editar essa página, enquanto todos os outros utilizadores poderão ler, mas não editar a página (excepto se tiver efectuado uma configuração especial na configuração do sítio).

Os anexos são igualmente protegidos pelas ACLs da página a que pertencem, mesmo estando localizadas no servidor de wiki do moin.

Os anexos não são protegidos quando o servidor estiver configurado para acesso directo aos anexos (ou seja, quando a opção attachments é utilizada no wikiconfig.py).

3. Configuração

Estes são os itens de configuração utilizados na configuração de ACLs num sítio moin.

Portanto, agora sabe o que faz, mas o que significa?

• "antes" significa forçar algo (isto deve-se à primeira correspondência do algoritmo) Utilize isto para os administradores e editores de páginas de todo o seu wiki.

• "por omissão" significa o que acontece se nenhum ACL for definido na página. Isto é igual a definir exactamente estes ACLs numa página. Estes são também as permissões que se fundem se escrever Default (por omissão) entre as ACLs da página.

• "depois" significa não forçar algo acidentalmente (como por exemplo dar permissões de leitura a todos)

Ajuda pensar nelas como o processamento de ACLs baseadas em páginas antes, durante e depois.

A anotação u"" utilizada nas strings de configuração significa Unicode e tem de lá estar - para mais informações, consulte o tópico AjudaNaConfiguração.

Se não utilizar nomes CamelCase nas definições do seu grupo, exemplo PROJECTGroup é necessário alterar o page_group_regex para u'[a-z0-9,A-Z]Group$'

4. Sintaxe

A sintaxe de cada linha é a seguinte:

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

Legenda:

• User é o nome de utilizador e o que se segue só é activado se o utilizador coincidir.

• SomeGroup é um nome de página correspondente ao page_group_regex com algumas linhas no formato " * Member" (ver #Grupos).

• Trusted é um grupo especial que contém todos os utilizadores autenticados que utilizaram uma autenticação de HTTP básica.

• Known é um grupo especial que contém todos os utilizadores válidos (por exemplo, ao utilizar a cookie).

• All é um grupo especial que contém todos os utilizadores (utilizadores conhecidos e anónimos).

• Default é um registo especial que insere num determinado local os registos do acl_rights_default (ver #PorOmissão).

• right pode ser uma palavra arbitrária como read, write, delete, revert, admin.

Apenas as palavras existentes no acl_rights_valid são aceites, as restantes são ignoradas. É permitido não especificar permissões, o que significa que não são dadas permissões.

Não deixe espaços em branco entre o nome e as permissões - All: write,read não é uma string de ACL válida.

5. Permissões disponíveis

Estas são as permissões disponíveis que pode utilizar num registo de ACL. Tenha em atenção que não é permitido EliminarPágina e RenomearPágina se o utilizador não for Known, mesmo que a permissão delete seja atribuída.

read

Os utilizadores com esta permissão poderão ler o texto dessa página.

write

Os utilizadores com esta permissão poderão editar o texto dessa página.

delete

Os utilizadores com esta permissão poderão eliminar essa página e respectivos anexos

revert

Os utilizadores com esta permissão poderão repor uma versão anterior dessa página.

admin

Os utilizadores com esta permissão terão permissões administrativas nessa página. Isto significa que estes utilizadores poderão alterar as definições de ACL, incluindo a atribuição/revogação de permissões administrativas a/de outros utilizadores.

A permissão rename não existe isoladamente: para renomear uma página é necessário que o utilizador tenha permissões de escrita, de edição e de eliminação.

6. Processar lógica numa só página

Quando algum utilizador tentar aceder a um recurso protegido pelas ACLs, estas serão processadas pela ordem que forem localizadas. A primeira ACL que corresponda ao utilizador ditará se o utilizador tem acesso a esse recurso ou não, e o processamento terminará assim que o utilizador tenha um registo de ACL correspondente

Devido a esse algoritmo first match (primeira ACL correspondente), deve dispor as suas ACLs da seguinte forma: primeiro os nomes de utilizadores individuais, depois os grupos especiais, depois os grupos gerais, depois os Known e por fim os All.

Por exemplo, a ACL que se segue define que SomeUser pode ler e editar os recursos protegidos por essa ACL, enquanto que qualquer membro do grupo SomeGroup (para além do SomeUser, caso faça parte do grupo) pode também administrá-los, e os restantes utilizadores poder lê-los.

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

Para tornar o sistema mais flexível, existem também dois modificadores: os prefixos '+' e '-'. Quando são utilizados, o processamento só termina quando a permissão pedida a um utilizador específico corresponda ao utilizador e à(s) permissão(ões) atribuída(s) no registo da ACL, mas continuará se estiver à procura de outra permissão (ou outro utilizador).

No caso de '+' a permissão será atribuída, no caso de '-' a permissão será negada (no caso do processamento terminar).

Como exemplo e assumindo que o SomeUser é um membro do grupo SomeGroup, a ACL em cima podia ser igualmente definida assim:

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

Este exemplo só é especial para o SomeUser, porque quando a permissão de administração for solicitada para o SomeUser, esta será negada e o processamento termina. Em qualquer outro caso, o processamento continua.

Ou ainda:

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

O +All:read significa que quando um utilizador pedir permissão de leitura, esta será atribuída e o processamento termina. Em qualquer outro caso, o processamento continua. Se a permissão de administração for solicitada para o SomeUser, esta será negada e o processamento termina. Em qualquer outro caso, o processamento continua. Por último, se um membro do grupo SomeGroup solicitar alguma permissão que lá esteja especificada, esta será atribuída, caso não esteja, será negada. Todos os outros utilizadores não têm outras permissões, excepto se forem atribuídas na configuração.

Tenha em consideração que provavelmente não quererá utilizar os segundo e terceiro exemplos nos registos de ACLs de uma página. No entanto, são muito úteis nos registos da configuração do sítio

7. Herdar valores por omissão

Pode ser útil, por vezes, atribuir permissões a alguém sem afectar em demasia as permissões por omissão. Por exemplo, vamos supor que tem os seguintes registos na sua configuração:

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

Agora, tem algumas páginas nas quais quer atribuir permissões de escrita ao SomeUser, mas também quer manter o comportamento por omissão para All e para o TrustedGroup. Pode fazê-lo facilmente utilizando o registo Default (por omissão):

#acl SomeUser:read,write Default

Isto irá inserir os registos a partir do acl_rights_default exactamente no local onde a palavra Default for colocada. Por outras palavras, o registo em cima, com a configuração definida dessa forma, é equivalente ao registo seguinte:

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

Vamos ver melhor o primeiro exemplo desta secção:

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

As ACLs são processadas pela ordem "before" (antes), "page/default" (página/por omissão) e "after" (depois), "da esquerda pata a direita".

Assim começa à esquerda de "before" com AdminGroup:... - isto coincide se for um membro do AdminGroup. Se coincidir, obtém essas permissões (arwdr) e o processamento de ACL TERMINA.

Se não coincide, o processamento de ACL continua com o +TrustedGroup:admin - isto coincide se for um membro do TrustedGroup.

Se coincidir, obtém as permissões (a) e - devido ao modificador, o processamento da ACL CONTINUA! Assim se existir outra coincidência para aquele grupo, para o seu utilizador, para Known: ou para All: obterá essas permissões, também.

Se não coincidir, o processamento da ACL continua - com as ACLs da página (se existir alguma) ou com as ACLs por omissão (se não existirem ACLs da página) e finalmente com as ACLs "after".

Ao representar a mesma coisa, herdar os valores por omissão tem a vantagem de seguir automaticamente qualquer alteração futura adicionada nos valores por omissão.

8. Processamento de ACLs de forma hierárquica

New feature in version 1.6 Se tiver activado o acl_hierachic (ver em cima), as páginas são vistas como uma hierarquia e as permissões definidas em páginas num nível mais elevado podem influenciar as permissões do utilizador.

Como descrevemos em cima, o algoritmo correspondente de cada página mantém-se. As páginas são verificadas de baixo para cima, ou seja, na página A/B/C/D, a página A é verificada em último lugar. Isto significa que para cada página da hierarquia, o before (antes) e after (depois) das ACLs são respeitados. Se uma destas verificações for coincidente (seja permitido ou não), será o resultado final de uma sequência de verificações. Caso contrário, o segundo nível mais alto será verificado.

9. Grupos

Os grupos de utilizadores simplificam a tarefa de especificar permissões para grupos maiores. Normalmente, o nome do grupo tem de terminar com a palavra Group como FriendsGroup. Isto permite ao MoinMoin reconhecê-lo como uma lista de nomes de utilizadores. Este padrão por omissão pode ser alterado (ex: para outros idiomas que não o inglês, etc.), consulte o tópico AjudaNaConfiguração.

Apenas os amigos (~friends) do SomeUser podem ler e editar esta página:

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

O SomeUser/FriendsGroup será uma página com cada item da lista de nível de topo que representam um nome de utilizador do wiki nesse grupo:

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

Uma página intitulada AdminGroup pode definir um grupo desse nome e pode ser igualmente protegido pelas ACLs:

#acl AdminGroup:admin,read,write All:read
 * SomeUser
 * OtherUser
   * Isto é actualmente ignorado.
Qualquer outro texto fora do primeiro nível da lista será ignorado.

Uma lista de primeiro nível é uma apenas com um espaço antes do asterisco (e tem de existir apenas um espaço depois do asterisco). O exemplo seguinte não funcionará:

  * some user
-- com dois espaços não funciona

Pode configurar quais os nomes das páginas considerados como páginas de definição de grupos (ex: para wikis que não sejam em inglês):

page_group_regex =  u'[a-z]Group$'    # isto é o valor por omissão

Se as alterações na página de grupo não sortirem efeito, o MoinMoin pode reconstruir a cache, removendo todos os ficheiros da directoria caminho_para_o_seu_ wiki_de_exemplo/data/cache/wikidicts/

10. Casos práticos

10.1. Wiki como comunidade pública na Internet

O ponto mais importante aqui é utilizar as ACLs apenas onde é estritamente necessário. Os Wikis dependem na liberdade da informação e edição. Utilizam segurança mínima para limpar conteúdos menos bons. Assim, geralmente as ACLs não são necessárias. Se as utilizar em demasia, pode destruir o modo de funcionamento do wiki.

Eis o motivo pelo qual as ACLs não devem ser utilizadas (por omissão, ou, caso o sejam, o ficheiro wikiconfig.py deve parecer-se com isto

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

A opção por omissão acl_rights_default deve ser satisfatória para si:

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

Um bom conselho será ter apenas um conjunto pequeno de administradores de confiança no AdminGroup (devem estar a par do funcionamento do wiki ou poderão destruir acidentalmente o modo de funcionamento: pela sua liberdade, não por ser fechado e trancado!).

Ao utilizar AdminGroup, pode criar uma página intitulada AdminGroup e utilizá-la para definir as pessoas a quem atribui permissões de administração.

Ao especificar BadGuy como mostramos em cima, bloqueia-lhe o acesso - ele não pode ler nem editar nada com essa conta. Isto só faz sentido temporariamente, caso contrário bastaria eliminar essa conta. É claro que este BadGuy pode trabalhar como anónimo, não oferecendo por isso uma protecção verdadeira (a segurança mínima seria aplicada nestes casos).

10.2. Wiki como um CMS simples

Se deseja utilizar um wiki para criar facilmente conteúdo Web, e não quiser edições públicas (apenas de alguns webmasters), pode utilizar o seguinte no seu ficheiro wikiconfig.py:

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

Assim todos podem ler, mas apenas os Webmasters podem fazer qualquer outra coisa. Se trabalharem numa nova página, coloquem

#acl All: 

nela, para que ninguém possa ver a página inacabada. Ao finalizá-la, não se esqueça de remover essa linha de novo para que acl_rights_default seja utilizada.

Para que alguma(s) página(s) possam igualmente permitir comentários (como um intitulado PublicComments), atribua mais permissões nessa página:

#acl All:read,write 

10.3. Wiki na Intranet

Se quiser utilizar um wiki na sua intranet e confia nos seus utilizadores (no que diz respeito a não ter atitudes hostis como bloquear outros utilizadores ou atacar páginas) para utilizar a funcionalidade de administração de um modo sensato, pode utilizar o seguinte:

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

Assim, todos poderão ler, editar e alterar as permissões das ACL, o WikiAdmin e o BigBoss são forçados a conseguir fazer qualquer coisa, os utilizadores known têm permissões de administração atribuidos pelo acl_rights_default (assim mantêm-na a não ser que haja uma ACL em contrário numa determinada página).

Consequências:

• numa nova página, o criador da página pode definir as ACLs que quiser
• nas páginas existentes, não existindo ainda ACLs definidas, qualquer utilizador conhecido pode definir as ACLs que entender

• todas as pessoas (à excepção do WikiAdmin e do BigBoss) podem ser bloqueadas por qualquer pessoas ("known") nas páginas sem ACLs definidas

10.4. Wiki como uma página pública de uma empresa

Se quiser utilizar um wiki como a página da empresa, e não quiser que qualquer utilizador possa alterar o conteúdo da página da empresa, pode definir as ACLs assim:

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

Isto significa que:

• por omissão, os utilizadores conhecidos e anónimos têm apenas permissões de leitura

• numa nova página, os utilizadores do grupo TrustedGroup podem adicionar as ACLs que quiserem

• nas páginas existentes, não existindo ainda ACLs definidas, qualquer utilizador do grupo TrustedGroup pode defini-las como quiser

• todas as pessoas, à excepção das do grupo AdminGroup, podem ser bloqueadas pelos administradores ou pelos utilizadores de confiança

• as pessoas do grupo TrustedGroup podem utilizar as suas permissões de administração em qualquer página em que tenham permissões de edição, mesmo quando existem ACLs específicas

10.5. Comentários em páginas apenas para leitura (read-only)

Pode adicionar uma secção de comentários numa página apenas para leitura, utilizando uma subpágina editável e permitindo que os utilizadores a editem. Por exemplo, pode definir SomePage da seguinte forma:

#acl SomeUser:read,write All:read
'''Algum conteúdo apenas para leitura'''

...

''' Comentários do utilizador '''
<<Include(SomePage/Comments)>>

E SomePage/Comments assim:

#acl All:read,write
Adicione os seus comentários sobre SomePage aqui.

11. Ver também

• AjudaNaAutoAdministração: A funcionalidade AutoAdmin permite que os utilizadores tenham permissões de administração sobre um subconjunto do wiki