4

We are looking to override Kong error response structure and write custom messages (i.e. replace "API rate limit exceeded", "Invalid authentication credentials" and others with our custom messages).

The error response structure we are looking for (code is a custom internal error code, not related to HTTP code):

{
   "errors":[
       {
          "code": 10,
          "message": "This is a custom message for code 10."
       }
   ]
}

I don't see any other possibilities than writing a custom plugin. If that is the only solution, how to install a plugin in the default Kubernetes deployment (Helm chart)?

urgas9
  • 806
  • 9
  • 22

1 Answers1

0

I did not create a custom plugin, but replaced the handler.lua (or whatever file consists the definition of the error message). So you can still use the original plugin but with custom logic (in your case meaning with custom message).

If you use the official Kong Docker image, the easiest way to deploy custom plugins or overrides is to put your custom files into your repository and build your own image by creating a Dockerfile which extends the original Kong image and copies the necessary files to the Kong Plugins folder in the Docker image. In case of a custom plugin (not only overrides) you additionally have to set an environment variable KONG_PLUGINS=bundled,<customPluginName> to enable the new custom plugin.

Philipp
  • 470
  • 2
  • 10
  • I do agree this could be a viable solution, but I do find it very dangerous for various reasons - mainly because that binds your logic to a version of the plugin. Meaning it is hard to update it to a newer version (for each change in the handler.lua of a new version you need to make new changes). It is dangerous and you might forget to update it sometimes, making it hard to maintain. Back in the time, I did come up with a custom plugin to solve the issue. Check the following repo for `error-transformer` plugin: https://github.com/urgas9/kong-plugins I will try to add some more plugins – urgas9 May 26 '20 at 12:16
  • Thanks for the link. I am aware that the proposed solution has many downsides regarding maintainability, however it's the only solution I know to avoid a complete plugin duplication in case of small changes on an existing plugin. Or did you also find another solution for that? – Philipp May 26 '20 at 22:24