Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Emily Eisbruch <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09
  • Date: Wed, 4 Feb 2009 16:56:19 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

At this point here are my issues regarding auditing, transactions, and context ids:

 

1.       I have the tables created and hibernated for user-auditing.  The cols (maybe not all, but a good sample), are here under audit type table, and audit entry table.  Let me know if something doesn’t look ok

https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing

2.       For the user auditing and context ids, I need some threadlocal space to keep the id and if the caller is auditing (if so, inner calls shouldn’t audit, if not, inner calls should audit).  I want to use the hibernateSession transaction callbacks (natural place for it since the auditing needs to be in a transaction anyways).  Here are the changes required for people using the callbacks (shouldn’t be many).  We also have a GrouperTransaction callback that I could also expose this to:

FROM:
public Object callback(HibernateSession hibernateSession) {

 

TO (hibernate handler bean will tell you if caller is auditing, give you context id, etc):

public Object callback(HibernateHandlerBean hibernateHandlerBean)

    throws GrouperDAOException {

  HibernateSession hibernateSession = hibernateHandlerBean.getHibernateSession();

 

FROM:

HibernateSession.callbackHibernateSession(GrouperTransactionType.READ_WRITE_OR_USE_EXISTING, new HibernateHandler()

 

TO (false means caller is not auditing, so inner calls should, true would be opposite):
HibernateSession.callbackHibernateSession(GrouperTransactionType.READ_WRITE_OR_USE_EXISTING, false, new HibernateHandler()

Note: If there is a case where the outer transaction doesn’t need a contextId, then we need another param or an overload or something…  GSH transactions might be a reason, but GSH transactions are different and wont get contextid’s anyways

 

3.       I think we should drop the created_by and modified_by cols in the grouper tables (e.g. grouper_groups and grouper_stems), since these will be maintained in the user auditing.  The user auditing will tell you who the logged_in user is, who the act_as user is, etc.  I think the created_by and modified_by is just who the grouperSession belongs to, so it might even be meaningless.  Does anyone use these, or does anyone object?  Oh yeah, I need to update those in memberChangeSubject calls potentially when merging subjects…

4.       Speaking of, I want to use member_uuid for the created_by and modified_by in the audit record.  Is it a reasonable assumption that everyone logging in to the UI or WS is a subject resolvable by subjectId or subjectIdentifier???  If they don’t have a grouper_members record, I will add them.

5.       I think we can drop the loader log table and use the audit log table instead.  Would anyone be sad about that decision.  I picture having web services to query the logs, and the UI potentially, so if there were fewer tables, then we would get that functionality in all of the logs

6.       I have everything working for a group type add to do the user auditing correctly.  It has been pretty time consuming, more than I originally thought, so bear with me, but it will take some time to crank this out for all grouper operations (similar to hooks).

 

Thanks,

Chris

 

 

 

From: Emily Eisbruch [mailto:]
Sent: Wednesday, February 04, 2009 3:59 PM
To: Grouper Dev
Subject: [grouper-dev] Action Items: Grouper Call 4-Feb-09

 

New Action Items

 

[AI] (Everyone) will send to the list ideas on DB tables & triggers for audit / notification / as complete solutions / as infrastructure.

https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing

 

[AI] (Chris) will email the group regarding auditing, transactions, and context IDs.

 

Carry Over Action Items

 

[AI] TomZ will send to the list a summary of the strands in the group's discussion on notification.

 

 

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1734-352-4996 | mobile +1-734-730-5749

 

Spring 2009 Internet2 Member Meeting

April 27-29, Arlington, Virginia

events.internet2.edu/2009/spring-mm/

 

 

 

 




Archive powered by MHonArc 2.6.16.

Top of Page