Order in which Plugins are executed

[shashiranjan84]

We need a better way than having a PRIORITY constant in a plugin's handler to decide the order of execution of the plugins. As the number of plugins grow, it's not intuitive.

More appropriate would be putting the order in the configuration.

[subnetmarco]

I agree. As the number of plugins grows it's hard to define what PRIORITY each plugin should have.

Having the order in the configuration is an option: plugins will be executed accordingly to their order in the available_plugins property in the configuration. But it's not bulletproof, because I am pretty sure users will add plugins to the array pretty randomly.

Another option would be to sit down and look at the use cases that we have, and introduce some triggers in the lifecycle of the request, like:

• access.before_authentication
• access.on_request_preconditions
• access.before_proxy

Etc

[thibaultcha]

Another link to #505 when redesigning the Model.

[jdarling]

Hopefully this is still up for debate, but it seems to me that having some type of endpoints like /order/plugins and /order/apis/plugins or similar that returned and accepted an ordered list of plugins provides the best flexibility. This would allow the user to control the flow through plugins, and by default could be autosorted on the PRIORITY.

[ernsheong]

As it currently stands, what is the plugin order? Undefined?

Edit: Sorry, here it is https://getkong.org/docs/0.11.x/plugin-development/custom-logic/

I'd say maybe a custom priority field for each plugin to override current the PRIORITY field would suffice, and an API retrieve the plugins in priority order might make sense.

[macedogm]

On Thu, 31 Aug 2017 05:23:55 -0700 Jonathan ES Lin ***@***.***> wrote: As it currently stands, what is the plugin order? Undefined?

Hi Jonathan. The plugin execution/priority order is defined here - https://getkong.org/docs/0.11.x/plugin-development/custom-logic/#plugins-execution-order . Best regards. Guilherme Macedo -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[philbarr]

Any more news on this issue? Being able to set priority order when applying the plugin would be great.
I would really like to be able to do something like this:

curl -X POST http://kong:8001/services/myservice/plugins \
    --data "name=myplugin" \
    --data "priority=1000"

As it stands the only way to change priority is to fork the plugin and change it manually (as far as I am aware anyway).

[samwonwyd]

If two plugins's phases and priority are same, which one will be executed first?

[thibaultcha]

@samwonwyd In this case the order is (was) undefined.

[bungle]

@samwonwyd it is not undefined, it is sorted by plugin created_at.

[julianguinard]

Any update on this issue? Being allowed to easily change the plugins priorities would be greatly appreciated, as it would allow us to avoid forking a plugin just to change the PRIORITY constant value. In my case I would set the rate-limiting plugin priority higher than basic-Auth for instance, as the Current order prevents rate limiting protection against password bruteforce attackers

[rucciva]

Just wondering, if any change to the plugin order be made, is it also possible to have a plugin executed more than once? for example applying rate-limit to route and route+consumer, to make sure that the route will serve max 100 tps but a certain consumer can only get max 10 tps on that route. I'm also thinking that this will benefit scripting-like plugin, maybe when we need to add some generic processing to a route but add some custom processing for a certain consumer without losing the generic processing done on the route.

[julianguinard]

In the end I ended up with the following steps in order to adress this issue :

• write a Dockerfile starting FROM kong:2.0.4 in which rate-limiting is copied as rate-limiting-1999-priority, and the latter's handler.lua has a RateLimitingHandler.PRIORITY = 1999 rather than 901, which is the initial priority for rate-limiting

• run my kong containers using that forked image and passing them KONG_PLUGINS=bundled,rate-limiting-1999-priority environment variable

• use rate-limiting-1999-priority, which runs directly after CORS plugin and before any Auth plugin, when I need to limit rates by IP, and original rate-limiting for others services/routes for which I want to limit by any other entity (consumer, credentual or service)

I will stay tuned for this issue in case there is a cleaner, config-driven way to do this

[ozonni]

this is insane that this issue is still opened after 6 years. I have very standard flow, i wanna rate limit based on header that i build in request transformation plugin. Is it really unique what i'm doing here? But i can't do that cause rate limiting happens before request transformation.

[Tieske]

This request is, as simple as it might seem, a very complex one to implement. It is still on the radar however.

Meanwhile this can be used as a workaround: https://github.com/Kong/priority-updater

ping @brycehemme

[yaduvesh]

we have a similar problem wherein we wanted to rate-limit the kong authentication calls so that callers do not misuse the oauth process itself. We use a double-hop approach for the auth request so that first hop acts as the rate limiter and the second hop acts as the oauth generator. Described here.