← Cloudflare Firewall Rules / firewall / api

Последовательность вызовов

Примеры вызовов API на этом сайте иллюстрируют рекомендуемая последовательность вызова двух API (а именно Cloudflare Filters API и Firewall Rules API).

На изображении ниже показана эта последовательность, применимая при создании и редактировании правил. Для операций удаления действует обратный порядок.

Cloudflare рекомендует именно такую последовательность действий, поскольку она облегчает повторное использование фильтров и позволяет работать с обоими API независимо друг от друга. Благодаря автономности Cloudflare Filters один и тот же фильтр можно использовать сразу в нескольких правилах брандмауэра, а также в других продуктах и функциях Cloudflare в будущем.

Например, фильтр, который соответствует всему трафику вашего API (то есть http.request.uri.path matches "^/api/.*$") может отключать кеширование, отключать CAPTCHA для людей, настраивать пользовательские ошибки JSON и использоваться в правиле брандмауэра. При рекомендованной выше последовательности вы повторяете шаги 3-6 для каждой функции Cloudflare, которую настраиваете для того же фильтра, созданного на шагах 1-2.

Однако для POST операция, упрощённая последовательность (показанная ниже) позволяет создать фильтр и правило в одном вызове. В этом случае фильтр и правило ссылаются только друг на друга.

В этой последовательности один POST запрос к /firewall/rules конечная точка принимает объект фильтра в формате JSON, чтобы создать фильтр в Filters API (также с помощью POST запрос). В случае успеха правило брандмауэра будет создано.

Ниже приведен пример вызова и ответа с использованием этого метода:

curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/rules" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '[
  {
    "filter": {
      "expression": "http.request.uri.path contains \"/api/\" and ip.src eq 93.184.216.34"
    },
    "action": "block"
  }
]'

{
	"result": [
		{
			"id": "<RULE_ID>",
			"paused": false,
			"action": "block",
			"priority": null,
			"filter": {
				"id": "<FILTER_ID>",
				"expression": "http.request.uri.path contains \"/api/\" and ip.src eq 93.184.216.34",
				"paused": false
			}
		}
	],
	"success": true,
	"errors": [],
	"messages": []
}

Однако у этого подхода есть некоторые недостатки:

• Клиент, работающий с правилами брандмауэра, должен реализовать обработку ошибок и исключений для всех возможных сбоев как в Firewall Rules API, так и в Filters API.
• Чтобы защититься от случайного изменения или удаления фильтров, используемых другими функциями Cloudflare, PUT или DELETE операции не разрешены.

По умолчанию, если фильтр или правило недействительны, ни один из них не будет создан.

Однако есть одно исключение. Если вы близки к превышению квоты правил, Cloudflare может создать фильтр, но не создать само правило брандмауэра. Это происходит потому, что согласно диаграмме последовательности правило создаётся только после фильтра.

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

В итоге Cloudflare настоятельно рекомендует последовательность из двух вызовов API. Создание правил и фильтров по упрощённой последовательности допускайте только в экстренных ситуациях и только через curl запросы.