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

Mas o objetivo deste post não é dizer o que já foi dito, quero iniciar uma série de posts onde vou explicar o funcionamento de alguns recursos dentro do Comitiva, convidando todos os desenvolvedores a opinar sobre implementação e contribuir com o projeto.

O assunto de hoje é controle de acesso, então vamos ao que interessa.

Como funciona o controle de acesso no Comitiva?

Utilizamos o componente Auth do CakePHP para cuidar da autenticação (efetuar login, verificar se o usuário está logado e efetuar logout).
Mas precisávamos ir um pouco além da configuração básica, definindo diferentes opções para diferentes tipos de usuários. Para isso, consideramos duas opções iniciais: usar também o Acl Behavior ou ficar apenas com o AuthComponent e criar diferentes actions para diferentes tipos de usuários.

Como possuímos apenas dois tipos de usuários (admin e participant) decidimos pela que seria mais simples inicialmente – mesmo sabendo que a manutenção no futuro poderia ser mais complicada – que foi criar diferentes actions para os tipos de usuários.

Para criar essa funcionalidade, definimos inicialmente um prefixo para cada tipo de usuário (prefixos ‘admin‘ e ‘participant‘). Em seguida configuramos o AuthComponent desta maneira (código extraído do AppController):

//Configure AuthComponent
$this->Auth->authorize = 'controller';
 
if( !isset($this->params['prefix']) || !( in_array($this->params['prefix'], Configure::read('Routing.prefixes')) ) )
{
	// all non-prefixed actions are allowed
	$this->Auth->allow('*');
}

Ou seja, toda ação que não tiver prefixo ou o prefixo não estiver definido nas configurações de rota serão públicas (assim é possível, por exemplo, deixar uma página com instruções acessível à qualquer usuário).

Mas como fica essa verificação de tipos no controlador? Como definimos o método de autorização do Auth como ‘controller’, precisamos definir em todos os controladores o método isAuthorized que deve retornar true quando o acesso é aprovado e false caso contrário.
Seguindo a ideia de que cada tipo de usuário possui um prefixo próprio nas ações, nosso método isAuthorized fica desta forma:

if($this->userLogged == TRUE && $this->params['prefix'] == User::get('type'))
{
	return true;
}
 
return false;

Onde o atributo $this->userLogged pertence a classe AppController e sua função é reduzir chamada ao método $Auth->login() e na segunda parte da condição temos uma comparação entre o prefixo da url acessada e o tipo do usuário – se ambos forem iguais, então o acesso está liberado.

Por fim, devemos criar nossas ações para cada tipo de usuário, onde o prefixo será usado para validar o acesso à aquela ação, veja o exemplo da ação “listar pagamentos”:

// ação exclusiva para admin - tem acesso aos pagamentos de todos os outros usuários
public function admin_index($event_id = null)
{
	$this->Subscription->recursive = 0;
 
	if(is_numeric($event_id))
	{
		$this->paginate = array(
			'conditions' => array(
				'event_id' => $event_id
			)
		);
	}
 
	$this->set(compact('event_id'));
	$this->set('subscriptions', $this->paginate());
}
 
// ação exclusiva para participant - tem acesso somente aos próprios pagamentos
public function participant_index()
{
	$this->Subscription->recursive = 0;
	$this->set('subscriptions', $this->paginate(array('user_id' => User::get('id'))));
}

Como podem ver, isso permite a criação de diferentes regras de negócio para os diferentes tipos de usuários e embora aumente a quantidade de código “redundante” por repetir alguns procedimentos para todos os tipos de usuários, a leitura e entendimento do código é facilitada – basta ver o prefixo do método (ação) para saber quem terá acesso a ele.

Porém os anos passaram e algumas coisas começaram a fazer falta: como faço quando estou desenvolvendo algo grande, fico sem commitar até ter algo estável/usável? crio um branch para isso? mas e depois para unir os branches, e os conflitos? além disso, se só eu estou trabalhando em cima disso, porque commitar para todo mundo algo não pronto?

