I'm starting to wonder if the root of the problem is that the username does indeed get lost. Note that when I remove the auditTrailContext.xml file, the AuditTrailManagementAspect problem goes away, but I end up with credentials in my AuthenticationHandler that are empty. In this particular case, fixing that might make the auditor happy. ?
From: Scott Battaglia [mailto:[email protected]] Sent: Thursday, June 09, 2011 10:47 AM To: [email protected] Subject: Re: [cas-user] Causing CAS to make a REST call at each auth attempt The API says you MUST never throw an exception unless you want it to stop the transaction: https://github.com/dima767/inspektr/blob/master/inspektr-common/src/main/java/com/github/inspektr/common/spi/PrincipalResolver.java Since its an Audit Trail, the assumption is you let us know you couldn't determine the user, rather than us trying to discern that from an empty string, thrown exception, etc. On Thu, Jun 9, 2011 at 11:38 AM, Marvin Addison <[email protected]<mailto:[email protected]>> wrote: > Is this the issue that was opened? The following looks very close but not exactly what I've seen or described above. https://github.com/dima767/inspektr/issues/8 What we've seen here at VT happens in AuditTrailManagementAspect#handleAuditTrail() when the following throws: currentPrincipal = this.auditPrincipalResolver.resolveFrom(joinPoint, retVal) which causes the following to execute in the catch block: currentPrincipal = this.auditPrincipalResolver.resolveFrom(joinPoint, e) We have a custom resolver that may also throw there as well, leaving currentPrincipal uninitialized when executeAutiCode runs in the finally block. Both this case and the one above are very similar in that the *Aspects need to guarantee that required variables are initialized in all cases. I suppose the initial assumption was that resolvers are simple and shouldn't throw, but we use ones that do LDAP queries to map a meaningless integer onto a principal name for X.509 auth to provide something meaningful for the audit trail. I think it's reasonable to guard against that assumption since the audit machinery fails in a pretty ugly way at present. M -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
