Categorias
Desenvolvimento Web

CakePHP: Plugin Auditable

Cenário: você desenvolve um sistema para uma empresa e 4 meses depois a gerência da empresa detecta um problema nos dados e solicita uma auditoria pra saber o que causou aquilo e quem é o responsável.

Este cenário é mais comum do que parece, em várias situações talvez não chegue a diretoria, mas algum usuário pede informação de como dada informação chegou ou saiu do sistema. Como você atenderia a solicitação? Se você não tem ainda uma resposta, vou apresentar uma alternativa, um plugin para CakePHP desenvolvido pela equipe da Radig (eu incluso) e disponível no seu github: github.com/radig/auditable

O objetivo do Auditable é muito simples: tornar qualquer sistema em CakePHP auditável.

O plugin é composto de duas peças chaves: uma classe de configuração e um behavior. Para tornar um modelo auditável, basta “plugar” o behavior à ele, a partir daí todas as informações criadas, alteradas ou removidas.

Há ainda um helper para ajudar na formatação das entradas do log e um controller simples que pode ser usado para visualizar o log.

Há casos de teste para todo o behavior e informações sobre sua configuração em seu readme: https://github.com/radig/auditable/blob/master/README.textile

Bom proveito =]

————–

Conforme o assunto se desenrolou nos comentários, implementamos os modelos Logger e LogDetail para uso junto ao CakeMongoDb para armazenar os logs no banco de dados MongoDB. Você pode conferir no plugin AuditableMongoLogger

Qualquer dúvida ou sugestão pode usar os comentários ou o Github ;]

Por Cauan Cabral

Desenvolvedor com 2 dígitos de experiências, especialista em PHP e CakePHP mas com bagagens em JavaEE, Node.js, Javascript (ES6, jQuery, Angular) e Python. Interessado em automação, Machine Learning e cozinha.

12 respostas em “CakePHP: Plugin Auditable”

Opa, realmente a escalabilidade não é um ponto forte da solução, mas o próprio plugin permite que você crie seu modelo e o utilize. Seu modelo pode usar qualquer tipo de persistência.
Pensei em usar arquivos como log primário, mas teria de criar um arquivo cada X entradas, ou para cada dia, o que tornaria a consulta bem complicada.
Usar um BD NoSQL parece uma ótima alternativa, vou testar se utilizando um modelo com MongoDB ele funciona tranquilo.

Estamos usando aqui o que imagino ser o “pai” do Auditable, o Logable.

Já pensando nessa questão de escalabilidade, remodelamos algumas partes para que ele funcionasse salvando os logs num arquivo. No presente momento não temos a demanda de visualização dos logs pelo cliente, os mesmo são utilizados por nós mesmos quando preciamos verificar alguma inconsistência ou “erro” humano.

Se o Auditable funcionar em bases NoSQL ou alguma abordagem semelhante será bem útil mesmo. Quem sabe em breve passaremos a utilizar e contribuir com o Auditable.

Criamos um modelo usando o MongoDB Datasource e o Plugin funciona “like a charm” =]

Não vou inclui-lo no plugin por que adiciona uma dependência externa, mas basta copiar o Logger atual e trocar o datasource dele.

Opa!
antes de mais nada queria agradecer pelo plugin, que poupou um enorme trabalho nessa ultima semana!

Uma coisa que notei em seu plugin, foi que ele registra o log mesmo sem ter tido altereção nos dados.
ex: quando alguém executa a ação para salvar, porém não foi editado nada no formulário.

Oi Cauan!

Perguntei porque quando executa o update no mysql e os dados são o mesmo, o mysql os ignora. No caso não houve a atualização e mesmo assim foi registrado no log.
Contudo creio que você tenha feito para registrar qualquer ação mesmo que nenhum dado tenha sido alterado no sistema.

Aproveitando, gostaria de tirar outra duvida contigo, eu estou usando o prefix admin e mesmo configurando o routes corretamente, só funciona se eu configurar no dentro routes.php do App.
Router::connect(‘/admin/auditable’, array(‘plugin’ => ‘auditable’, ‘controller’ => ‘loggers’, ‘admin’ => true));

para esse caso deve configurar de outra maneira?

Gaijinboy, não entendi o problema com a rota.

O plugin não usa a rota ‘admin’ por padrão, desse modo, caso queira ter o prefixo ‘admin’ você terá sim de definir explicitamente a rota, mas acho que seria algo como:

Router::connect(‘/admin/auditable’, array(‘plugin’ => ‘auditable’, ‘controller’ => ‘loggers’, ‘admin’ => false));
Router::connect(‘/admin/auditable/*’, array(‘plugin’ => ‘auditable’, ‘controller’ => ‘loggers’, ‘admin’ => false));

Oi Cauan!

Eu havia lido que quando usa prefixo, nao da pra sobrescrever a rota. So pelo routes.php do App/Config

Mas a sua dica funcionou perfeitamente!
A unica coisa que notei foi que a url ficou assim: admin/auditable/loggers
se definir no routes do App
aparece admin/auditable.

tirando isso funciona perfeito 🙂

Oi Cauan!

Estive configurando seu plugin hoje e me veio uma ideia que seria interessante para implementar ao seu plugin.
Na listagem do log, voce poderia colocar uma opção para desfazer o que foi feito.
Podendo assim restaurar os dados antigos.

Teria de editar muita coisa para implementar essa ideia?

[]’s.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.