マッチ条件とビヘイビアの組合せ
１ルール、２マッチ条件、１ビヘイビア
拡張子"jpg" "gif" "png"、およびリクエストメソッドGETにマッチするアクセスに対し、IPホワイトリストを適用します。この設定では、192.18.48.211および192.18.48.212を除くすべてのIPについて、これらのオブジェクトへのGETメソッドアクセスを拒否します。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
}
]
}
]
}
２ルール、２マッチ条件、２ビヘイビア
以下の例では、2つそれぞれのルールが2つのマッチ条件と2つのビヘイビアを持つ組合せを示しています。最初のルールは拡張子"jpg" "gif" "png"、およびリクエストメソッドGETにマッチするアクセスに対し、IPホワイトリストとリファラブラックリストの両方を適用するものです。198.18.48.211および198.18.48.212からのリクエストのみが許可されますが、"abcd.com"を含むリファラヘッダー値を持つ場合は許可されません。
2番目のルールはURLスキームが"HTTP"であるすべてのGETリクエストに対し、IPホワイトリストとリファラブラックリストの両方を適用するものです。198.18.48.215および198.18.48.216からのリクエストのみが許可されますが、"www.abc.com"を含むリファラヘッダー値を持つ場合は許可されません。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
},
{
"name": "referer-blacklist",
"value": "*abcd.com*"
}
]
},
{
"matches": [
{
"name": "url-scheme",
"value": "HTTP"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.215 198.18.48.216"
},
{
"name": "referer-blacklist",
"value": "*www.abc.com*"
}
]
}
]
}
矛盾または未定義となるビヘイビア
拡張子"jpg" "gif" "png"、およびリクエストメソッドGETにマッチするアクセスに対し、IPホワイトリストとIPブラックリストの両方を適用します。このルールは198.18.48.211および198.18.48.212を除くすべてのIPアドレスからのオブジェクトに対するアクセスを拒否します。このルールのビヘイビアではIPホワイトリスト198.18.48.211または198.18.48.212と合致せずアクセスを拒否されるIPアドレスと、IPブラックリストで198.18.48.213または198.18.48.214と合致せずアクセスを許可されるIPアドレスの間で矛盾が生じ、振る舞いは未定義となります。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
},
{
"name": "ip-blacklist",
"value": "198.18.48.213 198.18.48.214"
}
]
}
]
}
より実用的なユースケースとしては、拡張子 "jpg" "gif" "png"、およびリクエストメソッドGETにマッチするリクエストに対し、地理的なアクセス制限を設け、制限地域の中でも例外的にコンテンツへアクセスできるクライアントについてはIPホワイトリストを用いて許可設定するなどが挙げられます。
以下の例では、アメリカ合衆国内のすべてのクライアントを拒否します。ただし、198.18.48.211と198.18.48.212のIPについては、アクセスが明示的に許可されています。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "geo-blacklist",
"type": "country",
"value": "US"
},
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
}
]
}
]
}
ビヘイビアの重複
重複するルールを作成する可能性があることから、ルールの順番は重要です。特にビヘイビアの重複がある場合、ルールの順番は重要です。意図しない振る舞いを防ぐため、ルールの順番に注意してください。具体的には、マッチ条件の制限が厳しいルールほど後方に現れるようにしてください。
例えば、次のような2つのルールが存在する場合を考えます。まず、最初のルールではファイル拡張子"jpg"とのマッチ条件が定義され、コンテンツに7日間のTTLが設定されています。次に、2番目のルールでは"/images/*"のようなパスおよび拡張子"jpg"とのマッチ条件が定義され、コンテンツに1日のTTLが設定されています。このとき、2番目のルールは最初のルールの後でなければなりません。より包括的なルールがリストの後方にある場合、その以前のすべてのマッチ条件と関連するビヘイビアが上書きされます。この例でルールの順番を逆にした場合、"jpg"オブジェクトが"/images/*"パス上にあるかどうかに関わらず、7日間のTTLが適用されます。
以下の例は、上記のシナリオに沿って適切な順序で構成されたルールです。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "7d"
}
]
},
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
},
{
"name": "url-wildcard",
"value": "/images/*"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "1d"
}
]
}
]
}
一方で、ビヘイビアの重複がない場合、ルールの順番は実際の挙動と無関係になります。例えば、 パス"/images/*"と拡張子"jpg"とのマッチ条件があるTTLとされており、さらに別のルールでは拡張子"jpg"が地理的なブラックリストビヘイビア（例えばアクセスを拒否したい国など）のためのマッチ条件に用いられる場合です。この2つのルールはビヘイビアを共有しないので、より制限の少ないルールをリストの後方に配置してもかまいません。
以下の例は、ビヘイビアの重複がなく、ルールの順番が影響しない場合の例を示したものです。
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
}
],
"behaviors": [
{
"name": "geo-blacklist",
"type": "country",
"value": "KP"
}
]
},
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
},
{
"name": "url-wildcard",
"value": "/images/*"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "1d"
}
]
}
]
}