Skip to content

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

Closed
spring-projects-issues opened this issue Nov 1, 2020 · 4 comments · Fixed by #1102
Closed

Add @EnableReactiveCouchbaseAuditing [DATACOUCH-644] #955

spring-projects-issues opened this issue Nov 1, 2020 · 4 comments · Fixed by #1102
Assignees
Labels
in: core Issues in core support type: bug A general bug

Comments

@spring-projects-issues
Copy link

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 it


Affects: 4.1 GA (2020.0.0)

Reference URL: https://github.com/hantsy/spring-reactive-sample/tree/master/boot-data-couchbase

@jorgerod
Copy link
Contributor

jorgerod commented Mar 5, 2021

Hi

What is the status of this issue?
I could try to contribute.

@mikereiche
Copy link
Collaborator

@jorgerod - auditing can be enabled with EnableAuditorAware . It is for both reactive and non-reactive operations. Let me know if more is required

@jorgerod
Copy link
Contributor

jorgerod commented Mar 5, 2021

Hi @mikereiche

I think it would be useful to be able to use org.springframework.data.domain.ReactiveAuditorAware, like spring-data-mongo does.

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?

@mikereiche
Copy link
Collaborator

@jorgerod if you make a pull-request, I'll submit it.

mikereiche added a commit that referenced this issue Apr 6, 2021
…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]>
mikereiche added a commit that referenced this issue Apr 6, 2021
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]>
mikereiche added a commit that referenced this issue Apr 6, 2021
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]>
mikereiche added a commit that referenced this issue May 28, 2021
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.
mikereiche added a commit that referenced this issue Jun 2, 2021
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.
mikereiche added a commit that referenced this issue Jun 8, 2021
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.
mikereiche added a commit that referenced this issue Jun 8, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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.
mikereiche added a commit that referenced this issue Jun 10, 2021
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]>
mikereiche added a commit that referenced this issue Aug 9, 2021
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core support type: bug A general bug
Projects
None yet
3 participants