Foi aí que descobri o GIT, um sistema de controle de versão distribuído, open source e gratuito. Ok, ele é gratuito e open source, mas isso não é motivo suficiente. Como disse, ele é um sistema de controle de versão distribuído, isso quer dizer que cada um que tem uma cópia do repositório tem de fato uma cópia dele, e pode servir outras pessoas, ver histórico, tudo localmente.

Então de quebra, ele resolve o problema de ter de criar um branch para desenvolver uma funcionalidade que só eu vou mexer, posso controlar cada alteração minha localmente, e quando quiser – se quiser – posso sincronizar meu repositório local com um outro central (que eu considero central, já que essa figura não existe no GIT). E mais, ele é MUITO RÁPIDO. Acho que para ajudar na argumentação de que é rápido basta dizer que ele foi feito por alguns desenvolvedores do Kernel Linux, e gerencia todo o código trabalhado por eles – e não é pouca coisa.

Ainda estou caminhando com o GIT, tenho aproveitado minha ânsia de aprende-lo junto com a de contribuir com softwares open source para criar e disponibilizar projetos no GitHub.

A grande maioria dos projetos é voltado ao CakePHP, mas há outras coisas também. Alguns projetos que podem interessar são:

• Comitiva – Sistema construído em CakePHP 1.3 para gerenciamento de eventos;
• Plugin Mailer – Um plugin que ajuda na utilização da biblioteca PHP SwiftMailer dentro do CakePHP;
• Behavior Locale – Um behavior para transformar dados vindo do usuário de seu padrão local para um padrão internacional (de banco de dados)
• Libs – uma coleção de pequenos scripts PHP que fui fazendo ao longo da vida. Há coisas boas, coisas úteis, coisas não tão úteis, mas tudo pode ser usado ao menos como ponto inicial para uma implementação mais elaborada.

Em nosso caso, cada prefixo representa um tipo de usuário.

A ideia ia bem, até termos que criar um link explicitando uma rota.

Por padrão, a classe Router reconhece o prefixo em uso no momento e adiciona ele na url que você está construindo, desta forma se eu estiver acessando um endereço http://comitiva/participant/events  e quiser criar um link para a url http://comitiva/admin/users  eu terei um problema (não documentado): a segunda url ficaria http://comitiva/partipant/users , por causa da página que está ativa no momento.

A solução foi me apresentada no IRC, canal #cakephp-pt pelo padeiro Danielpk: adicione um índice com o nome do prefixo associado ao valor TRUE no array de endereço.  Fica algo assim:

$this->Html->link('Administre os usuários', array('controller' => 'users', 'action' => 'index', 'admin' => true));
// ou, caso queira forçar o prefixo participant
$this->Html->link('Veja os usuários', array('controller' => 'users', 'action' => 'index', 'participant' => true));

Para quem me acompanha há algum tempo, sabe que participo do grupo e sempre ajudo de alguma forma no evento, dessa vez não seria diferente.
O evento terá 4 excelentes palestras, sendo duas de nossa celebridade convidada, Guilherme Blanco.

Tenho ajudado bastante no desenvolvimento de uma ferramenta para a gestão de eventos do grupo, que terá seu código liberado tão breve quanto fique pronto (ou seja, sem data, mas não deve demorar muito, hehehe). O nome dele é Comitiva.

Confira abaixo o release oficial:

O 3° Workshop do PHPMS será realizado no dia 27 de março no SENAC/MS, das 08:30 até 17:50. O evento vai contar com a presença de Guilherme Blanco que hoje trabalha na empresa sul-africana MIH/SWAT, desenvolvedor do core do projeto Doctrine, bem como nas frameworks Zend e Symfony. Ele vai apresentar duas palestras, “Overview do Doctrine 2.0″ e “Usando o Doctrine 2.0 com Zend Framework 1.10″.

Vamos ter também duas palestras sobre WordPress, a ferramenta de blog mais usada no mundo, Flávio Ricardo irá apresentar o tema “Gerenciando blogs e websites de forma flexível com WordPress MU” e em seguida Gabriel Novaes aborda o tema “WordPress SEO: Práticas e plugins para robos de busca”.

