Re: Audit trail - implementation strategies
Well, I'm using Hibernate for persistance, so I guess the implementation would be somehow different. Nevertheless, I'm looking at this solution. For my understanding, with this approach you monitor the CRUD transactions (via JPA/Toplink features) and audit each CRUD event individually, correct? Brian Trzupek wrote: > > We just did the very same thing. Here is how we did it > > We are using JPA/Toplink for our database layer, so our > implementation is highly dependent on that. > > We then used an approach based on this blog entry: > http://tapestryofthoughts.blogspot.com/2007/05/glassfish-and-audit- > logging.html > > Our modification to his approach was (well his doesn't compile on our > version of Toplink , so we changed that): > 1) We implemented the PrincipalAware interface for our Action classes > so that we can use JAAS for authentication and pass the remote User > identity through to the Audit interface (in the Model) and know who > actually did the change. > 2) We incorporated a 'mode' for audit logging. We have things like > AUDIT (where that is a interface driven event, like approving > resource access AUDIT_APPROVE etc), VIEW (where that is another > interface driven event representing that a user 'saw' something) and > general field level CRUD operations on the core entities we wanted > audited. > 3) Then we implemented some specific rules where given AUDIT events > would trigger full field level audits (essentially serializing the > object) in the case where the rule trigger was an event that would > 'have historical significance'. > > I know it sounds a bit gnarly, but is VERY elegant and extensible. > Give it a whirl and let me know if you need any help. > > Thanks, > Brian- > > On Oct 25, 2007, at 1:35 PM, wild_oscar wrote: > >> >> I want to implement an audit trail in my application. Basically, I >> want to >> record every database change, in the form "previous value, new >> value, who >> changed it, when". >> >> I want to debate with you the best strategy in terms of >> minimization of data >> transfer between the browser and the server and server operations. >> >> The user accesses a page and gets data from the database on a form. He >> changes, say, one textfielnd and submits the form. >> >> We now need to see where changes occurred and record them, and >> therefore >> need the old values and new values. >> >> What do you think of different approaches to this problem? My >> current ideas >> are: >> >> 1) Resubmit the first query to get the "oldvalues" on the second >> submission >> and then compare with the new values. Problem I see is that we'll >> have one >> redundant query on each operation (first query to display values to >> the user >> and second query to get the old values again in the database). In >> large >> applications, between the 1st and 2nd queries data may have changed. >> >> 2) Have a hidden field for each value on the display form with the >> oldValue. >> Main problem I see is the increased workload on the jsp page - for >> each >> input field we need to manually have a hidden "oldValue" field... >> >> 3) Storing the oldObject in session right before the first display >> page. >> Workload increases in Session management, to wisely add and remove >> these >> objects from session. >> >> Can you share your ideas, point different approaches or suggest >> improvements >> on the ones I mentioned? >> >> -- >> View this message in context: http://www.nabble.com/Audit-trail--- >> implementation-strategies-tf4692772.html#a13413247 >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Audit-trail---implementation-strategies-tf4692772.html#a13423517 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Audit trail - implementation strategies
We just did the very same thing. Here is how we did it We are using JPA/Toplink for our database layer, so our implementation is highly dependent on that. We then used an approach based on this blog entry: http://tapestryofthoughts.blogspot.com/2007/05/glassfish-and-audit- logging.html Our modification to his approach was (well his doesn't compile on our version of Toplink , so we changed that): 1) We implemented the PrincipalAware interface for our Action classes so that we can use JAAS for authentication and pass the remote User identity through to the Audit interface (in the Model) and know who actually did the change. 2) We incorporated a 'mode' for audit logging. We have things like AUDIT (where that is a interface driven event, like approving resource access AUDIT_APPROVE etc), VIEW (where that is another interface driven event representing that a user 'saw' something) and general field level CRUD operations on the core entities we wanted audited. 3) Then we implemented some specific rules where given AUDIT events would trigger full field level audits (essentially serializing the object) in the case where the rule trigger was an event that would 'have historical significance'. I know it sounds a bit gnarly, but is VERY elegant and extensible. Give it a whirl and let me know if you need any help. Thanks, Brian- On Oct 25, 2007, at 1:35 PM, wild_oscar wrote: I want to implement an audit trail in my application. Basically, I want to record every database change, in the form "previous value, new value, who changed it, when". I want to debate with you the best strategy in terms of minimization of data transfer between the browser and the server and server operations. The user accesses a page and gets data from the database on a form. He changes, say, one textfielnd and submits the form. We now need to see where changes occurred and record them, and therefore need the old values and new values. What do you think of different approaches to this problem? My current ideas are: 1) Resubmit the first query to get the "oldvalues" on the second submission and then compare with the new values. Problem I see is that we'll have one redundant query on each operation (first query to display values to the user and second query to get the old values again in the database). In large applications, between the 1st and 2nd queries data may have changed. 2) Have a hidden field for each value on the display form with the oldValue. Main problem I see is the increased workload on the jsp page - for each input field we need to manually have a hidden "oldValue" field... 3) Storing the oldObject in session right before the first display page. Workload increases in Session management, to wisely add and remove these objects from session. Can you share your ideas, point different approaches or suggest improvements on the ones I mentioned? -- View this message in context: http://www.nabble.com/Audit-trail--- implementation-strategies-tf4692772.html#a13413247 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Audit trail - implementation strategies
As a matter of fact, I have implemented an audit trail solution with triggers in the past. I am trying to think of an alternative in the business layer now, although implementing it directly in the database is an option if I find this approach to be too troublesome. Rod Bollinger wrote: > > Depending on the DB you can implement this using triggers and log your > audit > trail directly in the DB itself. > > -Rod > > -Original Message- > From: wild_oscar [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 25, 2007 14:36 > To: user@struts.apache.org > Subject: Audit trail - implementation strategies > > > I want to implement an audit trail in my application. Basically, I want to > record every database change, in the form "previous value, new value, who > changed it, when". > > I want to debate with you the best strategy in terms of minimization of > data > transfer between the browser and the server and server operations. > > The user accesses a page and gets data from the database on a form. He > changes, say, one textfield and submits the form. > > We now need to see where changes occurred and record them, and therefore > need the old values and new values. > > What do you think of different approaches to this problem? My current > ideas > are: > > 1) Resubmit the first query to get the "oldvalues" on the second > submission > and then compare with the new values. Problem I see is that we'll have one > redundant query on each operation (first query to display values to the > user > and second query to get the old values again in the database). In large > applications, between the 1st and 2nd queries data may have changed. > > 2) Have a hidden field for each value on the display form with the > oldValue. > Main problem I see is the increased workload on the jsp page - for each > input field we need to manually have a hidden "oldValue" field... > > 3) Storing the oldObject in session right before the first display page. > Workload increases in Session management, to wisely add and remove these > objects from session. > > Can you share your ideas, point different approaches or suggest > improvements > on the ones I mentioned? > > -- > View this message in context: > http://www.nabble.com/Audit-trail---implementation-strategies-tf4692772.html > #a13413247 > Sent from the Struts - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Audit-trail---implementation-strategies-tf4692772.html#a13413561 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Audit trail - implementation strategies
Depending on the DB you can implement this using triggers and log your audit trail directly in the DB itself. -Rod -Original Message- From: wild_oscar [mailto:[EMAIL PROTECTED] Sent: Thursday, October 25, 2007 14:36 To: user@struts.apache.org Subject: Audit trail - implementation strategies I want to implement an audit trail in my application. Basically, I want to record every database change, in the form "previous value, new value, who changed it, when". I want to debate with you the best strategy in terms of minimization of data transfer between the browser and the server and server operations. The user accesses a page and gets data from the database on a form. He changes, say, one textfield and submits the form. We now need to see where changes occurred and record them, and therefore need the old values and new values. What do you think of different approaches to this problem? My current ideas are: 1) Resubmit the first query to get the "oldvalues" on the second submission and then compare with the new values. Problem I see is that we'll have one redundant query on each operation (first query to display values to the user and second query to get the old values again in the database). In large applications, between the 1st and 2nd queries data may have changed. 2) Have a hidden field for each value on the display form with the oldValue. Main problem I see is the increased workload on the jsp page - for each input field we need to manually have a hidden "oldValue" field... 3) Storing the oldObject in session right before the first display page. Workload increases in Session management, to wisely add and remove these objects from session. Can you share your ideas, point different approaches or suggest improvements on the ones I mentioned? -- View this message in context: http://www.nabble.com/Audit-trail---implementation-strategies-tf4692772.html #a13413247 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
