Improve hook mechanism

[mcweba]

The current implementation of the hook mechanism is often used and turns out to be reliable. However, there are a few issues which are not optimal and should be improved

Hook API

To add a listener hook for example, a PUT request to the desired hook URL with an additional _hooks/listeners/... suffix has to be made.
Example:

PUT http://myserver:7012/gateleen/everything/_hooks/listeners/http/myexample
{
    "methods": [
        "PUT"
    ],
    "destination": "/gateleen/example/thePosition",
    "filter": "/gateleen/everything/.*/position.*",
    "headers": [
        { "header":"X-Expire-After", "value":"3600", mode:"complete"}
    ]    
}

Problem

Let's say that client A should have read access to /gateleen/everything. In order for client A to add a listener hook, also write access to /gateleen/everything is required, because the listener hook has to be added trough a PUT request to /gateleen/everything/_hooks/listeners/http/myexample.

Certainly, this is not wanted and should be changed.

Solution

Provide a designated hook API for the hook management. This api could have a common prefix for all hook management related operations. For example this prefix could be /gateleen/hooks/

Having a designated hook API would require a client to only have write (PUT) access to the hook API and not to all urls to hook to.

Add a hook
To add a hook, the request could look like this:

 PUT http://myserver:7012/gateleen/hooks/myUniqueHookId
{
    "methods": [
        "PUT"
    ],
    "hookUrl": "/gateleen/everything",
    "destination": "/gateleen/example/thePosition",
    "filter": "/gateleen/everything/.*/position.*",
    "headers": [
        { "header":"X-Expire-After", "value":"3600", mode:"complete"}
    ]    
}

Delete a hook
To delete a hook, the request could look like this:

 DELETE http://myserver:7012/gateleen/hooks/myUniqueHookId

Get hooks
To find hooks it could be useful to allow url parameters. Example:

 GET http://myserver:7012/gateleen/hooks?destination=/gateleen/example/thePosition

Note: This is just an idea and has to be given another thought. The thing is, that we are sometimes have a hard time finding specific hooks because we just can get all hooks and then have to perform a text search on the hook names.

Static listener hooks

The current limitation of not having the possibility to provide static listener hook resources leads to projects having a huge scheduler configuration where the listener hooks are refreshed (re-added) periodically.

It would be useful to define static listener hook resources, because listener hooks which have to be updated (or re-added) periodically are in fact static.
When using the scheduler approach, there's also a small problem where the scheduler entries are processed with a delay on server startup. This can lead to a short time right after server startup where already requests arrive, but the hooks are not yet ready.

Please add your thoughts and additional ideas in the comments.
Thank you

[lbovet]

Could you make two issues. Both topics (hook path and static listeners) are orthogonal.

About static listeners. Yes, we should have persistent hooks that do not require the scheduler configuration overhead.

About the hook path. In fact, the way it is designed now was precisely to allow fine tuning of the access rights.
You can actually allow placing hooks without granting write on the resource. The ACL pattern would be /gateleen/.*/_hooks/listeners/http/.*.
If we don't have the resource URL in the hook URL, we cannot use the usual ACL mechanism for granting access to specific hooks. Then we could not distinguish granting read and granting placing hooks without a special handling.
About searching hooks, I agree that it would be useful to have this possibility. This point is also orthogonal and could be realized without changing the hook path structure.

[mcweba]

You are right, the write granting can be realized with specific ACL patterns as you have shown. When I get your comment right, you do not see any advantage in changing the hook path structure?

So we could make two issues:

1. Add static listener hooks. (what about static route hooks?)
2. Provide API access for improved hook searching

[lbovet]

Yep, that's what I meant. And yes, these two issues make sense.

[mcweba]

OK, I will create these issues. Tx

[mcweba]

Created #310 and #311