Sem falar na tradicional mesa-redonda para debater assuntos de interesse da comunidade de desenvolvedores PHP do estado, que vem nesse workshop com o tema “Perfil do programador PHP no estado de MS”.

Informações para inscrição no evento, grade completa, você encontra no hotsite do evento http://www.phpms.org/workshop/

Bom, a conclusão que tirei do comparativo foi de que a velocidade de execução é importante, mas mais do que isso, o programador é essencial. No exemplo da thread supracitada, o PHP perdia feio para as outras linguagens, mas olhando para o código escrito em PHP, dava para notar  vários erros de uso da linguagem e suas funções (ponto para o Begnini que viu o código antes de todos).

Então a dica de hoje é: estude bem a linguagem. Procure a saber o funcionamento das funções e construções da linguagem, isso é essencial para se tornar um bom programador.

Exemplos de código

//uso comum
for($i = 0; count($var) < 0; $i++)
  ...
 
//forma mais adequada
for($i = 0, $c = count($var); $c < 0; ++$i)
 ...
 
//outro caso, ao invés de forçar várias verificações
if( $a > 100 )
 ...
if( $a < 100 )
 ...
if( $a == 100 )
 
//use a estrutura adequada
if( $a > 100 )
 ...
else if( $a < 100 )
 ...
else //não precisa fazer o último teste
 ...
 
// esse último caso que me inspirou a fazer o post
 
// a pessoa só queria saber se o array $var tava vazio, e para isso contou todos os seus elementos
if ( count($var) > 0 )
 ...
 
// enquanto ela poderia ter usado uma verificação direta como
if ( !empty($var) )

Este último caso, que motivou o post foi visto no changelog da versão 1.2.6 do CakePHP. Neste caso o “erro” foi encontrado e corrigido pelo brasileiro Juan Basso neste commit.

O intuito do post não é meter o dedo na cara de ninguém, apenas alertar para situações onde culpamos uma determinada linguagem pelo desempenho de nossa aplicação quando o problema na verdade é o mal uso que estamos fazendo.

Desde meados de 2009 quem utiliza o Joomla! só pensa na próxima grande atualização do CMS, a versão 1.6. Ela deve incluir alguns dos itens mais requisitados pela comunidade como:

• Sistema de permissões, com possibilidade de se criar novos grupos e definir o que cada grupo pode fazer;
• União das Seções e Categorias, ao mesmo tempo que agora pode-se ter infinitas subcategorias;
• Suporte a outros sistemas de banco de dados;
• Assistente para adicionar link para um artigo enquanto estamos escrevendo outro artigo;

Agora parece que estamos perto do lançamento da próxima grande atualização do Joomla!, e pensando nisso baixei a versão atual em desenvolvimento do SVN e tirei alguns screenshot da área administrativa dessa nova versão, mostrando alguns dos recursos novos:

As últimas informações sobre o planejamento (incluindo o que deve ser feito e o que já foi feito) podem ser vistas nesta notícia e nesta página de status.

Podemos aguardar, na melhor das hipóteses, um release final do Joomla! 1.6 para março de 2010, o que não está muito longe, felizmente =]

Erros de codificação e configuração:

Quando acessamos um endereço de nossa aplicação e está faltando alguma coisa, o CakePHP nos retorna uma mensagem avisando sobre o erro ocorrido e a causa dele (o que falta fazer).

Erros HTTP:
Quando tentamos acessar um endereço inexistente (erro 404) e quando há falha no servidor (erro 500).

O primeiro tipo deixa de ser exibido quando você configura o debug para o valor zero. A partir deste momento todos os erros relacionados ao primeiro tipo serão mostrados como um erro 404.
O segundo tipo é exibido não importando o valor do debug.

Como personalizar essas mensagens?

Caso queira usar o mesmo layou definido no arquivo app/views/layouts/default.ctp, você precisará apenas criar uma pasta chamada errors dentro da pasta views  (caso ela não exista) e depois criar um arquivo para cada erro, ficando mais ou menos assim:

app/views/errors/error404.ctp
app/views/errors/error500.ctp
app/views/errors/missing_action.ctp

