No último post falei um pouco sobre o sistema de permissões que implantamos no Comitiva.
Acontece que após a adição de uma nova funcionalidade (submissão de trabalhos) aquele sistema de permissão começou a ficar ineficiente, e apesar de eu ter dito nos comentários que o ideal era implementar o Acl para este controle no sistema, acabei por implementar a solução sugerida pelo grande Humberto – que, tomando como ponto inicial o que tínhamos, era o jeito mais simples de solucionar os problemas.
Então o que mudou?
- Os usuários não possuem mais um “tipo”, agora eles pertencem a “grupos” (um ou mais);
- A verificação de permissão é feita na classe AppController, de forma genérica, o que elimina a necessidade de reescrever a função de autorização a cada controlador;
- Os grupos que um usuário pertence ficam definidos em um campo “groups”, do tipo varchar e são guardados codificados no formato json
- Defini um método protegido no AppController para verificar se o usuário logado pertence a um grupo qualquer, facilitando essa operação quando necessário. (o método chama-se AppController::__checkGroup($string) )
O que não mudou?
- As ações continuam tendo como prefixo o grupo que pode acessa-la, sendo assim, a ação ProposalsController::participant_add() está disponível a todos os usuários que pertençam ao grupo “participant”
- Todos os usuários registrados pertencem inicialmente ao grupo ‘participant’, porém podem vir a pertencer a outros grupos posteriormente (em adição ao grupo ‘participant’)
- Continua sendo muito fácil saber se o usuário logado pode ou não efetuar uma ação, basta usar o método supracitado __checkGroup.
Exemplo de como verificar se o usuário é administrador
if($this->__checkGroup('admin'))
echo 'O usuário logado é administrador';
else
echo 'O usuário logado não é administrador';
