Plugin Development - Plugin Configuration

    The configuration consists of a Lua table in Kong that we call a schema. It contains key/value properties that the user will set when enabling the plugin through the Admin API. Kong provides you with a way of validating the user’s configuration for your plugin.

    Your plugin’s configuration is being verified against your schema when a user issues a request to the to enable or update a plugin on a given Service, Route, or Consumer.

    For example, a user performs the following request:

    If all properties of the object are valid according to your schema, then the API would return 201 Created and the plugin would be stored in the database along with its configuration:

    1. {
    2.   foo = "bar"
    3. }

    If the configuration is not valid, the Admin API would return 400 Bad Request and the appropriate error messages.

    1. kong.plugins.<plugin_name>.schema

    This module is to return a Lua table with properties that will define how your plugins can later be configured by users. Available properties are:

    In most of the cases you can ignore most of those and use the defaults. Or let the user specify value when enabling a plugin.

    Here is an example of a potential schema.lua file (with some overrides applied):

    The config.fields property of your schema.lua file describes the schema of your plugin’s configuration. It is a flexible array of field definitions where each field is a valid configuration property for your plugin, describing the rules for that property. For example:

    1. {
    2.   name = "<plugin-name>",
    3.   fields = {
    4.     config = {
    5.       type = "record",
    6.       fields = {
    7.         {
    8.           some_string = {
    9.             type = "string",
    10.             required = false,
    11.           },
    12.         },
    13.         {
    14.           some_boolean = {
    15.             type = "boolean",
    16.             default = false,
    17.           },
    18.         },
    19.         {
    20.           some_array = {
    21.             type = "array",
    22.             elements = {
    23.               type = "string",
    24.               one_of = {
    25.                 "GET",
    26.                 "POST",
    27.                 "PUT",
    28.                 "DELETE",
    29.               },
    30.             },
    31.           },
    32.         },
    33.       },
    34.     },
    36. }

    Here is the list of some common (not all) accepted rules for a property (see the fields table above for examples):

    There are many more, but the above are commonly used.

    You can also add field validators, to mention a few:

    This schema.lua file is for the key-auth plugin:

    1. -- schema.lua
    2. local typedefs = require "kong.db.schema.typedefs"
    5. return {
    6.   name = "key-auth",
    7.     {
    8.       consumer = typedefs.no_consumer
    9.     },
    10.     {
    11.       protocols = typedefs.protocols_http
    12.     },
    13.     {
    14.       config = {
    15.         type = "record",
    16.         fields = {
    17.           {
    18.             key_names = {
    19.               type = "array",
    20.               required = true,
    21.               elements = typedefs.header_name,
    22.               default = {
    23.                 "apikey",
    24.               },
    25.             },
    26.           },
    27.           {
    28.             hide_credentials = {
    29.               type = "boolean",
    30.               default = false,
    31.             },
    32.           },
    33.           {
    34.             anonymous = {
    35.               type = "string",
    36.               uuid = true,
    37.               legacy = true,
    39.           },
    40.           {
    41.             key_in_body = {
    42.               type = "boolean",
    43.               default = false,
    44.             },
    45.           },
    46.           {
    47.             run_on_preflight = {
    48.               type = "boolean",
    49.               default = true,
    50.             },
    51.           },
    52.         },
    53.       },
    54.     },
    55.   },
    56. }

    Hence, when implementing the access() function of your plugin in and given that the user enabled the plugin with the default values, you’d have access to:

    Note that the above example uses the kong.log.inspect function of the to print out those values to the Kong logs.

    A more complex example, which could be used for an eventual logging plugin:

    1. local typedefs = require "kong.db.schema.typedefs"
    4. return {
    5.   name = "my-custom-plugin",
    6.   fields = {
    7.     {
    8.       config = {
    9.         type = "record",
    10.         fields = {
    11.           {
    12.             environment = {
    13.               type = "string",
    14.               required = true,
    15.               one_of = {
    16.                 "production",
    17.                 "development",
    18.               },
    19.             },
    20.           },
    21.           {
    22.             server = {
    23.               type = "record",
    24.               fields = {
    25.                 {
    26.                   host = typedefs.host {
    27.                     default = "example.com",
    28.                   },
    29.                 },
    30.                 {
    31.                   port = {
    32.                     type = "number",
    33.                     default = 80,
    34.                     between = {
    35.                       0,
    36.                       65534
    37.                     },
    38.                   },
    39.                 },  
    40.               },
    41.             },
    42.           },
    43.         },
    44.       },
    45.     },
    46.   },
    47. }

    Such a configuration will allow a user to post the configuration to your plugin as follows:

    1. $ curl -X POST http://kong:8001/services/<service-name-or-id>/plugins \
    2.     -d "name=my-custom-plugin" \

    And the following will be available in handler.lua:

    Next: