Add infrastructure for reactive auditing [DATACMNS-1231]

[spring-projects-issues]

Jocelyn Ntakpe opened DATACMNS-1231 and commented

AuditorAware currently doesn't support any way to retrieve user. Since SecurityContext is not available, AuditorAware should provide a way to pass ReactiveSecurityContext for instance using Mono.subscriberContext

---

Issue Links:

• DATACMNS-1467 Add API for entity callbacks/change before save/after load
  ("depends on")
• DATAMONGO-2586 Add support for reactive auditing
  ("is depended on by")
• DATACASS-784 Add support for reactive auditing
  ("is depended on by")
• DATAES-886 Complete reactive auditing
  ("is depended on by")

Referenced from: pull request #458

11 votes, 14 watchers

[spring-projects-issues]

Mark Paluch commented

Auditing for imperative data access is different than auditing could work for reactive usage because of the way how we propagate contexts (like SecurityContext). Imperative auditing can be backed with a thread-local storage of the auditor. For reactive usage, we do not have thread affinity but the context is bound to the actual subscription which happens on a per-call (per-subscription) basis.

All involved components need to integrate with the changed context passing mechanism. The current implementation is based (for e.g. MongoDB) on a listener (AuditingEventListener) that operates on a bean (AuditingHandler/IsNewAwareAuditingHandler) registered and configured through a context. We can't reconfigure the auditing handler bean otherwise we would affect other concurrent processes.

That said, we need to change auditing for reactive use and it might be we need to provide a separate implementation for auditing

[spring-projects-issues]

Scott White commented

Mark Paluch Could you confirm that this breaks audit user functionality (AuditorAware) for reactive endpoints. Also are there any workarounds for this?

[spring-projects-issues]

maresja1 commented

Mark Paluch the same question here, is there a way to use AuditorAware for webflux without this issue resolved? If not, when is this issue going to be addressed? The last update is adding blocking issue, which is resolved now. Thank you,

[spring-projects-issues]

Mark Paluch commented

We don't have a reactive implementation for AuditorAware yet because the current implementation assumes Thread-Local transport of the security context and the bean is entirely configured by the application container.

For reactive auditing, we need to rethink how auditing is implemented and likely entirely rewrite the auditing implementation. You can implement auditing somewhat yourself as we have laid a reactive foundation with EntityCallbacks. For a reactive security context integrations, all calling paths must participate in returning Publisher and implementations (e.g. SpEL extensions) must provide an API to associate a reactive context with them without requiring reactive APIs for imperative usage.

That being said, it's a fair amount of work to make these things work

[spring-projects-issues]

Lee commented

Related discussion, assuming potential use of Future as one solution:

spring-projects/spring-security#5690