|
Share this
Twitter
Mister Wong
Digg
Yahoo
Technorati
Newsvine
Googlize this
Blinklist
Facebook
Hear this text
Export PDF
Print
E-mail
Analisando o controle de acesso no Joomla 1.5 acabei descobrindo que as novas versões vêm com o phpGACL completinho e que o uso deste excelente conjunto de funções é utilizado apenas uma vez (e de modo muito precário) na autenticação de usuários. É uma pena porque, se fosse devidamente explorado, poderíamos criar novos grupos de usuários, regras de acesso e muito mais.
Porque um sistema de controle de acesso?
Aviso aos navegantes: o componente Control, citado acima, NÃO vai permitir controlar o componente nativo com_content, responsável pela apresentação das páginas do conteúdo. Ao invés de começar a hackear o código fonte do Joomla, o melhor é adquirir experiência com componentes próprios e deixar para os desenvolvedores deste CMS a tarefa de incorporar definitivamente o phpGACL de forma mais completa.
O que é o phpGACL?
O porque do nome começar com php está na cara, mas o que vem a ser GACL? É Generic Access Control List, ou seja, Lista de Controle de Acesso Genérica. Este projeto é da autoria de Mike Benoit e pode ser encontrado na sourceforge.net. Taí o endereço, se bem que, como já disse, o Joomla traz a última versão (procure em /libraries/joomla/phpgacl - são apenas dois arquivos relativamente pequenos, o gacl.php e o gacl_api.php).
Entendendo o Controle de Acesso
Melhor do que ficar discutindo conceitos teóricos é partir para exemplos práticos. Vamos imaginar o seguinte cenário: Maremoto é o capitão do navio Princesa dos Mares e Barrica é seu imediato. Eles levam alguns passageiros a bordo: Zé Arruela, Zé do Boné, Margarida e Papagaio. Maremoto precisa definir restrições de acesso para vários recintos do navio: Cabine de Comando, Refeitório, Despensa e Casa das Máquinas.Maremoto diz: "Eu e o Barrica precisamos ter acesso a qualquer recinto mas, depois que ele acabou com as barras de chocolate, proibi o Barrica de chegar perto da despensa. Os passageiros só podem entrar no refeitório".
A partir de agora vamos assumir que o acesso é booleano, isto é, a verificação do acesso de uma pessoa a um determinado recinto é PERMITIDO (ALLOW) ou PROIBIDO (DENY). Não existe mais ou menos, é sim ou não. Se mapearmos esta declaração numa matriz de acesso que mostre quem tem acesso a que, o resultado será este (0 significa PERMITIDO e X significa PROIBIDO):
As colunas mostram os recintos de acesso restrito e as linhas mostram as pessoas que podem solicitar acesso a estes recintos. Em termos mais gerais, os "recintos" são "coisas cujo acesso precisa ser controlado". Chamamos estas "coisas" de Objetos de Acesso Controlado (ACO Access Control Objects). As pessoas são "coisas que solicitam acesso" e são chamadas de Objetos de Solicitação de Acesso (ARO Access Request Objects). As pessoas solicitam acesso aos recintos ou, na terminologia ACL, AROs solicitam acesso a ACOs.Existe um terceiro tipo de objeto, o Objeto de eXtensão de Acesso (AXO Access eXtension Object) que será apresentado a vocês mais adiante. Estes objetos são coletivamente chamados de Objetos de Acesso (Access Objects).
* Sua granularidade é muito fina. É possível controlar o acesso para cada uma das pessoas se for necessário.
* É muito fácil ver quem tem acesso a o que. A resposta fica na intersecção da pessoa e do recinto.
As desvantagens, por sua vez, são as seguintes:
* Fica difícil administrar em larga escala. 6 passageiros e 4 recintos é uma coisa bastante simples, mas e se fosse um transatlântico com milhares de passageiros e centenas de recintos? E se fosse preciso restringir o acesso a grupos grandes e ainda assim manter uma granularidade suficiente para poder controlar as pessoas individualmente? A tarefa seria muito difícil, trabalhosa e propensa a erros.
* Ficaria difícil resumir ou visualizar. O exemplo anterior é bastante simples, mas, e se a matriz fosse a mostrada logo abaixo? Mesmo com pouca gente a coisa fica bem mais complicada.
Definindo o controle de acesso com o phpGACL
Parece que para situações mais complexas esta técnica da 'matriz de acesso' não é muito apropriada. Precisamos de um sistema melhor que mantenha as vantagens (controle de granularidade fina e uma noção clara de quem tem acesso a que), mas que elimine as desvantagens (dificuldade de resumir e dificuldade de administrar grandes grupos de pessoas). Uma das soluções é o phpGACL (não foi por acaso que os responsáveis pelo Joomla fizeram esta opção).O phpGACL não descreve o acesso de 'baixo para cima' como as matrizes de acesso mostradas. Faz exatamente ao contrário, de 'cima para baixo', assim como a descrição textual da política de acesso feita pelo capitão Maremoto. Isto é um sistema muito flexível que permite administrar acessos de grupos grandes, sintetiza muito bem a política de acesso e fica fácil de ver quem pode acessar o que.
Uma árvore ARO define uma hierarquia de Grupos e de AROs (coisas que solicitam acesso). É muito parecida com a árvore de diretórios (pastas) e arquivos. As 'pastas' são os Grupos e os 'arquivos' são os AROs.
Vamos fazer uma árvore ACL para as pessoas do navio do Maremoto. Primeiramente definimos algumas categorias para as pessoas. É evidente que Maremoto e Barrica comandam o navio e que o restante das pessoas fazem parte da tripulação:
Princesa dos Mares
|
|- Grupo Comando
| |- Maremoto ARO
| |- Barrica ARO
|
|- Grupo Tripulação
|- Zé Arruela ARO
|- Zé do Boné ARO
|- Margarida ARO
|- Papagaio ARO
Esta árvore, por si só, não especifica qualquer política de acesso - ela só mostra como estamos agrupando as pessoas que podem requisitar acesso (AROs). Podemos aplicar restrições de acesso colocando instruções sobre determinados recintos (ACOs) para Grupos ou AROs na árvore. Maremoto diz: "Como padrão, ninguém pode ter acesso a qualquer recinto do Princesa dos Mares. Mas o comando deve ter acesso a todos os recintos. A tripulação pode ter acesso apenas ao refeitório".
Princesa dos Mares
|
|- Grupo Comando [ALLOW: ALL]
| |- Maremoto
| |- Barrica
|
|- Grupo Tripulação [ALLOW: Refeitório]
|- Zé Arruela
|- Zé do Boné
|- Margarida
|- Papagaio
Em primeiro lugar, a política padrão é proibir o acesso. As permissões podem ser substituídas para o "Comando" de modo que este tenha acesso a tudo ("ALL" significa TUDO, todos os recintos: "Comando, Refeitório, Despensa, Máquinas"). A "tripulação" tem acesso apenas ao Refeitório.
Resumindo:
* Access Control Objects (ACOs) são coisas cujo acesso queremos controlar (por exemplo, páginas web, bases de dados, recintos, etc).
* Access Request Objects (AROs) são coisas que requisitam acesso (por exemplo, pessoas, computadores remotos, etc)
* Árvores ARO definem uma hierarquia de Grupos e AROs. Grupos podem conter outros Grupos e AROs.
* A política default 'pega-tudo' para a árvore ARO sempre é "DENY ALL".
* Para definir uma política de acesso vá descendo a árvore e, quando necessário, assinale explicitamente as permissões para Grupos e AROs.
Controle de Acesso de granularidade fina
Xiiii, esquecemos que o Barrica não pode entrar na despensa. Como ele está no grupo Comando, ele acaba tendo acesso a todos os recintos. Peraí!
Princesa dos Mares
|
|- Grupo Comando [ALLOW: ALL]
| |- Maremoto
| |- Barrica [DENY: Despensa]
|
|- Grupo Tripulação [ALLOW: Refeitório]
|- Zé Arruela
|- Zé do Boné
|- Margarida
|- Papagaio
Outro exemplo de controle de granularidade fina acontece quando o mar resolve encrespar: o capitão Maremoto precisa do Zé Arruela na casa das Máquinas e do seu Papagaio de estimação a seu lado, na cabine de comando:
Princesa dos Mares
|
|- Grupo Comando [ALLOW: ALL]
| |- Maremoto
| |- Barrica [DENY: Despensa]
|
|- Grupo Tripulação [ALLOW: Refeitório]
|- Zé Arruela [ALLOW: Máquinas]
|- Zé do Boné
|- Margarida
|- Papagaio [ALLOW: Comando]
fonte joomlarj