Traffic Parrot 5.42.2 released, what's new?

We have just released version 5.42.2. Here is a list of the changes that came with the release:

Features

• Added support for casting to a boolean value
• Added request matching and response templating examples to check for presence of an optional JSON field:

  {{#if (jsonPath request.body '$.[?(@.field)]') }}field is present{{/if}}
  {{#if (not (jsonPath request.body '$.[?(@.field)]') ) }}field is not present{{/unless}}
  {{#if (jsonPath request.body '$.[?(!(@.field))]') }}field is not present{{/unless}}
  {{#unless (jsonPath request.body '$.[?(@.field)]') }}field is not present{{/unless}}
  

• Added new Couchbase configuration options
  • Added support for executing a Couchbase warmup query on startup, which can improve performance of subsequent
  • Added support for setting Couchbase IO options enableDnsSrv and networkResolution
  • Enable in database-connections.json by setting:

    {
        "connectionId": "couchbase.db",
        "type": "COUCHBASE_CONNECTION",
        "connectionString": "couchbase://localhost:32784",
        "username": "Administrator",
        "password": "password",
        "warmupQuery": "SELECT COUNT(*) FROM bucket_a UNION SELECT COUNT(*) FROM bucket_b",
        "enableDnsSrv": true,
        "networkResolution": "auto"
    }

• Added support for OpenAPI request schema validation annotations (beta)
  • Enable in trafficparrot.properties by setting:

    # OFF will turn off validation
    # DEFAULT_VALIDATION will turn on validation and provide default responses when not annotated
    # ONLY_ANNOTATED will turn on validation only for annotated specifications
    trafficparrot.openapi.request.validation.mode=OFF

  • Place OpenAPI specifications in the openapi configuration directory
  • Requests that match the OpenAPI URL will be validated according to the schema of the parameters
  • By default, Traffic Parrot will return an HTTP 400 response with a human-readable plain text validation message of the first validation error encountered
  • You can customize which fields to validate and the error response, by annotating the OpenAPI YAML file with:

    paths:
      /items:
        get:
          parameters:
            # standard OpenAPI parameters with schema definitions
          responses:
            '400':
              content:
                application/json:
                  schema:
                    # standard OpenAPI response schema definition
              x-traffic-parrot-validation: # array of validations that trigger this response code

  • To validate the entire request and return a plain text validation message:

    x-traffic-parrot-validation:
    - type: schema
      response: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate the entire request and return a specific response object:

    x-traffic-parrot-validation:
    - type: schema
      response:
        code: INVALID_REQUEST
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate particular query/path/header parameters and return a specific response object:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: style
        in: query
      - name: limit
        in: query
      - name: id
        in: path
      - name: X-Request-Label
        in: header
      response:
        code: INVALID_REQUEST_PARAMETER
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate the request body:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: *
        in: requestBody
      response:
        code: REQUEST_BODY_INVALID
        message: Request body has invalid value ${value} because ${reason}

  • To perform a specific validation and fall back on a catch-all validation:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: style
        in: query
      response:
        code: INVALID_QUERY
        message: query parameter ${name} has invalid value ${value} because ${reason}
    - type: schema
      response:
        code: INVALID_REQUEST
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}
    

  • Multiple response codes can be annotated, but only one response code per OpenAPI path should have a catch-all validation
  • The template parameters ${name} and ${value} will be populated with the name and value of the field that failed validation
  • The template parameter ${in} will be populated with query/path/header/requestBody
  • The template parameter ${reason} will be populated with a human-readable description of why the validation failed

Fixes

• Library upgrades to fix OWASP issues
• Upgrade script now migrates any previous logback configuration
• Fixed an issue where {{ dataSource }} errors would shadow all other context variables
• Improved internal error reporting when an expected Handlebars variable is not found or of the wrong type
• Validate that mapping queue name is not empty when saving a mapping and when starting replay mode
• Improved performance when using custom request matchers for requests that do not match the standard matcher checks

Changes

• Upgraded WireMock from 2.35.0 to 2.35.1
• Upgraded protoc from 3.23.4 to 3.24.4
• Upgraded gRPC from 1.56.1 to 1.58.0
• Upgraded bundled JRE from 8u372 to 8u382