The Request Validator plugin allows you to validate requests before they reach the upstream server. This plugin supports validating the schema of the body and the parameters of the request using either Kong’s own schema validator (body only) or a JSON Schema Draft 4 compliant validator.
If a validation fails, a 400 Bad Request response is returned.
The request Content-Type header is validated against the plugin’s config.allowed_content_types setting. If the Content-Type is not listed, the request will be rejected, and return an HTTP/400 error: {"message":"specified Content-Type is not allowed"}.
The parameter is strictly validated, which means a request with a parameter (for example, application/json; charset=UTF-8) is NOT considered valid for one without the same parameter (for example, application/json). The type, subtype, parameter names, and the value of the charset parameter are not case sensitive based on the RFC explanation.
When setting this configuration, the
Content-Typeheader only gets validated when thebody_schemais configured.
You can validate query parameters, path parameters, and headers in a request using the config.parameter_schema configuration. Only the JSON Schema Draft 4 compliant validator is supported for parameter validation.
Even if
config.versionis set tokong, the parameter validation will still use the JSON Schema Draft 4 compliant validator.
You can set up definitions for each parameter using the parameters under config.parameter_schema.
These definitions are based on the OpenAPI Specification, and the plugin will validate each parameter against it.
For more information, see the OpenAPI specification and the OpenAPI examples.
Request body validation is only performed for:
Content-Type header is set to application/json
+json suffix is added to the Content-Type For example: subtype: application/merge-patch+json
For requests with any other allowed Content-Type, body validation is skipped. In that case, the request is proxied to the upstream without validating the body.
Either Kong’s own schema validator (config.version=kong) or a JSON Schema Draft 4 compliant validator (config.version=draft4) can be used to validate the request body.
This section describes the schema definition for the
kongvalidator. For more information about the JSON Schema Draft 4-compliant validator, see the JSON Schema website.
The config.body_schema parameter expects a JSON array with the definition of each field expected to be in the request body.
Each field definition contains the following attributes:
|
Attribute |
Required |
Description |
|---|---|---|
type
|
The expected type of the field. The following values are supported:
|
|
required
|
Whether the field is required |
Additionally, specific types may have their own required fields:
Each field specification may also contain validators, which perform specific validations:
|
Validator |
Applies to |
Description |
|---|---|---|
between
|
Integers |
Checks if the value is between two integers. Specified as an array; for example, {1, 10}
|
len_eq
|
|
Checks if an array’s length is a given value |
len_min
|
|
Checks if an array’s length is at least a given value |
len_max
|
|
Checks if an array’s length is at most a given value |
match
|
Strings | Checks if the value matches a given Lua pattern |
not_match
|
Strings | Checks if the value doesn’t match a given Lua pattern |
match_all
|
Arrays | Checks if all strings in the array match the specified Lua pattern |
match_none
|
Arrays | Checks if all strings in the array match the specified Lua pattern |
match_any
|
Arrays | Checks if any one of the strings in the array matches the specified Lua pattern |
starts_with
|
Strings | Checks if the string value starts with the specified substring |
one_of
|
|
Checks if the string field value matches one of the specified values |
timestamp
|
Integers | Checks if the field value is a valid timestamp |
uuid
|
Strings | Checks if the string is a valid UUID |
For more information, see Lua patterns.
format attribute
This feature is only supported in JSON Schema Draft 4.
Structural validation alone may be insufficient to validate that an instance
meets all the requirements of an application. The format keyword is defined
to allow interoperable semantic validation for a fixed subset of values that
are accurately described by authoritative resources, be they RFCs or other
external specifications. The following attributes are available: