Implementing Custom Logic

    A Kong Gateway plugin allows you to inject custom logic (in Lua) at several entry-points in the life-cycle of a request/response or a tcp stream connection as it is proxied by Kong Gateway. To do so, the file must return a table with one or more functions with predetermined names. Those functions will be invoked by Kong Gateway at different phases when it processes traffic.

    The first parameter they take is always self. All functions except init_worker can receive a second parameter which is a table with the plugin configuration.

    Available contexts

    If you define any of the following functions in your handler.lua file you’ll implement custom logic at various entry-points of Kong Gateway’s execution life-cycle:

    • HTTP Module is used for plugins written for HTTP/HTTPS requests

    To reduce unexpected behaviour changes, Kong Gateway does not start if a plugin implements both response and either header_filter or body_filter.

    • is used for Plugins written for TCP and UDP stream connections

    All of those functions, except init_worker, take one parameter which is given by Kong Gateway upon its invocation: the configuration of your plugin. This parameter is a Lua table, and contains values defined by your users, according to your plugin’s schema (described in the schema.lua module). More on plugins schemas in the next chapter.

    Note that UDP streams don’t have real connections. Kong Gateway will consider all packets with the same origin and destination host and port as a single connection. After a configurable time without any packet, the connection is considered closed and the log function is executed.

    Kong Gateway processes requests in phases. A plugin is a piece of code that gets activated by Kong Gateway as each phase is executed while the request gets proxied.

    Phases are limited in what they can do. For example, the init_worker phase does not have access to the config parameter because that information isn’t available when kong is initializing each worker.

    A plugin’s handler.lua must return a table containing the functions it must execute on each phase.

    Kong Gateway can process HTTP and stream traffic. Some phases are executed only when processing HTTP traffic, others when processing stream, and some (like init_worker and log) are invoked by both kinds of traffic.

    In addition to functions, a plugin must define two fields:

    • VERSION is an informative field, not used by Kong Gateway directly. It usually matches the version defined in a plugin’s Rockspec version, when it exists.
    • PRIORITY is used to sort plugins before executing each of their phases. Plugins with a higher priority are executed first. See the plugin execution order below for more info about this field.

    The following example handler.lua file defines custom functions for all the possible phases, in both http and stream traffic. It has no functionality besides writing a message to the log every time a phase is invoked. Note that a plugin doesn’t need to provide functions for all phases.

    1. local CustomHandler = {
    2.   VERSION  = "1.0.0",
    3.   PRIORITY = 10,
    4. }
    6. function CustomHandler:init_worker()
    7.   -- Implement logic for the init_worker phase here (http/stream)
    8.   kong.log("init_worker")
    9. end
    12. function CustomHandler:preread(config)
    13.   -- Implement logic for the preread phase here (stream)
    15. end
    18. function CustomHandler:certificate(config)
    19.   -- Implement logic for the certificate phase here (http/stream)
    20.   kong.log("certificate")
    21. end
    23. function CustomHandler:rewrite(config)
    24.   -- Implement logic for the rewrite phase here (http)
    25.   kong.log("rewrite")
    26. end
    28. function CustomHandler:access(config)
    29.   -- Implement logic for the access phase here (http)
    30.   kong.log("access")
    31. end
    33.   -- Implement logic for the WebSocket handshake here
    34.   kong.log("ws_handshake")
    35. end
    37. function CustomHandler:header_filter(config)
    38.   -- Implement logic for the header_filter phase here (http)
    39.   kong.log("header_filter")
    40. end
    42. function CustomHandler:ws_client_frame(config)
    43.   -- Implement logic for WebSocket client messages here
    44.   kong.log("ws_client_frame")
    45. end
    47. function CustomHandler:ws_upstream_frame(config)
    48.   -- Implement logic for WebSocket upstream messages here
    49.   kong.log("ws_upstream_frame")
    50. end
    52. function CustomHandler:body_filter(config)
    53.   -- Implement logic for the body_filter phase here (http)
    54.   kong.log("body_filter")
    55. end
    57. function CustomHandler:log(config)
    58.   -- Implement logic for the log phase here (http/stream)
    59.   kong.log("log")
    60. end
    62. function CustomHandler:ws_close(config)
    63.   -- Implement logic for WebSocket post-connection here
    64.   kong.log("ws_close")
    65. end
    67. -- return the created table, so that Kong can execute it
    68. return CustomHandler
    1. function CustomHandler.access(self, config)
    2.   -- Implement logic for the rewrite phase here (http)
    3.   kong.log("access")
    4. end

    The plugin’s logic doesn’t need to be all defined inside the handler.lua file. It can be split into several Lua files (also called modules). The handler.lua module can use require to include other modules in your plugin.

    For example, the following plugin splits the functionality into three files. access.lua and body_filter.lua return functions. They are in the same folder as handler.lua, which requires and uses them to build the plugin:

    1. -- access.lua
    3.   kong.log("access phase")
    4. end
    1. -- body_filter.lua
    2. return function(self, config)
    3. end

    See for an example of a real-life handler code.

    The BasePlugin module is deprecated and has been removed from Kong Gateway. If you have an old plugin that uses this module, replace the following section:

    with the current equivalent:

    1. local CustomHandler = {
    2.   VERSION  = "1.0.0",
    3.   PRIORITY = 10,
    4. }

    You don’t need to add a :new() method or call any of the CustomHandler.super.XXX:(self) methods.

    WebSocket Plugin Development

    Warning: The WebSocket PDK is under active development and is considered unstable at this time. Backwards-incompatible changes may be made to these functions.

    Requests to services with the ws or wss protocol take a different path through the proxy than regular http requests. Therefore, there are some differences in behavior that must be accounted for when developing plugins for them.

    The following handlers are not executed for WebSocket services:

    • access
    • response
    • header_filter
    • body_filter
    • log

    The following handlers are unique to WebSocket services:

    • ws_handshake
    • ws_client_frame
    • ws_upstream_frame
    • ws_close

    The following handlers are executed for both WebSocket and non-Websocket services:

    • init_worker
    • certificate (TLS/SSL requests only)
    • rewrite

    Even with these differences, it is possible to develop plugins that support both WebSocket and non-WebSocket services. For example:

    1. -- handler.lua
    2. --
    3. -- I am a plugin that implements both WebSocket and non-WebSocket handlers.
    4. --
    5. -- I can be enabled for ws/wss services, http/https/grpc/grpcs services, or
    6. -- even as global plugin.
    7. local MultiProtoHandler = {
    8.   VERSION = "0.1.0",
    9.   PRIORITY = 1000,
    10. }
    12. function MultiProtoHandler:access()
    13.   kong.ctx.plugin.request_type = "non-WebSocket"
    14. end
    16. function MultiProtoHandler:ws_handshake()
    17.   kong.ctx.plugin.request_type = "WebSocket"
    18. end
    21. function MultiProtoHandler:log()
    22.   kong.log("finishing ", kong.ctx.plugin.request_type, " request")
    23. end
    25. -- the `ws_close` handler for this plugin does not implement any WebSocket-specific
    26. -- business logic, so it can simply be aliased to the `log` handler
    27. MultiProtoHandler.ws_close = MultiProtoHandler.log
    29. return MultiProtoHandler

    As seen above, the log and ws_close handlers are parallel to each other. In many cases, one can be aliased to the other without having to write any additional code. The access and ws_handshake handlers are also very similar in this regard. The notable difference lies in which PDK functions are/aren’t available in each context. For instance, the kong.request.get_body() PDK function cannot be used in an access handler because it is fundamentally incompatible with this kind of request.

    Logic implemented in those phases will most likely have to interact with the request/response objects or core components (e.g. access the cache, and database). Kong Gateway provides a (or “PDK”) for such purposes: a set of Lua functions and variables that can be used by Plugins to execute various gateway operations in a way that is guaranteed to be forward-compatible with future releases of Kong Gateway.

    When you are trying to implement some logic that needs to interact with Kong Gateway (e.g. retrieving request headers, producing a response from a plugin, logging some error or debug information), you should consult the Plugin Development Kit Reference.

    Plugins execution order

    Some plugins might depend on the execution of others to perform some operations. For example, plugins relying on the identity of the consumer have to run after authentication plugins. Considering this, Kong Gateway defines priorities between plugins execution to ensure that order is respected.

    Your plugin’s priority can be configured via a property accepting a number in the returned handler table:

    The higher the priority, the sooner your plugin’s phases will be executed in regard to other plugins’ phases (such as :access(), :log(), etc.).

    All of the plugins bundled with Kong Gateway have a static priority. This can be adjusted dynamically using the ordering option. See for more information.

    Open-source or Free mode

    Enterprise

    The following list includes all plugins bundled with open-source Kong Gateway or Kong Gateway running in Free mode.

    The current order of execution for the bundled plugins is:

    The following list includes all plugins bundled with a Kong Gateway Enterprise subscription.

    The current order of execution for the bundled plugins is:

    Next Plugin Configuration