ProtobufValidation#

Действие ProtobufValidation предназначено для валидации protobuf сообщения по proto схеме.

Более подробно работа с proto-файлами рассмотрена в разделе "Валидация Protobuf".

В качестве валидатора protobuf на SOWA используется библиотека protoc-gen-validate (https://github.com/envoyproxy/protoc-gen-validate)

Параметры:

Название

Обязательность

Допустимые значения

Описание

validation_schema

+

Элемент вида {type: proto_file, path: путь, class: класс, message: сообщение, allow_unknown_fields: true/false}

Обязательный параметр, определяющий относительный путь к схеме валидации от каталога ресурсов профиля, валидируемое сообщение и класс с данными, задается в виде: {type: proto_file, path: путь_к_протофайлу, class: класс_с_данными_из_протофайла, message: сообщение_из_протофайла, allow_unknown_fields: allow_unknown_fields}

is_grpc

-

true / false. По умолчанию false.

Параметр, определяющий, что передаваемое сообщение является форматом grpc. Cообщение парсится с учетом length-prefixed-message.

merge_type

-

DELIMITED / FULL. По умолчанию FULL.

Учитывается в случае is_grpc == None or is_grpc == false.

Для Protobuf, но не grpc сообщений, возможна передача в простом или Delimited (c префиксом varint) формате.

Пример:

chains:
  request_chains:
    - actions:
      - action: ProtobufValidation
        conditions:
         - {var: $request_method, operator: '=', val: 'POST'}
        params:
          validation_schema: {type: proto_file, path: data.proto, class: protobuf.Data, message: Person}
      message: $clj_request_body

В параметрах action'а указаны следующие директивы:

  • type: proto_file - тип схемы валидации;

  • path: data.proto - путь к proto-файлу относительно директории с кастомными ресурсами;

  • class: protobuf.Data - класс вместе с пакетом;

  • message: Person - сообщение, которое необходимо валидировать;

  • allow_unknown_fields: true/false - разрешает или запрещает передачу полей, не объявленных в proto-схеме. По умолчанию - false.

В приведенном примере валидация осуществляется для запросов с методом POST. Обратите внимание, что запросы/ответы с другими отправленными/полученными методами в текущей конфигурации игнорируются. Если необходимо предпринимать какие-либо действия, то необходимо либо определять действия ConditionChecker для блокировки таких запросов/ответов, либо другие проверяющие действия.