Wednesday, 18 October 2023

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