Audit Logs being associated with the wrong actor

[jonnyhoffer]

Hi,

I'm using this plugin with a Grails 4 project, and we're running into issues with some (~1.5%) records being attributed to the wrong actor. I've posted a question on stack overflow, but haven't gotten much traction from it, so I wanted to check here as well.

Most of these records are actions done by methods called from event listeners. It appears that Hibernate may be piggy-backing the actions that are done by the subscriber onto another active session and incorrectly attributing the actor. Is that possible? This has been tricky to debug since most of the records are being correctly saved.

I'm happy to provide more info as needed to help solve this.

Thanks!
Jonathan

[felixscheinost]

Hi, I remember that we had a problem with the principal being wrong occassionally because of the SecurityContextHolder strategy being MODE_INHERITABLETHREADLOCAL. They changed the default in Grails Spring Security Plugin version 3.2.1

See grails/grails-spring-security-core#587

Have you changed the strategy by chance?

[felixscheinost]

Sorry, to clarify: The default between 3.2.1 up to 4.0.1 has been MODE_INHERITABLETHREADLOCAL. It was changed back to the secure MODE_THREADLOCAL in 4.0.1.

So the questions are:

• On which version of the Grails Spring security plugin are you?
• Have you changed the strategy?

I think the drawback is that in newly created threads you manually have to set the context. If I remember correctly we worked around it by including the principal in the event and then in the event listener explicitly setting this principal in the security context.

[jonnyhoffer]

Hi,

I really appreciate the response! We haven't changed the strategy, and we're using spring-security-rest:3.0.0.RC1, which has spring-security-core:4.0.0.M2 as a transitive dependency.

Just to make sure I'm understanding, if I switch spring-security-core to 4.0.1 (which uses MODE_THREADLOCAL), will we have to set the principal in each event and event listener in the application? Or was that simply the workaround while using versions that had MODE_INHERITABLETHREADLOCAL?

EDIT: I've updated the dependency:

compile ("org.grails.plugins:spring-security-rest:3.0.0.RC1") {
        exclude group: "org.grails.plugins:spring-security-core:4.0.0.M2"
    }
compile "org.grails.plugins:spring-security-core:4.0.1"

After refreshing Gradle, the strategy name for SecurityContextHolder is MODE_THREADLOCAL now! I'll start testing to see if we can reproduce the issue after the change.

Thanks,
Jonathan

[jonnyhoffer]

Hi Felix, this ended up fixing it! Thank you so much for the help on this one. We really appreciate it!