Audit logs: model or controller?

[Ton Voon]

Hi!

I have a requirement for adding an audit log of certain actions  
(creating an object, editing the object, etc) to our web app. In my  
mind, it is best to do this at the model, so it is consistent  
regardless of the method of access.

However, one key bit of information I'd like to save is the user at  
the web app level. But this is not passed to the model. What would be  
a good way of having that information passed to the model (I was  
thinking of setting an environment variable at the start of a request  
and then removing it at the end)? Or is it best to have audit logs at  
the controller?

What have others done in similar cases?

Ton

http://www.altinity.com
T: [phone]
F: [phone]
Skype: tonvoon



_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Charlie Garrison]

Good evening,

On 17/9/07 at 12:55 PM +0100, Ton Voon <ton.voon@...> wrote:

>However, one key bit of information I'd like to save is the
>user at the web app level. But this is not passed to the model.
>What would be a good way of having that information passed to
>the model (I was thinking of setting an environment variable at
>the start of a request and then removing it at the end)? Or is
>it best to have audit logs at the controller?
>
>What have others done in similar cases?

You're looking for ACCEPT_CONTEXT. Took me a while to get the
right setup so that it did what I needed but works great now. I
couldn't find *one* complete example that showed me how to best
implement it, but after looking at various examples I was able
to pick out the bits that worked for my app. I ended up with
something very close to this <http://article.gmane.org/gmane.comp.web.catalyst.general/11887>.

Best practices say to only store the info from $context that you
need in your model rather than a reference to $context itself.
IOW, if you just need the current user object, then just store
that. I don't recall the reasoning for it though.

Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Jonathan Rockway]

Charlie Garrison wrote:

> You're looking for ACCEPT_CONTEXT. Took me a while to get the right
> setup so that it did what I needed but works great now. I couldn't
> find *one* complete example that showed me how to best implement it,
> but after looking at various examples I was able to pick out the bits
> that worked for my app. I ended up with something very close to this
> <http://article.gmane.org/gmane.comp.web.catalyst.general/11887>.
>
> Best practices say to only store the info from $context that you need
> in your model rather than a reference to $context itself. IOW, if you
> just need the current user object, then just store that. I don't
> recall the reasoning for it though.

You can try mixing in Catalyst::Component::ACCEPT_CONTEXT.  It will
handle the ACCEPT_CONTEXT magic and provide $c as $self->context for
you.  The reason for not storing $context in your model is because it
will create a circular reference if you're not careful.
Catalyst::Component::ACCEPT_CONTEXT is careful, so you don't need to
worry about that. :)

Regards,
Jonathan Rockway



_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Matt S Trout-2]

On Mon, Sep 17, 2007 at 12:55:52PM +0100, Ton Voon wrote:
> Hi!
>
> I have a requirement for adding an audit log of certain actions  
> (creating an object, editing the object, etc) to our web app. In my  
> mind, it is best to do this at the model, so it is consistent  
> regardless of the method of access.

The DBIx-Class-Journal stuff in trunk is pretty good for this, needs more
testing before we ship it but basically there.

> However, one key bit of information I'd like to save is the user at  
> the web app level. But this is not passed to the model. What would be  
> a good way of having that information passed to the model (I was  
> thinking of setting an environment variable at the start of a request  
> and then removing it at the end)? Or is it best to have audit logs at  
> the controller?

I tend to use DBIx::Class::Schema::RestrictWithObject
+ Catalyst::Component::InstancePerContext a lot and use the current user as
the restricting object, which mostly makes this go away.

--
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Charlie Garrison]

Good morning,

On 17/9/07 at 8:37 AM -0500, Jonathan Rockway <jon@...> wrote:

>> Best practices say to only store the info from $context that you need
>> in your model rather than a reference to $context itself. IOW, if you
>> just need the current user object, then just store that. I don't
>> recall the reasoning for it though.
>
>You can try mixing in Catalyst::Component::ACCEPT_CONTEXT.  It will
>handle the ACCEPT_CONTEXT magic and provide $c as $self->context for
>you.  The reason for not storing $context in your model is because it
>will create a circular reference if you're not careful.
>Catalyst::Component::ACCEPT_CONTEXT is careful, so you don't
>need to
>worry about that. :)

Thanks for that reference. That was one of the sources I looked
at, but I needed slightly different behaviour. I missed the
'weaken' stuff though. Reading up on that now.


Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/