演算子とグルーピングシンボル
Cloudflareのルール言語は、比較演算子と論理演算子をサポートしています:
- 比較演算子は、式で定義された値が実際のHTTPリクエスト値とどのように関連する必要があるかを指定し、式が
trueを返すための条件を示します。 - 論理演算子は、2つの式を組み合わせて複合式を形成し、優先順位を使用して式がどのように評価されるかを決定します。
グルーピングシンボルは、式を整理し、優先順位を強制し、式をネストすることを可能にします。
比較演算子は、HTTPリクエストからの値が式で定義された値と一致する場合にtrueを返します。
比較演算子を使用する一般的なパターンは次のとおりです:
<field> <comparison_operator> <value>ルール言語は、次の比較演算子をサポートしています:
| 名前 | 演算子表記 | サポートされているデータ型 | ||||
|---|---|---|---|---|---|---|
| 英語 | C風 | 文字列 | IP | 数値 | 例 (演算子は太字) | |
| 等しい | eq | == | ✅ | ✅ | ✅ | http.request.uri.path eq “/articles/2008/“ |
| 等しくない | ne | != | ✅ | ✅ | ✅ | ip.src ne 203.0.113.0 |
| 未満 | lt | < | ✅ | ❌ | ✅ | cf.threat_score lt 10 |
| 以下 | le | <= | ✅ | ❌ | ✅ | cf.threat_score le 20 |
| より大きい | gt | > | ✅ | ❌ | ✅ | cf.threat_score gt 25 |
| 以上 | ge | >= | ✅ | ❌ | ✅ | cf.threat_score ge 60 |
| 正確に 含む | contains | ✅ | ❌ | ❌ | http.request.uri.path contains “/articles/“ | |
| 正規表現に 一致* | matches | ~ | ✅ | ❌ | ❌ | http.request.uri.path matches ”^/articles/200[7-8]/$“ |
| 値が 値のセットに含まれる | in | ✅ | ✅ | ✅ | ip.src in { 203.0.113.0 203.0.113.1 } | |
* matches演算子へのアクセスにはCloudflareのビジネスまたはエンタープライズプランが必要です。
Cloudflareダッシュボードは、次の関数を演算子として表示します:
- starts with(
starts_with()関数に対応):文字列が指定された部分文字列で始まる場合にtrueを返し、そうでない場合はfalseを返します。 - ends with(
ends_with()関数に対応):文字列が指定された部分文字列で終わる場合にtrueを返し、そうでない場合はfalseを返します。
ただし、自分のカスタム式を書くときは、これらの関数を演算子としてではなく、関数呼び出しで使用する必要があります。例えば:
# 有効な関数呼び出しends_with(http.request.uri.path, ".html")
# 無効なends_with関数の使用http.request.uri.path ends_with ".html"ルール式における文字列比較は大文字と小文字を区別します。式内の文字列の大文字小文字のバリエーションを考慮するために、lower()関数を使用し、その結果を小文字の文字列と比較することができます。以下の例のように:
lower(http.request.uri.path) contains "/wp-login.php"wildcard演算子は、フィールド値とリテラル文字列の間で大文字小文字を区別しないマッチを行います。このリテラル文字列には、0個以上の*メタキャラクターが含まれます。各*メタキャラクターは0個以上の文字を表します。strict wildcard演算子は、同様のマッチを行いますが、大文字小文字を区別します。
wildcard/strict wildcard演算子を使用する場合、フィールド値全体がワイルドカードを含むリテラル文字列(演算子の後のリテラル)と一致する必要があります。
# 次の式:http.request.full_uri wildcard "https://example.com/a/*"
# 次のURIに一致します:# - https://example.com/a/ (`*`は0文字に一致)# - https://example.com/a/page.html# - https://example.com/a/sub/folder/?name=value
# 次のURIには一致しません:# - https://example.com/ab/# - https://example.com/b/page.html# - https://sub.example.com/a/例 B
# 次の式:http.request.full_uri wildcard "*.example.com/*/page.html"
# 次のURIに一致します:# - http://sub.example.com/folder/page.html# - https://admin.example.com/team/page.html# - https://admin.example.com/team/subteam/page.html
# 次のURIには一致しません:# - https://example.com/ab/page.html ('*.example.com'はサブドメインのみ一致)# - https://sub.example.com/folder2/page.html?s=value (http.request.full_uriはクエリ文字列を含み、その完全な値は一致しません)# - https://sub.example.com/a/ ('page.html'が欠落)例 C
# 次の式:http.request.full_uri wildcard "*.example.com/*" or http.request.full_uri wildcard "example.com/*"
# 次のURIに一致します:# - https://example.com/folder/list.htm# - https://admin.example.com/folder/team/app1/# - https://admin.example.com/folder/team/app1/?s=foobarwildcard演算子によって使用されるマッチングアルゴリズムは大文字小文字を区別しません。大文字小文字を区別したワイルドカードマッチングを行うには、strict wildcard演算子を使用してください。
リテラル文字列内でリテラル*文字を入力するには、\*を使用してエスケープする必要があります。さらに、\も\\を使用してエスケープする必要があります。ワイルドカードリテラル文字列内で2つのエスケープされていない*文字(**)は無効と見なされ、使用できません。文字のエスケープを行う必要がある場合は、ワイルドカードを含むリテラル文字列を指定するために、生文字列構文を使用することをお勧めします。
ビジネスおよびエンタープライズプランの顧客は、matches演算子にアクセスできます。正規表現マッチングは、Rustの正規表現エンジンを使用して実行されます。
正規表現を使用している場合は、Regular Expressions 101 ↗やRustexp ↗のようなツールを使用してテストできます。
正規表現に関する詳細は、文字列値と正規表現を参照してください。
論理演算子は、2つ以上の式を単一の複合式に結合します。複合式は次の一般的な構文を持ちます:
<expression> <logical_operator> <expression>各論理演算子には、優先順位があります。優先順位(およびグルーピングシンボル)は、Cloudflareが式内の論理演算子を評価する順序を決定します。not演算子は優先順位の中で最も高いです。
| 名前 | 英語 表記 | C風 表記 | 例 | 優先順位 |
|---|---|---|---|---|
| 論理NOT | not | ! | not ( http.host eq “www.cloudflare.com” and ip.src in {203.0.113.0/24} ) | 1 |
| 論理AND | and | && | http.host eq “www.cloudflare.com” and ip.src in {203.0.113.0/24} | 2 |
| 論理XOR (排他的OR) | xor | ^^ | http.host eq “www.cloudflare.com” xor ip.src in {203.0.113.0/24} | 3 |
| 論理OR | or | || | http.host eq “www.cloudflare.com” or ip.src in 203.0.113.0/24 | 4 |
複合式を書く際には、論理演算子の優先順位を意識することが重要です。そうすることで、式が期待通りに評価されます。
例えば、次の一般的な式を考えてみましょう。これはandとor演算子を使用しています:
Expression1 and Expression2 or Expression3これらの演算子に優先順位がなければ、次の2つの解釈のうちどちらが正しいかは明確ではありません:
- Expression 1とExpression 2の両方がtrueである場合またはExpression 3がtrueである場合に一致します。
- Expression 1がtrueである場合かつExpression 2またはExpression 3のいずれかがtrueである場合に一致します。
論理 and 演算子は論理 or よりも優先されるため、and 演算子は最初に評価されなければなりません。解釈1は正しいです。
論理演算子を使用する際の曖昧さを避けるために、評価の順序が明示的になるようにグルーピング記号を使用してください。
Rules言語は、グルーピング記号として括弧((, ))をサポートしています。グルーピング記号を使用すると、式を整理し、優先順位を強制し、式をネストすることができます。
Expression Editor と Cloudflare API のみがグルーピング記号をサポートしています。Expression Builder はサポートしていません。
括弧を使用して、一緒に評価されるべき式を明示的にグループ化します。この例では、括弧は式の評価を変更しませんが、どの論理演算子を最初に評価するかを明確に示します。
(Expression1 and Expression2) or Expression3グルーピング記号が非常に明示的であるため、複合式を書く際にエラーを犯す可能性が低くなります。
グルーピング記号は、複合式のグループ化された要素の優先順位を強制するための強力なツールです。この例では、括弧が論理 or 演算子を論理 and よりも先に評価するように強制します。
Expression1 and (Expression2 or Expression3)括弧がなければ、論理 and 演算子が優先されます。
他のグループ内に括弧でグループ化された式をネストして、非常に正確で洗練された式を作成できます。例えば、ドメインへのアクセスをブロックするために設計されたルールの例は次のとおりです。
( (http.host eq "api.example.com" and http.request.uri.path eq "/api/v2/auth") or (http.host matches "^(www|store|blog)\.example\.com" and http.request.uri.path contains "wp-login.php") or ip.geoip.country in {"CN" "TH" "US" "ID" "KR" "MY" "IT" "SG" "GB"} or ip.geoip.asnum in {12345 54321 11111}) and not ip.src in {11.22.33.0/24}論理演算子の優先順位を評価する際、引用符で区切られた文字列内の括弧は無視されることに注意してください。上記の例からの次の正規表現に含まれるものです。
"^(www|store|blog)\.example\.com"