Unable to properly PATCH a plugin

1

Hello everyone!

I’m not creating an issue on GitHub as I know that a lot of things will change with the 1.0 around that (and maybe with the 0.15 ??), but looking to the way the plugins are implemented right now, there is a high chance that running a PATCH on a plugin will not result in what you are expecting, or at least for the ACL, IP Restriction, JWT, OAuth2 and Respone Rate Limiting plugins.

This is mainly due to the fact that the plugin’s schema.lua is running the self_check function that may perform some consistency checks between the parameters. To do these checks, the config input data is used.

When creating a plugin with PUT or POST, this config variable contains the whole set of data that have been provided in the curl command line, plus the default values for the others (if defined): check can be performed correctly.

But when a PATCH is done, config only contains the very specific configuration data specified in the curl command line (the ones to be “patched”), and not the values for the other parameters (the one that are not touched), so that it is not possible to perform the checks that may involve 2 parameters: one to be patched and one not patched.
I suppose that the dao input data of self_check should then be used in order to retrieve the plugin configuration in the DB, and then a correct verification can be done by mixing the patched parameters and the non-patched parameters extracted from the DB… but none of the schema.lua of the plugins bundled in Kong are currently implementing this behavior :stuck_out_tongue:

The problem has been raised several times, without a clear identification of the issue:

So this post is only for information to anyone looking for this problem.

2

@pamiel Hi,

Yes, this is correct. And as you said in the beginning of your message, this is indeed changing with 1.0 (and 0.15). In fact, the Services and Routes entities introduced in 0.13 were implemented with a new DAO and Admin API layer (attentive readers will remember mentions of this in the Changelog).

In this new DAO module, one is able to specify which parameters should be given together to perform validation, and PATCH will produce an error if none (or some) of these parameters are missing. We call these “entity checkers”. An example of this can be seen in the Routes schema, which requires that at least one of the routing properties be given. The key improvement here was to specify those rules in a declarative fashion, instead of implementing validation logic inside of an arbitrary function (which the Admin API had no idea what the said function was doing).

In 1.0 (and 0.15) all entities are migrated to the new DAO/Admin API, and will be able to leverage these new entity checkers, including plugins (granted they update their schema.lua definitions).

1 Like