How should audit hook persist data?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How should audit hook persist data?

jewzaam
Administrator
I've landed on a decision to have data persisted via lightblue CRUD, but I'm hitting a point where I can see pains with doing it.  There are two options I see:
1) Call REST API from the audit hook implementation.
2) Access the crud mediator and directly persist from the audit hook impl.

Both will require the principal for the audit hook to be authorized, but option #1 requires more work for authentication.  But #2 is a dirty dirty hack.  And #2 will mean doing some hack around ClientIdentification since there won't be any http servlet request.

Is there any other options?  This hook will run on the same JVM the rest services are on so it wouldn't be creating a new mediator.  The configuration is sort of split out from the REST bits, but it's in the same module and shares the 'rest' packaging.

I can't help but think #1 is the way to do it.  Guess even with the authentication the call could be configured to hit whatever instance we want: local, load balancer, or remote.
Reply | Threaded
Open this post in threaded view
|

Re: How should audit hook persist data?

bserdar

There is a third way. Bypass mediator, get crud controller and persist with it. It bypasses all field validations and you can clone the operation context and change parts of it as necessary.

On Aug 29, 2014 2:56 PM, "jewzaam [via lightblue-dev]" <[hidden email]> wrote:
I've landed on a decision to have data persisted via lightblue CRUD, but I'm hitting a point where I can see pains with doing it.  There are two options I see:
1) Call REST API from the audit hook implementation.
2) Access the crud mediator and directly persist from the audit hook impl.

Both will require the principal for the audit hook to be authorized, but option #1 requires more work for authentication.  But #2 is a dirty dirty hack.  And #2 will mean doing some hack around ClientIdentification since there won't be any http servlet request.

Is there any other options?  This hook will run on the same JVM the rest services are on so it wouldn't be creating a new mediator.  The configuration is sort of split out from the REST bits, but it's in the same module and shares the 'rest' packaging.

I can't help but think #1 is the way to do it.  Guess even with the authentication the call could be configured to hit whatever instance we want: local, load balancer, or remote.


If you reply to this email, your message will be added to the discussion below:
http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: How should audit hook persist data?

jewzaam
Administrator

Which option do you recommend? Is there a risk for future hook developers to think bypassing and hacks are OK?

On Aug 29, 2014 10:44 PM, "bserdar [via lightblue-dev]" <[hidden email]> wrote:

There is a third way. Bypass mediator, get crud controller and persist with it. It bypasses all field validations and you can clone the operation context and change parts of it as necessary.

On Aug 29, 2014 2:56 PM, "jewzaam [via lightblue-dev]" <[hidden email]> wrote:
I've landed on a decision to have data persisted via lightblue CRUD, but I'm hitting a point where I can see pains with doing it.  There are two options I see:
1) Call REST API from the audit hook implementation.
2) Access the crud mediator and directly persist from the audit hook impl.

Both will require the principal for the audit hook to be authorized, but option #1 requires more work for authentication.  But #2 is a dirty dirty hack.  And #2 will mean doing some hack around ClientIdentification since there won't be any http servlet request.

Is there any other options?  This hook will run on the same JVM the rest services are on so it wouldn't be creating a new mediator.  The configuration is sort of split out from the REST bits, but it's in the same module and shares the 'rest' packaging.

I can't help but think #1 is the way to do it.  Guess even with the authentication the call could be configured to hit whatever instance we want: local, load balancer, or remote.


If you reply to this email, your message will be added to the discussion below:
http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML



If you reply to this email, your message will be added to the discussion below:
http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123p125.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: How should audit hook persist data?

bserdar
Using CRUD directly isn't a hack. It has a public API, well defined
ways of retrieving it, and provides a coherent front-end to a
particular back-end. So, I think calling CRUD directly would be a good
choice. Calling the REST API from the audit hook has the potential to
make the call async, but I think it has too much overhead. I'd call
CRUD directly. I don't have a strong opinion either way, but I think
CRUD is the simplest approach with minimal overhead.

On Sat, Aug 30, 2014 at 5:52 AM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> Which option do you recommend? Is there a risk for future hook developers to
> think bypassing and hacks are OK?
>
> On Aug 29, 2014 10:44 PM, "bserdar [via lightblue-dev]" <[hidden email]>
> wrote:
>>
>> There is a third way. Bypass mediator, get crud controller and persist
>> with it. It bypasses all field validations and you can clone the operation
>> context and change parts of it as necessary.
>>
>> On Aug 29, 2014 2:56 PM, "jewzaam [via lightblue-dev]" <[hidden email]>
>> wrote:
>>>
>>> I've landed on a decision to have data persisted via lightblue CRUD, but
>>> I'm hitting a point where I can see pains with doing it.  There are two
>>> options I see:
>>> 1) Call REST API from the audit hook implementation.
>>> 2) Access the crud mediator and directly persist from the audit hook
>>> impl.
>>>
>>> Both will require the principal for the audit hook to be authorized, but
>>> option #1 requires more work for authentication.  But #2 is a dirty dirty
>>> hack.  And #2 will mean doing some hack around ClientIdentification since
>>> there won't be any http servlet request.
>>>
>>> Is there any other options?  This hook will run on the same JVM the rest
>>> services are on so it wouldn't be creating a new mediator.  The
>>> configuration is sort of split out from the REST bits, but it's in the same
>>> module and shares the 'rest' packaging.
>>>
>>> I can't help but think #1 is the way to do it.  Guess even with the
>>> authentication the call could be configured to hit whatever instance we
>>> want: local, load balancer, or remote.
>>>
>>> ________________________________
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123.html
>>> To start a new topic under lightblue-dev, email [hidden email]
>>> To unsubscribe from lightblue-dev, click here.
>>> NAML
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123p125.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/How-should-audit-hook-persist-data-tp123p126.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: How should audit hook persist data?

jewzaam
Administrator
I went with getting the Mediator instance and setting ClientIdentification such that it's always authorized.

audit-hook PR: https://github.com/lightblue-platform/lightblue-audit-hook/pull/7

This PR is dependent on a change in lightblue-mongo, creation of module mongo-test.
PR for mongo-test:  https://github.com/lightblue-platform/lightblue-mongo/pull/9

Anybody have time to review the mongo one?  Then we can force rebuild of the audit hook, cause the dependency doesn't exist on sonatype yet...
Reply | Threaded
Open this post in threaded view
|

Re: How should audit hook persist data?

jewzaam
Administrator