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 ;]
12 respostas em “CakePHP: Plugin Auditable”
O problema com esse esquema de log eh a escalabilidade. Um sistema com centenas de usuarios durante alguns meses eh capaz de produzir bilhoes de itens. Talvez uma solucao melhor seja um arquivo ou algo como NoSQL.
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.
Podrias explicarme o compartir lo que hiciste con mongoDB?
Muchas Gracias!
[…] CakePHP: Auditando dados […]
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.
Opa Gaijinboy,
Ele registra o log quando é gerada a query tendo os statements UPDATE, INSERT ou DELETE.
No log da query, esses statements estão aparecendo? Nele algum campo é salvo/alterado?
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.