Hook / Event System

[nijikokun]

Would provide an ample and powerful solution to many outstanding issues including #682 and #338 by having hooks / events that plugins can register functions on for listening or actionable purposes.

Hook Examples

• PLUGIN_ENABLED
• PLUGIN_DISABLED
• PLUGIN_DELETED
• API_CREATED
• API_DELETED
• API_UPDATED
• CONSUMER_...
• PROVISION
• etc...

Effectively allowing plugins to do actions throughout kong, without kong being aware of the plugins existence or calling the plugin directly.

Some Use Cases

• [request] Audit Logging #338 (audit plugin) would just attach to all events and register the information as a log. done.
• Admin API should have a "provisioning" endpoint #682 (provisioning endpoint) each authentication plugin registers a provision function and handles the data passed accordingly to provision credentials.

These are just two, but there are countless more, even the #640 (slack integration) would benefit from hooks.

---

[Tieske]

this might help; https://github.com/Olivine-Labs/mediator_lua

[thibaultcha]

I'd say it looks overly complex for the very simple goal we are trying to achieve here. We simply want a hash table with keys being the event ids, and values being arrays containing functions to execute on a given key.

I can see a simple Lua module doing the job here.

[Tieske]

I see what you mean. But in my experience, the simple module will quickly get a few feature requests and then ends up being a copy of an existing, fancier, module. It all depends on how confident you are that it stays "simple".

Also; this module is only 160 lines (126 sloc),

[thibaultcha]

Yes you're right. We should consider it as an implementation. We would need some sort of wrapper around it though.

[nijikokun]

I think this needs some clarification that wasn't specified, this is not simply an event bus.

Its Hooking, hooks can modify the result and return it.

Essentially it's a place in code that allows you to tap in to either provide different behavior (invoked callback methods that return the same or different results in sequence) or to react when something happens (this would be the event bus currently in #729).

[Tieske]

There are many ways to do roughly the same thing. I think an important distinction here is whether the event handler (or hook) is trusted or not. If it's trusted, pass the full set of data along and let the handler decide whether or not to modify it (usually it will be tables, which are passed by reference anyway).

But if the code is not trusted, only a minimum set of data should be passed (by value, not by reference), and any results should be validated and copied back. Performance wise this is a tough one, considering deep copying of tables etc.

The first approach is far simpler of course... but because it is security related it is a rather fundamental choice.

[nijikokun]

I don't think we should waste our time with the minimum set of data / copy mechanism, since the administrator of Kong would most likely only add officially supported by Kong or self-made plugins. I think this was a discussion previously brought up on plugins when separating them out and it is not really our concern.

Obviously if you add a plugin that isn't officially supported you are taking a risk on your behalf, we are not liable for this security wise, it is your own responsibility to verify and vet that before installing said plugin on your instances.

---

From another angle, let's say it's a medical enterprise business and they want to process their information, I don't think they would enable something that logs to the cloud for their health-care information and should they want to do this, they would split up their apis, or utilize sort of a plugin enabling mechanism that is in discussion (there are many ways to mitigate having that information pipe through such plugins)

[Tieske]

It comes down to what your security philosophy is. So I guess it comes down to making a choice (Kong wide), document it, stick with it.

Anyway, my personal opinion is that I would leave it to the admin as to which plugins he/she wants to install. The complexity and performance hit will probably not be worth it.

[Tieske]

So far for off-topic. On the event bus itself; the picture just registers callbacks for kong events (single producer, multiple consumer, hardly a bus).

Could it be useful to have any component register its own events (multi producer, multi consumer)? for example; a logger that subscribes to authentication events.

[nijikokun]

Anyway, my personal opinion is that I would leave it to the admin as to which plugins he/she wants to install. The complexity and performance hit will probably not be worth it.

👍

Could it be useful to have any component register its own events (multi producer, multi consumer)? for example; a logger that subscribes to authentication events.

If you pass along the hook mechanisms in the new ngx.ctx and kong.core (#709) (attach / create) then I wouldn't see why a plugin couldn't have them (in fact I would expect some to create their own so other plugins could also hook into them -- auditing plugin, etc)

[Tieske]

Couldn't the event/hook system also resolve #267? (provided the hook mechanism is passed along to enable multi-producer/multi-consumer setups)

[thibaultcha]

In 0.6.0 too.