On 08/25/2011 05:43 PM, Miroslav Suchý wrote: > On 08/25/2011 02:30 PM, Johannes Renner wrote: >> So (1.) there are some helper classes that I put into a new separate >> package, see 01-new-classes.patch: > > AuditLog.java has 4 (!) functions log() and all of them has different > semantics - if I ommit that they are utilized to logging. Please > consider different names.
Well, I can count three, while only one (!) of them is public. But we can still rename the other ones, no problem. >> >> Therefore there is (2.) calls to the logger from within the existing >> code, see 03-rhnaction-example.patch: > > Hmm, what I dislike is the need to change the code. Which will be prone > to coder error and you may end up in situtation where somebody commit > code, which are worth auditing, but the audit call will not be there. > > If I would be designing such functionality I would prefer something like > mod_security. So you will have one entry point and you will not care if > the action is actually handled by cobbler, backend, frontend or some aliens. > This would even allow you to have configuration file where you will > define what and how will be audited. > In your design it will be hard to say which actions are audited. > Especially in 2 years from now, when other will add/remove/change your > initial audit calls. I completely agree and also dislike the need to change the code, but: If we wanted to log only HTTP requests and responses we could very well use something like mod_security, or alternatively use a ServletFilter or put the implementation into RhnRequestProcessor. Such an implementation would be much easier and there would be a single entry point, but there is several disadvantages as well, e.g.: - How can you distinguish between interesting and uninteresting requests? - There is some interesting requests that are not POST requests, e.g. logouts. - There is some POST requests that are not interesting, e.g user selects all entries of a list. - Log events cannot be categorized for a later filtering. At a single entry point it is very hard to see what really has happened. - When using an external entry point (like mod_security), you can't actually see from the logs which user was involved since it is not possible to map between uid, sid, ... and real world 'objects'. So, it depends a bit on how the requirements are, but to me it looks like all generic solutions will unfortunately not really meet our requirements. >> - While most of the struts actions are RhnAction or RhnLookupDispatchAction, >> there is still some that are not derived from these classes. Therefore it's >> not enough to put a shortcut method to the logger in the(se) >> superclass(es). > > Exactly, if you go from bottom (base classes) you can be never sure if > log all childs and getting the big picture will be very hard. And you > could not be really sure till you test it. It's supposed to be done in the superclass, this is just a shortcut for making it easier to put the calls in the derived classes where 'interesting' things (mostly calls to whatever *Manager class) are actually happening. I agree with you completely on the fact that getting the big picture is hard, but generic logging of request data does somehow not satisfy our needs :-/ -- SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
