- tocdepth
2
Настройки плагинов для правил
Плагин — подключаемый модуль, реализующий расширенную логику, которая применяется между отправкой HTTP-запроса и получением ответа. Конфигурация плагина привязывается к правилу.
Плагины могут быть привязаны только к конкретному правилу и модифицируют выполнение только тех запросов, которые соответствуют настройкам правила. К каждому правилу могут быть привязаны все доступные плагины, но только по одному каждого типа.
Чтобы настроить плагин:
Выберите плагин или плагины из списка.
Укажите параметры выбранных плагинов (наборы полей зависят от выбранного типа плагина).
Список доступных плагинов зависит от выбранного типа правила.
Тип плагина
Mock API
Маршрутизация запросов
Разделение трафика
Перенаправление запросов (Redirect)
-
+
+
-
+
+
+
-
-
+
-
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
Нажмите Создать.
Примечание
Использовать можно только включенное правило.
Ограничение числа запросов
- Сценарий использования
Ограничить количество запросов, отправляемых по определенному URI в единицу времени, чтобы избежать DDoS-атаки.
- Поля для заполнения
Количество запросов — максимальное количество запросов, которое может быть обработано в единицу времени.
Интервал времени — время в секундах, в течение которого действует счетчик количества запросов. При достижении указанного значения, счетчик максимального количества запросов обнуляется.
Код ответа на отклоненный запрос — код ответа HTTP, который следует возвращать, когда запрос отклоняется из-за превышения лимита. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения возвращается 503.
Заголовки успешно выполненных запросов содержат следующую информацию:
X-RateLimit-Limit— установленный в плагине лимит запросов.X-RateLimit-Remaining— оставшееся количество запросов, которые могут быть приняты до обнуления счетчика.
Пример успешно обработанного запроса
Ответ содержит следующий заголовок:
HTTP/1.1 200 OK Content-Type: text/html Content-Length: 13175 Connection: keep-alive X-RateLimit-Limit: 2 X-RateLimit-Remaining: 1 Server: web server
Таким образом, в настройках установлен лимит в количестве 2 запросов за интервал времени. До сброса счетчика доступна обработка еще одного запроса.
Пример запроса, отклоненного из-за превышения лимита на количество запросов за указанный интервал
HTTP/1.1 503 Service Temporarily Unavailable Content-Type: text/html Content-Length: 194 Connection: keep-alive Server: web server <html> <head><title>503 Service Temporarily Unavailable</title></head> <body> <center><h1>503 Service Temporarily Unavailable</h1></center> <hr><center>openresty</center> </body> </html>
Перезапись ответа
- Сценарий использования
Изменить информацию, получаемую в ответе от целевого хоста: набор заголовков, код ответа или тело ответа.
- Поля для заполнения
Новый код ответа — код ответа HTTP, которым заменяется получаемый код. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения код ответа не модифицируется.
Новое тело ответа — тело ответа, возвращаемое при перезаписи. При отсутствии значения тело ответа не модифицируется.
Кодировать тело ответа в base64 — возвращать ответ в кодировке base64.
Заголовок — заголовок, который нужно модифицировать при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Значение — значение, которое будет передано в соответствующем заголовке при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Кеширование запросов (Preview)
- Сценарий использования
Кешировать ответы от целевого хоста в течение определенного интервала времени и возвращать ответы из кеша. Это позволяет снизить нагрузку на целевой хост.
- Поля для заполнения
Перечень кодов ответа — коды ответов HTTP, при которых следует кешировать ответы. Оставьте поле пустым, если требуется кешировать все ответы.
Время жизни кеша — время (в секундах), в течение которого кешированный ответ следует удалить при отсутствии повторных запросов.
Базовая авторизация
- Сценарий использования
Запрашивать аутентификацию при отправке запросов к шлюзу. Доступ предоставляется только заданным пользователям, у которых в качестве способа авторизации используется пара логин-пароль.
- Поля для заполнения
Авторизовать всех пользователей API-шлюза — обрабатывать запросы всех зарегистрированных пользователей, обладающих парами логин-пароль. Если опция выключена, обрабатываются только запросы пользователей, указанных в группе полей Пользователь.
Пользователь — список зарегистрированных пользователей, которым предоставляется доступ.
Для каждого добавленного пользователя можно:
отобразить логин и пароль (
);скрыть отображение логина и пароля (
);скопировать значение логина и пароля (
).
Не передавать авторизационные заголовки в целевой хост — удалять из запросов к целевому хосту заголовки, содержащие авторизационные данные. Если опция отключена, данные передаются без изменений.
Если этот плагин и/или другие способы авторизации не подключены, будет обработан запрос любого неавторизованного пользователя к шлюзу API.
Авторизация по API-ключам
- Сценарий использования
Запрашивать аутентификацию при отправке запросов к шлюзу. Доступ предоставляется только заданным пользователям, у которых в качестве способа авторизации используется API-ключ.
- Поля для заполнения
Авторизовать всех пользователей API-шлюза — обрабатывать запросы всех пользователей, обладающих созданными API-ключами. Если опция выключена, обрабатываются только запросы от пользователей, указанных в следующей группе полей.
Пользователь — список зарегистрированных пользователей, которым предоставляется доступ на отправку запросов. Для каждого добавленного пользователя можно:
отобразить API-ключ (
);скрыть отображение API-ключа (
);скопировать значение API-ключа (
).
Удалить данные пользователя и тем самым заблокировать доступ можно кнопкой
.Не передавать авторизационные заголовки в целевой хост — удалять заголовки, содержащие авторизационные данные, из запросов к целевому хосту. Если опция отключена, данные передаются без изменений.
Если этот плагин и/или другие способы авторизации не подключены, будет обработан запрос любого неавторизованного пользователя к шлюзу API.
Авторизация через IAM-токен
- Сценарий использования
Запрашивать аутентификацию при отправке запросов к шлюзу. Доступ предоставляется пользователям, которые в качестве способа авторизации используют IAM-токен.
Для авторизации можно использовать как персональный IAM-токен, так и токен сервисного аккаунта.
Совместное использование ресурсов (CORS)
Плагин для реализации механизма доступа к ресурсам другого домена (Cross-Origin Resource Sharing).
- Поля для заполнения
Настройка разрешений — активировать поля для тонкой настройки разрешений. Если опция выключена, прочие опции недоступны — по умолчанию разрешены все ресурсы.
Разрешить источники — список источников (через запятую), для которых разрешен CORS. Формат указания одного источника:
scheme://host:port.Если опция Разрешить Credentials выключена, можно включить CORS для всех источников, указав в поле значение «*».
Разрешить HTTP-методы — список HTTP-методов (через запятую), для которых разрешен CORS. Примеры значений: «POST», «GET».
Если опция Разрешить Credentials выключена, можно включить CORS для всех методов, указав в поле значение «*».
Разрешить заголовки запроса — список заголовков запросов (через запятую), разрешенные при доступе к CORS-ресурсу.
Если опция Разрешить Credentials выключена, можно включить CORS для всех всех заголовков запросов, указав в поле значение «*».
Разрешить заголовки ответа — список заголовков ответов (через запятую), разрешенных при доступе к CORS-ресурсу.
Если опция Разрешить Credentials выключена, можно включить CORS для всех заголовков, указав в поле значение «*».
Разрешить Credentials — разрешить включать в запросы credentials (например, cookies).
Circuit Breaker
- Сценарий использования
Автоматически отклонять API-запросы в случае недоступности целевого бэкенда. Это позволит избежать постоянных повторных запросов от клиента к бэкенду в случае сбоя.
- Поля для заполнения
Код ответа на отклоненный запрос — код ответа шлюза при попытке подключения к целевому бэкенду в период автоматического отклонения запросов. Допустимое значение от 200 до 599.
Максимальное время работы Circuit Breaker, сек — время в секундах, в течение которого работает Circuit Breaker.
Коды ошибок сервера — коды ошибок от целевого бэкенда. Допустимое значение от 500 до 599. Если поле не заполнено, то автоматическое отклонение запросов включается при получении от целевого бэкенда ответов с кодом 500 в количестве, указанном в поле Количество неуспешных запросов.
Коды успешной обработки запроса — коды успешного ответа от целевого бэкенда. Допустимое значение от 200 до 499. Если поле не заполнено, при получении от целевого бэкенда ответов с кодом 200 в количестве, указанном в поле Количество успешных запросов, бэкенд считается работоспособным и мониторинг запросов прекращается.
Количество неуспешных запросов — количество последовательных неуспешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается неработоспособным и включается автоматическое отклонение запросов.
Количество успешных запросов — количество последовательных успешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается работоспособным и мониторинг запросов прекращается.
Пример конфигурации плагина:
В приведенном выше примере конфигурации автоматическое отклонение запросов работает следующим образом.
При получении от бэкенда ответа с кодом 503 включается мониторинг запросов — сервис начинает считать успешные и неуспешные коды ответов от бэкенда.
Если приходит три подряд ответа с кодом 503, то бэкенд считается неработоспособным и включается режим автоматического отклонения запросов. Режим включается на 2 секунды, после чего запросы к бэкенду повторяются.
Если от бэкенда снова поступает ответ с кодом 503, то время автоматического отклонения запросов увеличивается вдвое (4 секунды). Так происходит при каждом последующем получении ответа с кодом 503. При этом время работы режима отклонения запросов не может превышать указанное в поле Максимальное время работы Circuit Breaker.
Запросы к бэкенду повторяются каждый раз после окончания времени работы режима отклонения запросов. Сервис продолжает считать запросы, пока не получит от бэкенда два раза подряд код ответа 200. Тогда бэкенд снова считается работоспособным и мониторинг запросов прекращается до следующего получения кода ответа 503.
Примечание
Сервис считает только успешные и неуспешные коды ответа от бэкенда — 2хх и 5хх. Например, три подряд неуспешных ответа могут быть представлены следующими последовательностями:
«503 — 503 — 503»
«503 — 403 — 503 — 503»
«503 — 404 — 403 — 503 — 503»
Пример двух подряд успешных ответов:
«200 — 200»
«200 — 403 — 200»
«200 — 403 — 401 — 200»
При этом, если после ответа с кодом 200 пришел ответ 503, то количество успешных ответов обнуляется и счет начинается заново при получении следующего успешного ответа.
для Dev & Test