A Aldeia Numaboa ancestral ainda está disponível para visitação. É a versão mais antiga da Aldeia que eu não quis simplesmente descartar depois de mais de 10 milhões de pageviews. Como diz a Sirley, nossa cozinheira e filósofa de plantão: "Misericórdia, ai que dó!"

Se você tiver curiosidade, o endereço é numaboa.net.br.

Leia mais...

Informática Numaboa - Tutoriais e Programação

Controle de acesso no Joomla 1.5

Dom

4

Mai

2008


20:40

(29 votos, média 3.97 de 5) 


Grupos Multi-Nível

Os grupos podem ser estendidos para qualquer nível na árvore ARO. Por exemplo, podemos adicionar o grupo "Cozinha" à "Tripulação". A maioria dos tripulantes seria categorizada como "Tripulação", mas o Zé do Boné (cozinheiro) e a Margarida (copeira) seriam colocados na "Cozinha" e poderiam ter privilégios extras (como o acesso à Despensa):

Princesa dos Mares
|
|- Grupo Comando [ALLOW: ALL]
|  |- Maremoto
|  |- Barrica   [DENY: Despensa]
|
|- Grupo Tripulação [ALLOW: Refeitório]
   |- Cozinha [ALLOW: Despensa]
   |  |- Zé do Boné
   |  |- Margarida
   |- Zé Arruela [ALLOW: Máquinas]
   |- Papagaio   [ALLOW: Comando]

Como o phpGACL determina permissões

Quando o computador do Princesa dos Mares checa acessos, a única pergunta que ele pode fazer a si mesmo (melhor dizendo, ao phpGACL) é "A pessoa X tem acesso ao recinto Y?" o que, na linguagem nativa ACL é "O ARO X tem acesso ao ACO Y?"

O phpGACL determina se uma pessoa específica X tem acesso a um recinto específico Y trabalhando de cima para baixo na árvore ARO até chegar à pessoa especificada e anotando explicitamente todos os controles de acesso que for encontrando pelo caminho. Quando ele alcança a referida pessoa, ele usa o último controle de acesso encontrado e o devolve como resultado da busca. Deste modo, podemos definir controles de acesso para grupos de pessoas que, se houver necessidade, podem ser substituídos por outros num nível mais baixo.

Exemplo: a pergunta é "Margarida pode entrar no Refeitório?"

Seguindo o caminho na árvore ARO, chegamos até a Margarida da seguinte forma:

  • Princesa dos Mares: DENY ALL (o padrão é TUDO PROIBIDO)
  • Tripulação: ALLOW Refeitório, então o resultado interno é PERMITIDO Refeitório.
  • Cozinha: nenhuma referência ao refeitório, então ele continua PERMITIDO.
  • Margarida: nenhuma referência ao refeitório, então ele continua PERMITIDO.
  • Não tem mais para onde ir: o resultado é ALLOW Refeitório.

O exemplo nos mostra que, se um Grupo não especificar explicitamente uma permissão a um recinto, então o Grupo herda as restrições de acesso do seu Grupo Pai. Se o nó raiz ("Princesa dos Mares") não especificar uma permissão, ele herda a condição básica ("DENY ALL").

Isto conduz a vários pontos interessantes a respeito da árvore ARO:

  • A árvore ARO sempre mostra a lista completa dos AROs. Não teria sentido perguntar se "Marola tem acesso à cabine de comando" porque o Marola não foi definido neste sistema. O phpGACL, no entanto, não checa se algum ARO ou ACO existe antes de fazer a pesquisa e o resultado a esta pergunta seria a padrão "DENY".
  • A árvore ARO pode não mostrar algum ACO definido. Neste caso, a política padrão é usada para definir o acesso. Por exemplo, o capitão Maremoto definiu um ACO "Banheiro". Qualquer pergunta do tipo "Papagaio tem acesso ao Banheiro?" teria a resposta "DENY" porque o "Banheiro" não foi citado explicitamente em nenhum ponto da árvore ARO. Quando examinar uma árvore ARO não se esqueça de que alguns ACOs podem não estar visíveis.

info Apesar de "parecer" correto, ao fazer perguntas phpGACL sobre um acesso a algum ACO não é possível usar Grupos como AROs. Por exemplo, é impossível responder a pergunta "A Tripulação tem acesso à Sala de Máquinas?" porque a resposta completa não seria "ALLOW" ou "DENY" - seria alguma coisa mais complexa como "Zé Arruela pode, mas Zé do Boné, Margarida e o Papagaio não". Lembre-se, o phpGACL é de poucas palavras: sim ou não.

Resolvendo conflitos

Quando a árvore ARO começa a ficar mais complexa pode acontecer de um ARO ter acessos conflitantes. Veja no exemplo abaixo, quando o capitão Maremoto resolveu que o Barrica teria de ajudar na cozinha por uns tempos para aprender a se controlar melhor e não avançar sobre qualquer alimento que aparecesse na sua frente smile :

Princesa dos Mares
|
|- Grupo Comando [ALLOW: ALL]
|  |- Maremoto
|  |- Barrica   [DENY: Despensa]
|
|- Grupo Tripulação [ALLOW: Refeitório]
   |- Cozinha [ALLOW: Despensa]
   |  |- Zé do Boné
   |  |- Margarida
   |  |- Barrica
   |- Zé Arruela [ALLOW: Máquinas]
   |- Papagaio   [ALLOW: Comando]

Observe que, se o computador do navio seguir o caminho para o grupo Comando, o Barrica tem um DENY à Despensa. Se o computador seguir o caminho para o grupo Tripulação, subgrupo Cozinha, o Barrica tem um ALLOW à Despensa. Como é que fica, ele tem ou não tem acesso à Despensa?

Quando há acessos ambíguos numa ACL esta é chamada de INCONSISTENTE. ACLs inconsistentes podem ser muito perigosas porque podem dar acessos indesejados a pessoas não autorizadas. Para nossa sorte, o phpGACL avisa quando encontra controles de acesso ambíguos, mas não os corrige. Se receber um destes avisos você precisa corrigir o conflito porque o phpGACL não vai fazer isto por você.

Informações adicionais