1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383
// Code generated by software.amazon.smithy.rust.codegen.smithy-rs. DO NOT EDIT.
/// <p>A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.</p><note>
/// <p>If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.</p>
/// </note>
/// <p>You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.</p>
/// <p>Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.</p>
/// <p>For example, assume the rule evaluates web requests with the following IP address and HTTP method values:</p>
/// <ul>
/// <li>
/// <p>IP address 10.1.1.1, HTTP method POST</p></li>
/// <li>
/// <p>IP address 10.1.1.1, HTTP method GET</p></li>
/// <li>
/// <p>IP address 127.0.0.0, HTTP method POST</p></li>
/// <li>
/// <p>IP address 10.1.1.1, HTTP method GET</p></li>
/// </ul>
/// <p>The rule would create different aggregation instances according to your aggregation criteria, for example:</p>
/// <ul>
/// <li>
/// <p>If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:</p>
/// <ul>
/// <li>
/// <p>IP address 10.1.1.1: count 3</p></li>
/// <li>
/// <p>IP address 127.0.0.0: count 1</p></li>
/// </ul></li>
/// <li>
/// <p>If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:</p>
/// <ul>
/// <li>
/// <p>HTTP method POST: count 2</p></li>
/// <li>
/// <p>HTTP method GET: count 2</p></li>
/// </ul></li>
/// <li>
/// <p>If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:</p>
/// <ul>
/// <li>
/// <p>IP address 10.1.1.1, HTTP method POST: count 1</p></li>
/// <li>
/// <p>IP address 10.1.1.1, HTTP method GET: count 2</p></li>
/// <li>
/// <p>IP address 127.0.0.0, HTTP method POST: count 1</p></li>
/// </ul></li>
/// </ul>
/// <p>For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.</p>
/// <p>You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.</p>
/// <p>You cannot nest a <code>RateBasedStatement</code> inside another statement, for example inside a <code>NotStatement</code> or <code>OrStatement</code>. You can define a <code>RateBasedStatement</code> inside a web ACL and inside a rule group.</p>
/// <p>For additional information about the options, see <a href="https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-rules.html">Rate limiting web requests using rate-based rules</a> in the <i>WAF Developer Guide</i>.</p>
/// <p>If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call <code>GetRateBasedStatementManagedKeys</code>. This option is not available for other aggregation configurations.</p>
/// <p>WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.</p>
#[non_exhaustive]
#[derive(::std::clone::Clone, ::std::cmp::PartialEq, ::std::fmt::Debug)]
pub struct RateBasedStatement {
/// <p>The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a <code>ScopeDownStatement</code>, this limit is applied only to the requests that match the statement.</p>
/// <p>Examples:</p>
/// <ul>
/// <li>
/// <p>If you aggregate on just the IP address, this is the limit on requests from any single IP address.</p></li>
/// <li>
/// <p>If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.</p></li>
/// </ul>
pub limit: i64,
/// <p>The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.</p>
/// <p>This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.</p>
/// <p>Default: <code>300</code> (5 minutes)</p>
pub evaluation_window_sec: i64,
/// <p>Setting that indicates how to aggregate the request counts.</p><note>
/// <p>Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.</p>
/// </note>
/// <ul>
/// <li>
/// <p><code>CONSTANT</code> - Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.</p>
/// <p>With this option, you must configure the <code>ScopeDownStatement</code> property.</p></li>
/// <li>
/// <p><code>CUSTOM_KEYS</code> - Aggregate the request counts using one or more web request components as the aggregate keys.</p>
/// <p>With this option, you must specify the aggregate keys in the <code>CustomKeys</code> property.</p>
/// <p>To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to <code>IP</code> or <code>FORWARDED_IP</code>.</p></li>
/// <li>
/// <p><code>FORWARDED_IP</code> - Aggregate the request counts on the first IP address in an HTTP header.</p>
/// <p>With this option, you must specify the header to use in the <code>ForwardedIPConfig</code> property.</p>
/// <p>To aggregate on a combination of the forwarded IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// <li>
/// <p><code>IP</code> - Aggregate the request counts on the IP address from the web request origin.</p>
/// <p>To aggregate on a combination of the IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// </ul>
pub aggregate_key_type: crate::types::RateBasedStatementAggregateKeyType,
/// <p>An optional nested statement that narrows the scope of the web requests that are evaluated and managed by the rate-based statement. When you use a scope-down statement, the rate-based rule only tracks and rate limits requests that match the scope-down statement. You can use any nestable <code>Statement</code> in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.</p>
pub scope_down_statement: ::std::option::Option<::std::boxed::Box<crate::types::Statement>>,
/// <p>The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that's reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name.</p><note>
/// <p>If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.</p>
/// </note>
/// <p>This is required if you specify a forwarded IP in the rule's aggregate key settings.</p>
pub forwarded_ip_config: ::std::option::Option<crate::types::ForwardedIpConfig>,
/// <p>Specifies the aggregate keys to use in a rate-base rule.</p>
pub custom_keys: ::std::option::Option<::std::vec::Vec<crate::types::RateBasedStatementCustomKey>>,
}
impl RateBasedStatement {
/// <p>The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a <code>ScopeDownStatement</code>, this limit is applied only to the requests that match the statement.</p>
/// <p>Examples:</p>
/// <ul>
/// <li>
/// <p>If you aggregate on just the IP address, this is the limit on requests from any single IP address.</p></li>
/// <li>
/// <p>If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.</p></li>
/// </ul>
pub fn limit(&self) -> i64 {
self.limit
}
/// <p>The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.</p>
/// <p>This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.</p>
/// <p>Default: <code>300</code> (5 minutes)</p>
pub fn evaluation_window_sec(&self) -> i64 {
self.evaluation_window_sec
}
/// <p>Setting that indicates how to aggregate the request counts.</p><note>
/// <p>Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.</p>
/// </note>
/// <ul>
/// <li>
/// <p><code>CONSTANT</code> - Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.</p>
/// <p>With this option, you must configure the <code>ScopeDownStatement</code> property.</p></li>
/// <li>
/// <p><code>CUSTOM_KEYS</code> - Aggregate the request counts using one or more web request components as the aggregate keys.</p>
/// <p>With this option, you must specify the aggregate keys in the <code>CustomKeys</code> property.</p>
/// <p>To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to <code>IP</code> or <code>FORWARDED_IP</code>.</p></li>
/// <li>
/// <p><code>FORWARDED_IP</code> - Aggregate the request counts on the first IP address in an HTTP header.</p>
/// <p>With this option, you must specify the header to use in the <code>ForwardedIPConfig</code> property.</p>
/// <p>To aggregate on a combination of the forwarded IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// <li>
/// <p><code>IP</code> - Aggregate the request counts on the IP address from the web request origin.</p>
/// <p>To aggregate on a combination of the IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// </ul>
pub fn aggregate_key_type(&self) -> &crate::types::RateBasedStatementAggregateKeyType {
&self.aggregate_key_type
}
/// <p>An optional nested statement that narrows the scope of the web requests that are evaluated and managed by the rate-based statement. When you use a scope-down statement, the rate-based rule only tracks and rate limits requests that match the scope-down statement. You can use any nestable <code>Statement</code> in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.</p>
pub fn scope_down_statement(&self) -> ::std::option::Option<&crate::types::Statement> {
self.scope_down_statement.as_deref()
}
/// <p>The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that's reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name.</p><note>
/// <p>If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.</p>
/// </note>
/// <p>This is required if you specify a forwarded IP in the rule's aggregate key settings.</p>
pub fn forwarded_ip_config(&self) -> ::std::option::Option<&crate::types::ForwardedIpConfig> {
self.forwarded_ip_config.as_ref()
}
/// <p>Specifies the aggregate keys to use in a rate-base rule.</p>
///
/// If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use `.custom_keys.is_none()`.
pub fn custom_keys(&self) -> &[crate::types::RateBasedStatementCustomKey] {
self.custom_keys.as_deref().unwrap_or_default()
}
}
impl RateBasedStatement {
/// Creates a new builder-style object to manufacture [`RateBasedStatement`](crate::types::RateBasedStatement).
pub fn builder() -> crate::types::builders::RateBasedStatementBuilder {
crate::types::builders::RateBasedStatementBuilder::default()
}
}
/// A builder for [`RateBasedStatement`](crate::types::RateBasedStatement).
#[non_exhaustive]
#[derive(::std::clone::Clone, ::std::cmp::PartialEq, ::std::default::Default, ::std::fmt::Debug)]
pub struct RateBasedStatementBuilder {
pub(crate) limit: ::std::option::Option<i64>,
pub(crate) evaluation_window_sec: ::std::option::Option<i64>,
pub(crate) aggregate_key_type: ::std::option::Option<crate::types::RateBasedStatementAggregateKeyType>,
pub(crate) scope_down_statement: ::std::option::Option<::std::boxed::Box<crate::types::Statement>>,
pub(crate) forwarded_ip_config: ::std::option::Option<crate::types::ForwardedIpConfig>,
pub(crate) custom_keys: ::std::option::Option<::std::vec::Vec<crate::types::RateBasedStatementCustomKey>>,
}
impl RateBasedStatementBuilder {
/// <p>The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a <code>ScopeDownStatement</code>, this limit is applied only to the requests that match the statement.</p>
/// <p>Examples:</p>
/// <ul>
/// <li>
/// <p>If you aggregate on just the IP address, this is the limit on requests from any single IP address.</p></li>
/// <li>
/// <p>If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.</p></li>
/// </ul>
/// This field is required.
pub fn limit(mut self, input: i64) -> Self {
self.limit = ::std::option::Option::Some(input);
self
}
/// <p>The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a <code>ScopeDownStatement</code>, this limit is applied only to the requests that match the statement.</p>
/// <p>Examples:</p>
/// <ul>
/// <li>
/// <p>If you aggregate on just the IP address, this is the limit on requests from any single IP address.</p></li>
/// <li>
/// <p>If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.</p></li>
/// </ul>
pub fn set_limit(mut self, input: ::std::option::Option<i64>) -> Self {
self.limit = input;
self
}
/// <p>The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a <code>ScopeDownStatement</code>, this limit is applied only to the requests that match the statement.</p>
/// <p>Examples:</p>
/// <ul>
/// <li>
/// <p>If you aggregate on just the IP address, this is the limit on requests from any single IP address.</p></li>
/// <li>
/// <p>If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.</p></li>
/// </ul>
pub fn get_limit(&self) -> &::std::option::Option<i64> {
&self.limit
}
/// <p>The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.</p>
/// <p>This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.</p>
/// <p>Default: <code>300</code> (5 minutes)</p>
pub fn evaluation_window_sec(mut self, input: i64) -> Self {
self.evaluation_window_sec = ::std::option::Option::Some(input);
self
}
/// <p>The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.</p>
/// <p>This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.</p>
/// <p>Default: <code>300</code> (5 minutes)</p>
pub fn set_evaluation_window_sec(mut self, input: ::std::option::Option<i64>) -> Self {
self.evaluation_window_sec = input;
self
}
/// <p>The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.</p>
/// <p>This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.</p>
/// <p>Default: <code>300</code> (5 minutes)</p>
pub fn get_evaluation_window_sec(&self) -> &::std::option::Option<i64> {
&self.evaluation_window_sec
}
/// <p>Setting that indicates how to aggregate the request counts.</p><note>
/// <p>Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.</p>
/// </note>
/// <ul>
/// <li>
/// <p><code>CONSTANT</code> - Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.</p>
/// <p>With this option, you must configure the <code>ScopeDownStatement</code> property.</p></li>
/// <li>
/// <p><code>CUSTOM_KEYS</code> - Aggregate the request counts using one or more web request components as the aggregate keys.</p>
/// <p>With this option, you must specify the aggregate keys in the <code>CustomKeys</code> property.</p>
/// <p>To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to <code>IP</code> or <code>FORWARDED_IP</code>.</p></li>
/// <li>
/// <p><code>FORWARDED_IP</code> - Aggregate the request counts on the first IP address in an HTTP header.</p>
/// <p>With this option, you must specify the header to use in the <code>ForwardedIPConfig</code> property.</p>
/// <p>To aggregate on a combination of the forwarded IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// <li>
/// <p><code>IP</code> - Aggregate the request counts on the IP address from the web request origin.</p>
/// <p>To aggregate on a combination of the IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// </ul>
/// This field is required.
pub fn aggregate_key_type(mut self, input: crate::types::RateBasedStatementAggregateKeyType) -> Self {
self.aggregate_key_type = ::std::option::Option::Some(input);
self
}
/// <p>Setting that indicates how to aggregate the request counts.</p><note>
/// <p>Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.</p>
/// </note>
/// <ul>
/// <li>
/// <p><code>CONSTANT</code> - Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.</p>
/// <p>With this option, you must configure the <code>ScopeDownStatement</code> property.</p></li>
/// <li>
/// <p><code>CUSTOM_KEYS</code> - Aggregate the request counts using one or more web request components as the aggregate keys.</p>
/// <p>With this option, you must specify the aggregate keys in the <code>CustomKeys</code> property.</p>
/// <p>To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to <code>IP</code> or <code>FORWARDED_IP</code>.</p></li>
/// <li>
/// <p><code>FORWARDED_IP</code> - Aggregate the request counts on the first IP address in an HTTP header.</p>
/// <p>With this option, you must specify the header to use in the <code>ForwardedIPConfig</code> property.</p>
/// <p>To aggregate on a combination of the forwarded IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// <li>
/// <p><code>IP</code> - Aggregate the request counts on the IP address from the web request origin.</p>
/// <p>To aggregate on a combination of the IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// </ul>
pub fn set_aggregate_key_type(mut self, input: ::std::option::Option<crate::types::RateBasedStatementAggregateKeyType>) -> Self {
self.aggregate_key_type = input;
self
}
/// <p>Setting that indicates how to aggregate the request counts.</p><note>
/// <p>Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.</p>
/// </note>
/// <ul>
/// <li>
/// <p><code>CONSTANT</code> - Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.</p>
/// <p>With this option, you must configure the <code>ScopeDownStatement</code> property.</p></li>
/// <li>
/// <p><code>CUSTOM_KEYS</code> - Aggregate the request counts using one or more web request components as the aggregate keys.</p>
/// <p>With this option, you must specify the aggregate keys in the <code>CustomKeys</code> property.</p>
/// <p>To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to <code>IP</code> or <code>FORWARDED_IP</code>.</p></li>
/// <li>
/// <p><code>FORWARDED_IP</code> - Aggregate the request counts on the first IP address in an HTTP header.</p>
/// <p>With this option, you must specify the header to use in the <code>ForwardedIPConfig</code> property.</p>
/// <p>To aggregate on a combination of the forwarded IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// <li>
/// <p><code>IP</code> - Aggregate the request counts on the IP address from the web request origin.</p>
/// <p>To aggregate on a combination of the IP address with other aggregate keys, use <code>CUSTOM_KEYS</code>.</p></li>
/// </ul>
pub fn get_aggregate_key_type(&self) -> &::std::option::Option<crate::types::RateBasedStatementAggregateKeyType> {
&self.aggregate_key_type
}
/// <p>An optional nested statement that narrows the scope of the web requests that are evaluated and managed by the rate-based statement. When you use a scope-down statement, the rate-based rule only tracks and rate limits requests that match the scope-down statement. You can use any nestable <code>Statement</code> in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.</p>
pub fn scope_down_statement(mut self, input: impl ::std::convert::Into<::std::boxed::Box<crate::types::Statement>>) -> Self {
self.scope_down_statement = ::std::option::Option::Some(input.into());
self
}
/// <p>An optional nested statement that narrows the scope of the web requests that are evaluated and managed by the rate-based statement. When you use a scope-down statement, the rate-based rule only tracks and rate limits requests that match the scope-down statement. You can use any nestable <code>Statement</code> in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.</p>
pub fn set_scope_down_statement(mut self, input: ::std::option::Option<::std::boxed::Box<crate::types::Statement>>) -> Self {
self.scope_down_statement = input;
self
}
/// <p>An optional nested statement that narrows the scope of the web requests that are evaluated and managed by the rate-based statement. When you use a scope-down statement, the rate-based rule only tracks and rate limits requests that match the scope-down statement. You can use any nestable <code>Statement</code> in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.</p>
pub fn get_scope_down_statement(&self) -> &::std::option::Option<::std::boxed::Box<crate::types::Statement>> {
&self.scope_down_statement
}
/// <p>The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that's reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name.</p><note>
/// <p>If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.</p>
/// </note>
/// <p>This is required if you specify a forwarded IP in the rule's aggregate key settings.</p>
pub fn forwarded_ip_config(mut self, input: crate::types::ForwardedIpConfig) -> Self {
self.forwarded_ip_config = ::std::option::Option::Some(input);
self
}
/// <p>The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that's reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name.</p><note>
/// <p>If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.</p>
/// </note>
/// <p>This is required if you specify a forwarded IP in the rule's aggregate key settings.</p>
pub fn set_forwarded_ip_config(mut self, input: ::std::option::Option<crate::types::ForwardedIpConfig>) -> Self {
self.forwarded_ip_config = input;
self
}
/// <p>The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that's reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name.</p><note>
/// <p>If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.</p>
/// </note>
/// <p>This is required if you specify a forwarded IP in the rule's aggregate key settings.</p>
pub fn get_forwarded_ip_config(&self) -> &::std::option::Option<crate::types::ForwardedIpConfig> {
&self.forwarded_ip_config
}
/// Appends an item to `custom_keys`.
///
/// To override the contents of this collection use [`set_custom_keys`](Self::set_custom_keys).
///
/// <p>Specifies the aggregate keys to use in a rate-base rule.</p>
pub fn custom_keys(mut self, input: crate::types::RateBasedStatementCustomKey) -> Self {
let mut v = self.custom_keys.unwrap_or_default();
v.push(input);
self.custom_keys = ::std::option::Option::Some(v);
self
}
/// <p>Specifies the aggregate keys to use in a rate-base rule.</p>
pub fn set_custom_keys(mut self, input: ::std::option::Option<::std::vec::Vec<crate::types::RateBasedStatementCustomKey>>) -> Self {
self.custom_keys = input;
self
}
/// <p>Specifies the aggregate keys to use in a rate-base rule.</p>
pub fn get_custom_keys(&self) -> &::std::option::Option<::std::vec::Vec<crate::types::RateBasedStatementCustomKey>> {
&self.custom_keys
}
/// Consumes the builder and constructs a [`RateBasedStatement`](crate::types::RateBasedStatement).
/// This method will fail if any of the following fields are not set:
/// - [`limit`](crate::types::builders::RateBasedStatementBuilder::limit)
/// - [`aggregate_key_type`](crate::types::builders::RateBasedStatementBuilder::aggregate_key_type)
pub fn build(self) -> ::std::result::Result<crate::types::RateBasedStatement, ::aws_smithy_types::error::operation::BuildError> {
::std::result::Result::Ok(crate::types::RateBasedStatement {
limit: self.limit.ok_or_else(|| {
::aws_smithy_types::error::operation::BuildError::missing_field(
"limit",
"limit was not specified but it is required when building RateBasedStatement",
)
})?,
evaluation_window_sec: self.evaluation_window_sec.unwrap_or_default(),
aggregate_key_type: self.aggregate_key_type.ok_or_else(|| {
::aws_smithy_types::error::operation::BuildError::missing_field(
"aggregate_key_type",
"aggregate_key_type was not specified but it is required when building RateBasedStatement",
)
})?,
scope_down_statement: self.scope_down_statement,
forwarded_ip_config: self.forwarded_ip_config,
custom_keys: self.custom_keys,
})
}
}