Veja a lista completa de arquivos acessando o diretório cake/libs/views/errors/
Caso queira ir um pouco além, personalizando também o layout da mensagem, adicione um arquivo com o layout definido em app/views/layouts/. Vamos chamar esse arquivo de errors.ctp;
Em seguida, vamos adicionar o seguinte código em nosso AppController:

/**
 * Caso já esteja usando o beforeRender, apenas adicione a linha interna abaixo ao seu beforeRender
 */
function beforeRender () {
       $this->_setErrorLayout();
}
 
function _setErrorLayout() {
    if($this->name == 'CakeError') {
        $this->layout = 'error';
    }
}

Pronto, agora é só personalizar o arquivo errors.ctp da forma que achar melhor =]
Dica retirada do Teknoid

PROBLEMA:
Ao tentar usar a função file_exists do PHP dentro do arquivo config/bootstrap.php para incluir um outro arquivo do mesmo diretório sempre recebia como resposta o valor FALSE

SOLUÇÃO:
Descobri que ao usar o file_exists o PHP estava tomando como diretório corrente o webroot/ e não o diretório do bootstrap.php (arquivo atual), então tive de acrescentar o prefixo ‘../config/’ para encontrar o arquivo que procurava.
Após usar o file_exists, iria dar um include no arquivo, neste caso o comportamento é diferente: ele considera o diretório corrente como sendo o diretório do arquivo que está chamando a função ( no meu caso o config/), portanto não é preciso adicionar prefixo nenhum.

Ainda não consegui descobrir o motivo desses dois comportamentos no mesmo ambiente, porém imagino que o comportamento do file_exists está ligado ao arquivo .htaccess do CakePHP que seta para o Apache o diretório webroot/ como sendo a raiz do domínio.

Se souber a resposta deixe-a no comentário que eu atualizo o post.

Até a próxima.

———————————–
Atualizando conforme combinado – 27/01/2010
———————————–

O Társis deu uma boa dica para evitar esse tipo de problema: utilizar as constantes do CakePHP, no caso da dica do post, a constante utilizada seria CONFIGS, ela contém o caminho completo para o diretório /config.

A chamada da função ficaria assim:

if( file_exists(CONFIGS . 'arquivo.php') ) include( CONFIGS . 'arquivo.php');

Além da constante CONFIGS temos algumas outras, como a WWW_ROOT e IMAGES que seguem o mesmo princípio, mas para apontar o caminho completo do diretório /webroot e /webroot/img respectivamente.
Veja a lista completa de constantes em http://book.cakephp.org/view/122/Core-Definition-Constants

Tenho feito alguns testes em cima dele, estou inclusive reescrevendo um pequeno CMS que possuímos na empresa em cima desta versão (árvore 1.3-dev do repositório do projeto) e apesar de alguns pequenos bugs (ainda é uma versão de desenvolvimento, né?) esta versão possui muitas melhorias na sintaxe – que agora está mais concisa –  e novas funcionalidades.

Para a migração de nossa aplicação, não foi preciso alterar muita coisa, porém para grandes aplicações, deve-se considerar a necessidade do upgrade.

Abaixo segue uma lista de links para algumas páginas com informações sobre esta nova versão do CakePHP (todas em inglês):

• Lista de TODO (tudo que já foi realizado está riscado)
• Novas features
• Guia de migração (upgrade de aplicação feita com o CakePHP 1.2 para 1.3)

Caso tenha interesse em ajudar os desenvolvedores, baixe a versão em desenvolvimento e faça alguns testes. Só não esqueça de reportar eventuais problemas ou patchs que você venha a produzir. Não se preocupem com o tempo de resposta da equipe de desenvolvimento, eles realmente estão empenhados em fazer um bom trabalho, é possível que tenha feedback de seu ticket/patch em menos de 1 hora – experiência própria.

Logo que concluir algumas tarefas e tiver feito mais testes colocarei aqui meu “parecer” sobre a nova versão, enquanto isso acompanhe a página de desenvolvimento para ficar por dentro das atualizações.