Проверка отдельных запросов без проксирования¶

Если вам нужно проверить отдельные запросы API на основе заданной спецификации OpenAPI без дальнейшего прокси-сервера, вы можете использовать ПроAPI Защита в режиме без прокси. В этом случае решение не проверяет ответы.

Требования¶

• Установленный и настроенный Docker и Docker Compose

• База данных SQLite с таблицей, содержащей одну или несколько спецификаций OpenAPI 3.0. База данных может быть одного из следующих форматов::

  База данных SQLite V1База данных SQLite V2

  • Имя таблицы – openapi_schemas.
  • schema_id, целое число (автоинкрементное) - идентификатор спецификации.
  • schema_version, строка - версия спецификации. Вы можете назначить любую предпочтительную версию. При изменении этого поля ПроAPI Защита предполагает, что сама спецификация изменилась, и обновляет ее соответствующим образом.
  • schema_format, строка - формат спецификации, может быть json или yaml.
  • schema_content, строка - содержимое спецификации.

  Используйте этот формат, если вам нужно контролировать, была ли спецификация из базы данных обработана ПроAPI Защита или нет.

  • Имя таблицы - openapi_schemas.
  • schema_id, целое число (автоинкрементное) - идентификатор спецификации.
  • schema_version, строка - версия спецификации. Вы можете назначить любую предпочтительную версию. При изменении этого поля ПроAPI Защита предполагает, что сама спецификация изменилась, и обновляет ее соответствующим образом.
  • schema_format, строка - формат спецификации, может быть json или yaml.
  • schema_content, строка - содержимое спецификации.

  • status, string - указывает, является ли спецификация new (еще не обработана) или applied (уже обработана). Ожидается, что по умолчанию для нее будет установлено значение new.

    При запуске ПроAPI Защита автоматически обновляет статус обработанной спецификации с new на applied.

    Во время APIFW_SPECIFICATION_UPDATE_PERIOD, обновления получают только спецификации, помеченные как new.

Запуск контейнера ПроAPI Защита¶

Чтобы использовать ПроAPI Защита для проверки запросов без дальнейшего прокси-сервера, вам необходимо смонтировать SQLite database containing OpenAPI 3.0 specifications в /var/lib/wmx-api/1/api.db внутри контейнера Docker ПроAPI Защита. Путь может быть изменен с помощью APIFW_API_MODE_DEBUG_PATH_DB переменной.

Используйте следующую команду для запуска контейнера ПроAPI Защита:

docker run --rm -it \
    -v <PATH_TO_SQLITE_DATABASE>:/var/lib/wmx-api/1/api.db \
    -e APIFW_MODE=API \
    -e APIFW_API_MODE_DEBUG_PATH_DB=/var/lib/wmx-api/1/api.db \
    -e APIFW_LICENSE_KEY=LICENSE_KEY \
    -p 8282:8282 \
registry.webmonitorx.ru/api-firewall/api-firewall:latest 

Вы можете передать контейнеру следующие переменные:

Оценка запросов в соответствии со спецификацией¶

При оценке запросов на соответствие установленной спецификации включите заголовок X-Wallarm-Schema-ID: <schema_id> чтобы указать ПроAPI Защита, какую спецификацию следует использовать для проверки:

curl http://0.0.0.0:8282/path -H "X-Wallarm-Schema-ID: <SCHEMA_ID>"

curl http://0.0.0.0:8282/path -H "X-Wallarm-Schema-ID: 1, 2"

Понимание ответов ПроAPI Защита¶

ПроAPI Защита отвечает 200 HTTP-кодом и JSON с подробной информацией о проверке запроса:

{
    "summary": [
        {
            "schema_id": 1,
            "status_code": 200
        }
    ]
}

{
    "summary": [
        {
            "schema_id":1,
            "status_code":403
        }
    ],
    "errors": [
        {
            "message":"method and path are not found",
            "code":"method_and_path_not_found",
            "schema_id":1
        }
    ]
}

{
    "summary": [
        {
            "schema_id": 0,
            "status_code": 500
        }
    ]
}

Проблемы с базой данных¶

Обработка недействительности в уже смонтированной базе данных SQLite¶

ПроAPI Защита автоматически получает обновления спецификаций из смонтированной базы данных с интервалами, определяемыми переменной APIFW_SPECIFICATION_UPDATE_PERIOD. Если структура или спецификации базы данных становятся недействительными или файл базы данных исчезает после обновления, межсетевой экран сохраняет последний действительный файл спецификации и приостанавливает дальнейшие обновления. Этот метод гарантирует непрерывную работу с самыми последними действительными спецификациями до тех пор, пока правильный файл базы данных не будет восстановлен в брандмауэре API.

В случаях, когда файл базы данных действителен, но содержит недопустимую спецификацию, ПроAPI Защита проигнорирует ошибочную спецификацию и продолжит загрузку всех действительных спецификаций.

Пример

Предположим, ПроAPI Защита загрузил две спецификации, помеченные как 1 и 2. Если спецификация 1 изменена и становится недействительной (из-за синтаксических ошибок или проблем синтаксического анализа), ПроAPI Защита загрузит и будет использовать только спецификацию 2. Он зарегистрирует сообщение об ошибке. указывает на проблему и будет работать только со спецификацией 2.

Монтаж пустой SQLite база данных¶

Если ПроAPI Защита запускается с пустым, недействительным или несуществующим файлом базы данных, он запустится и зарегистрирует ошибки в случае сбоя обновления. В этом состоянии ПроAPI Защита не будет иметь каких-либо спецификаций и, следовательно, не сможет проверять запросы и будет отвечать кодом состояния 500. Обратите внимание, что проверка готовности не будет выполнена до тех пор, пока не будет загружена действительная база данных.