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:

Conteúdos

<<TableOfContents: échec de l'exécution [list index out of range] (consultez également le journal de bord)>>

Conceitos Básicos

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

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

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

Configuração

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

Entrada

Por omissão

Descrição

acl_rights_before

u""

aplicada antes da página ou ACLs por omissão

acl_rights_after

u""

aplicada depois da página ou ACLs por omissão

acl_rights_default

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

utilizada apenas quando nenhuma outra ACL é definida numa página acessível

acl_rights_valid

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

Estas são as permissões (conhecidas) aceitáveis (e o local a expandir, se necessário).

acl_hierarchic

False

Activa o processamento de ACL de forma hierárquica, ver #Hierarquia

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

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$'

Sintaxe

A sintaxe de cada linha é a seguinte: 

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

Legenda:

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.

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.

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

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.

Processamento de ACLs de forma hierárquica

{i} 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.

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/

Casos práticos

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

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

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:

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:

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.

Ver também