OAS Validation Configuration

Configuration

This plugin is compatible with DB-less mode.

Compatible protocols

The OAS Validation plugin is compatible with the following protocols:

grpc, grpcs, http, https

Parameters

Here's a list of all the parameters which can be used in this plugin's configuration:

• name

  string required

  The name of the plugin, in this case oas-validation.

• instance_name

  string

  An optional custom name to identify an instance of the plugin, for example oas-validation_my-service. Useful when running the same plugin in multiple contexts, for example, on multiple services.

• service.name or service.id

  string

  The name or ID of the service the plugin targets. Set one of these parameters if adding the plugin to a service through the top-level /plugins endpoint. Not required if using /services/SERVICE_NAME|ID/plugins.

• route.name or route.id

  string

  The name or ID of the route the plugin targets. Set one of these parameters if adding the plugin to a route through the top-level /plugins endpoint. Not required if using /routes/ROUTE_NAME|ID/plugins.

• consumer.name or consumer.id

  string

  The name or ID of the consumer the plugin targets. Set one of these parameters if adding the plugin to a consumer through the top-level /plugins endpoint. Not required if using /consumers/CONSUMER_NAME|ID/plugins.

• enabled

  boolean default: true

  Whether this plugin will be applied.

• config

  record required
  • api_spec

    string required

    The API specification defined using either Swagger or the OpenAPI. This can be either a JSON or YAML based file. If using a YAML file, the spec needs to be URL encoded to preserve the YAML format.

  • verbose_response

    boolean default: false

    If set to true, returns a detailed error message for invalid requests & responses. This is useful while testing.

  • validate_request_body

    boolean default: true

    If set to true, validates the request body content against the API specification.

  • notify_only_request_validation_failure

    boolean default: false

    If set to true, notifications via event hooks are enabled, but request based validation failures don’t affect the request flow.

  • validate_request_header_params

    boolean default: true

    If set to true, validates HTTP header parameters against the API specification.

  • validate_request_query_params

    boolean default: true

    If set to true, validates query parameters against the API specification.

  • validate_request_uri_params

    boolean default: true

    If set to true, validates URI parameters in the request against the API specification.

  • validate_response_body

    boolean default: false

    If set to true, validates the response from the upstream services against the API specification. If validation fails, it results in an HTTP 406 Not Acceptable status code.

  • notify_only_response_body_validation_failure

    boolean default: false

    If set to true, notifications via event hooks are enabled, but response validation failures don’t affect the response flow.

  • query_parameter_check

    boolean required default: false

    If set to true, checks if query parameters in the request exist in the API specification.

  • header_parameter_check

    boolean required default: false

    If set to true, checks if HTTP header parameters in the request exist in the API specification.

  • allowed_header_parameters

    string default: Host,Content-Type,User-Agent,Accept,Content-Length

    List of header parameters in the request that will be ignored when performing HTTP header validation. These are additional headers added to an API request beyond those defined in the API specification. For example, you might include the HTTP header User-Agent, which lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.

  • include_base_path

    boolean required default: false

    Indicates whether to include the base path when performing path match evaluation.