-
Notifications
You must be signed in to change notification settings - Fork 192
Add @EnableReactiveCouchbaseAuditing [DATACOUCH-644] #955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi What is the status of this issue? |
@jorgerod - auditing can be enabled with EnableAuditorAware . It is for both reactive and non-reactive operations. Let me know if more is required |
Hi @mikereiche I think it would be useful to be able to use Specifically, I want to make a ReactiveAuditorAware to audit the spring-security user that is obtained from ReactiveSecurityContextHolder which in a reactive application is a Mono. Sample public class ReactiveSecurityCouchbaseAuditorAware implements ReactiveAuditorAware {
@Override
public Mono<String> getCurrentAuditor() {
return ReactiveSecurityContextHolder.getContext()
.map(securityContext -> securityContext.getAuthentication().getName());
}
} What do you think? |
@jorgerod if you make a pull-request, I'll submit it. |
…allbacks. Add support for reactive auditing and ReactiveEntityCallbacks. Also, adapt CouchbaseAuditingRegistrar for support AuditingEntityCallback. Closes #955. Original pull request: #1102. Co-authored-by: Carlos Espinado <carlosemart> Co-authored-by: mikereiche <[email protected]>
Add support for reactive auditing and ReactiveEntityCallbacks. Also, adapt CouchbaseAuditingRegistrar for support AuditingEntityCallback. Closes #955. Original pull request: #1102. Co-authored-by: Carlos Espinado <carlosemart> Co-authored-by: mikereiche <[email protected]>
Add support for reactive auditing and ReactiveEntityCallbacks. Also, adapt CouchbaseAuditingRegistrar for support AuditingEntityCallback. Closes #955. Original pull request: #1102. Co-authored-by: Carlos Espinado <carlosemart> Co-authored-by: mikereiche <[email protected]>
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) The two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. EventListener is intendended to be read-only, therefore EntityCallback is necessary and should be used for modifying operations such as markAudited which modifies @createdby, @CreatedDate, @LastModifiedBy, @LostModifiedDate. Eventually EventListener will be deprecated. 3) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074.
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074. Co-authored-by: mikereiche <[email protected]>
1) the previous change (#955) to CouchbaseAuditingRegister intended to register AuditingEntityCallback instead of AuditingEventListener but only changed the name that AuditingEventListener was registered with. Since AuditingEventListener does exactly the same thing as AuditingEntityCallback, it behaved as those AuditingEntityCallback was being used. 2) It seems that the two mechanisms - EntityCallback and EventListener both do more-or-less the same thing. I'm not sure why there are two mechanisms to do the same thing. 3) Although the ReactiveAuditingEntityCallback mechanism is triggered only for reactive operations and the non-reactive AuditingEntityCallback is triggered only for non-reactive operations, the events are triggered for both. Since there was a desire to have distinct callbacks for reactive/non-reactive operations, I also made distinct events for reactive/non-reactive operations. However both the reactive and non-reactive event mechanisms are triggered for either reactive and non-reactive operations, so it is necessary for the mechanism to determine if it should act on the event. 4) Although there is an AbstractCouchbaseEventListener that is extended by LoggingEventListener and ValidatingEventListener, AuditingEventListener does not extend it (maybe it should). Closes #1074. Co-authored-by: mikereiche <[email protected]>
hantsy opened DATACOUCH-644 and commented
In this new Spring Data commons, there is a new ReactiveAuitorAware added for reactive stack.
The R2dbc, Mongo, Neo4j, etc had added a variant to enable this support.
Suggest use
@EnableReactiveCouchbaseAuditing
to enable itAffects: 4.1 GA (2020.0.0)
Reference URL: https://github.com/hantsy/spring-reactive-sample/tree/master/boot-data-couchbase
The text was updated successfully, but these errors were encountered: