Project version overview:
-
0.12.x - Bucket4j 8.9.0 - Spring Boot 3.2.x
-
0.11.x - Bucket4j 8.8.0 - Spring Boot 3.2.x
-
0.10.x - Bucket4j 8.7.0 - Spring Boot 3.1.x
This project is a Spring Boot Starter for Bucket4j, allowing you to set access limits on your API effortlessly. Its key advantage lies in the configuration via properties or yaml files, eliminating the need for manual code authoring.
Here are some example use cases:
-
Preventing DoS Attacks
-
Thwarting brute-force login attempts
-
Implementing request throttling for specific regions, unauthenticated users, and authenticated users
-
Applying rate limits for non-paying users or users with varying permissions
The project offers several features, some utilizing Spring’s Expression Language for dynamic condition interpretation:
-
Cache key for differentiate the by username, IP address, …)
-
Execution based on specific conditions
-
Skipping based on specific conditions
-
Post-token consumption actions based on filter/method results
You have two options for rate limit configuration: adding a filter for incoming web requests or applying fine-grained control at the method level.
Filters are customizable components designed to intercept incoming web requests, capable of rejecting requests to halt further processing. You can incorporate multiple filters for various URLs or opt to bypass rate limits entirely for authenticated users. When the limit is exceeded, the web request is aborted, and the client receives an HTTP Status 429 Too Many Requests error.
This projects supports the following filters:
-
Servlet Filter (Default)
-
Webflux Webfilter (reactive)
-
Spring Cloud Gateway Global Filter (reactive)
bucket4j.filters[0].cache-name=buckets # the name of the cache
bucket4j.filters[0].url=^(/hello).* # regular expression for the url
bucket4j.filters[0].rate-limits[0].bandwidths[0].capacity=5 # refills 5 tokens every 10 seconds (intervall)
bucket4j.filters[0].rate-limits[0].bandwidths[0].time=10
bucket4j.filters[0].rate-limits[0].bandwidths[0].unit=seconds
bucket4j.filters[0].rate-limits[0].bandwidths[0].refill-speed=intervallUtilizing the '@RateLimiting' annotation, AOP intercepts your method. This grants you comprehensive access to method parameters, empowering you to define the rate limit key or conditionally skip rate limiting with ease.
bucket4j.methods[0].name=not_an_admin # the name of the configuration for annotation reference
bucket4j.methods[0].cache-name=buckets # the name of the cache
bucket4j.methods[0].rate-limits[0].bandwidths[0].capacity=5 # refills 5 tokens every 10 seconds (intervall)
bucket4j.methods[0].rate-limits[0].bandwidths[0].time=10
bucket4j.methods[0].rate-limits[0].bandwidths[0].unit=seconds
bucket4j.methods[0].rate-limits[0].bandwidths[0].refill-speed=intervall@RateLimiting(
// reference to the property file
name = "not_an_admin",
// the rate limit is per user
cacheKey= "#username",
// only when the parameter is not admin
executeCondition = "#username != 'admin'",
// skip when parameter equals admin
skipCondition = "#username eq 'admin",
// the method name is added to the cache key to prevent conflicts with other methods
ratePerMethod = true,
// if the limit is exceeded the fallback method is called. If not provided an exception is thrown
fallbackMethodName = "myFallbackMethod")
public String execute(String username) {
log.info("Method with Param {} executed", username);
return myParamName;
}
// the fallback method must have the same signature
public String myFallbackMethod(String username) {
log.info("Fallback-Method with Param {} executed", username);
return myParamName;
}The '@RateLimiting' annotation on class level executes the rate limit on all public methods of the class. With '@IgnoreRateLimiting' you can ignore the rate limit at all on class level or for specific method on method level.
@Component
@Slf4j
@RateLimiting(name = "default")
public class TestService {
public void notAnnotatedMethod() {
log.info("Method notAnnotatedMethod");
}
@IgnoreRateLimiting
public void ignoreMethod() {
log.info("Method ignoreMethod");
}
}You can find some Configuration examples in the test project: Examples
bucket4j.enabled=true # enable/disable bucket4j support
bucket4j.cache-to-use= # If you use multiple caching implementation in your project and you want to choose a specific one you can set the cache here (jcache, hazelcast, ignite, redis)
# Optional default metric tags for all filters
bucket4j.default-metric-tags[0].key=IP
bucket4j.default-metric-tags[0].expression=getRemoteAddr()
bucket4j.default-metric-tags[0].types=REJECTED_COUNTERbucket4j.filter-config-caching-enabled=true #Enable/disable caching of filter configurations.
bucket4j.filter-config-cache-name=filterConfigCache #The name of the cache where the configurations are stored. Defaults to 'filterConfigCache'.
bucket4j.filters[0].id=filter1 # The id of the filter. This field is mandatory when configuration caching is enabled and should always be a unique string.
bucket4j.filters[0].major-version=1 # [min = 1, max = 92 million] Major version number of the configuration.
bucket4j.filters[0].minor-version=1 # [min = 1, max = 99 billion] Minor version number of the configuration. (intended for internal updates, for example based on CPU-usage, but can also be used for regular updates)
bucket4j.filters[0].cache-name=buckets # the name of the cache key
bucket4j.filters[0].filter-method=servlet # [servlet,webflux,gateway]
bucket4j.filters[0].filter-order= # Per default the lowest integer plus 10. Set it to a number higher then zero to execute it after e.g. Spring Security.
bucket4j.filters[0].http-content-type=application/json
bucket4j.filters[0].http-status-code=TOO_MANY_REQUESTS # Enum value of org.springframework.http.HttpStatus
bucket4j.filters[0].http-response-body={ "message": "Too many requests" } # the json response which should be added to the body
bucket4j.filters[0].http-response-headers.<MY_CUSTOM_HEADER>=MY_CUSTOM_HEADER_VALUE # You can add any numbers of custom headers
bucket4j.filters[0].hide-http-response-headers=true # Hides response headers like x-rate-limit-remaining or x-rate-limit-retry-after-seconds on rate limiting
bucket4j.filters[0].url=.* # a regular expression
bucket4j.filters[0].strategy=first # [first, all] if multiple rate limits configured the 'first' strategy stops the processing after the first matching
bucket4j.filters[0].rate-limits[0].cache-key=getRemoteAddr() # defines the cache key. It will be evaluated with the Spring Expression Language
bucket4j.filters[0].rate-limits[0].num-tokens=1 # The number of tokens to consume
bucket4j.filters[0].rate-limits[0].execute-condition=1==1 # an optional SpEl expression to decide to execute the rate limit or not
bucket4j.filters[1].rate-limits[0].post-execute-condition= # an optional SpEl expression to decide if the token consumption should only estimated for the incoming request and the returning response used to check if the token must be consumed: getStatus() eq 401
bucket4j.filters[0].rate-limits[0].execute-predicates[0]=PATH=/hello,/world # On the HTTP Path as a list
bucket4j.filters[0].rate-limits[0].execute-predicates[1]=METHOD=GET,POST # On the HTTP Method
bucket4j.filters[0].rate-limits[0].execute-predicates[2]=QUERY=HELLO # Checks for the existence of a Query Parameter
bucket4j.filters[0].rate-limits[0].skip-condition=1==1 # an optional SpEl expression to skip the rate limit
bucket4j.filters[0].rate-limits[0].tokens-inheritance-strategy=RESET # [RESET, AS_IS, ADDITIVE, PROPORTIONALLY], defaults to RESET and is only used for dynamically updating configurations
bucket4j.filters[0].rate-limits[0].bandwidths[0].id=bandwidthId # Optional when using tokensInheritanceStrategy.RESET or if the rate-limit only contains 1 bandwidth. The id should be unique within the rate-limit.
bucket4j.filters[0].rate-limits[0].bandwidths[0].capacity=10
bucket4j.filters[0].rate-limits[0].bandwidths[0].refill-capacity= # default is capacity
bucket4j.filters[0].rate-limits[0].bandwidths[0].time=1
bucket4j.filters[0].rate-limits[0].bandwidths[0].unit=minutes
bucket4j.filters[0].rate-limits[0].bandwidths[0].initial-capacity= # Optional initial tokens
bucket4j.filters[0].rate-limits[0].bandwidths[0].refill-speed=greedy # [greedy,interval]
bucket4j.filters[0].metrics.enabled=true
bucket4j.filters[0].metrics.types=CONSUMED_COUNTER,REJECTED_COUNTER # (optional) if your not interested in the consumed counter you can specify only the rejected counter
bucket4j.filters[0].metrics.tags[0].key=IP
bucket4j.filters[0].metrics.tags[0].expression=getRemoteAddr()
bucket4j.filters[0].metrics.tags[0].types=REJECTED_COUNTER # (optional) this tag should for example only be applied for the rejected counter
bucket4j.filters[0].metrics.tags[1].key=URL
bucket4j.filters[0].metrics.tags[1].expression=getRequestURI()
bucket4j.filters[0].metrics.tags[2].key=USERNAME
bucket4j.filters[0].metrics.tags[2].expression=@securityService.username() != null ? @securityService.username() : 'anonym'The refill speed defines the period of the regeneration of consumed tokens. This starter supports two types of token regeneration. The refill speed can be set with the following property:
bucket4j.filters[0].rate-limits[0].bandwidths[0].refill-speed=greedy # [greedy,interval]-
greedy: This is the default refill speed and tries to add tokens as soon as possible.
-
interval: You can alternatively chose interval for the token regeneration which refills the token in a fixed interval.
You can read more about the refill speed in the official documentation.
If multiple rate limits are defined the strategy defines how many of them should be executed.
bucket4j.filters[0].strategy=first # [first, all]The first is the default strategy. This the default strategy which only executes one rate limit configuration. If a rate limit configuration is skipped due to the provided condition. It does not count as an executed rate limit.
Skip and Execution Predicates can be used to conditionally skip or execute the rate limiting. Each predicate has a unique name and a self-contained configuration. The following section describes the build in Execution Predicates and how to use them.
The Path Predicate takes a list of path parameters where any of the paths must match. See PathPattern for the available configuration options. Segments are not evaluated further.
bucket4j.filters[0].rate-limits[0].skip-predicates[0]=PATH=/hello,/world,/admin
bucket4j.filters[0].rate-limits[0].execute-predicates[0]=PATH=/hello,/world,/adminMatches the paths '/hello', '/world' or '/admin'.
The Method Predicate takes a list of method parameters where any of the methods must match the used HTTP method.
bucket4j.filters[0].rate-limits[0].skip-predicates[0]=METHOD=GET,POST bucket4j.filters[0].rate-limits[0].execute-predicates[0]=METHOD=GET,POST
Matches if the HTTP method is 'GET' or 'POST'.
The Query Predicate takes a single parameter to check for the existence of the query parameter.
bucket4j.filters[0].rate-limits[0].skip-predicates[0]=QUERY=PARAM_1 bucket4j.filters[0].rate-limits[0].execute-predicates[0]=QUERY=PARAM_1
Matches if the query parameter 'PARAM_1' exists.
The Header Predicate takes to parameters.
-
First - The name of the Header Parameter which must match exactly
-
Second - An optional regular expression where any existing header under the name must match
bucket4j.filters[0].rate-limits[0].execute-predicates[0]=Content-Type,.*PDF.*
Matches if the query parameter 'PARAM_1' exists.
You can also define you own Execution Predicate:
@Component
@Slf4j
public class MyQueryExecutePredicate extends ExecutePredicate<HttpServletRequest> {
private String query;
public String name() {
// The name which can be used on the properties
return "MY_QUERY";
}
public boolean test(HttpServletRequest t) {
// the logic to implement the predicate
boolean result = t.getParameterMap().containsKey(query);
log.debug("my-query-parameter;value:%s;result:%s".formatted(query, result));
return result;
}
public ExecutePredicate<HttpServletRequest> parseSimpleConfig(String simpleConfig) {
// the configuration which is configured behind the equal sign
// MY_QUERY=P_1 -> simpleConfig == "P_1"
//
this.query = simpleConfig;
return this;
}
}To differentiate incoming request (e.g. by IP address) you can provide an expression which is used as a key resolver for the underlying cache.
Depending on the filter method [servlet, webflux, gateway] different SpEL root objects can be used in the expression so that you have a direct access to the method of these request objects:
-
servlet: jakarta.servlet.http.HttpServletRequest (e.g. getRemoteAddr() or getRequestURI())
-
webflux: org.springframework.http.server.reactive.ServerHttpRequest
-
gateway: org.springframework.http.server.reactive.ServerHttpRequest
The configured URL which is used for filtering is added to the cache-key to provide a unique cache-key for multiple URL. You can read more about it here.
Limiting based on IP-Address:
getRemoteAddress()Limiting based on Username - If not logged in use IP-Address:
@securityService.username()?: getRemoteAddr()/**
* You can define custom beans like the SecurityService which can be used in the SpEl expressions.
**/
@Service
public class SecurityService {
public String username() {
String name = SecurityContextHolder.getContext().getAuthentication().getName();
if(name.equals("anonymousUser")) {
return null;
}
return name;
}
}If you define a post execution condition the available tokens are not consumed on a rate limit configuration execution. It will only estimate the remaining available tokens. Only if there are no tokens left the rate limit is applied by. If the request was proceeded by the application we can check the return value check if the token should be consumed.
Example: You want to limit the rate only for unauthorized users. You can’t consume the available token for the incoming request because you don’t know if the user will be authenticated afterward. With the post execute condition you can check the HTTP response status code and only consume the token if it has the status Code 401 UNAUTHORIZED.
Sometimes it might be useful to modify filter configurations during runtime. In order to support this behaviour a cache-based configuration update system has been added. The following section describes what configurations are required to enable this feature.
In order to dynamically update rate limits, it is required to enable caching for filter configurations.
bucket4j.filter-config-caching-enabled=true #Enable/disable caching of filter configurations.
bucket4j.filter-config-cache-name=filterConfigCache #The name of the cache where the configurations are stored. Defaults to 'filterConfigCache'.-
When filter caching is enabled, it is mandatory to configure a unique id for every filter.
-
Configurations are implicitly replaced based on a combination of the major and minor version. If changes are made to the configuration without increasing either of the version numbers, it is most likely that the changes will not be applied. Instead the cached configuration will be used.
bucket4j.filters[0].id=filter1 #The id of the filter. This should always be a unique string. bucket4j.filters[0].major-version=1 #[min = 1, max = 92 million] Major version number. bucket4j.filters[0].minor-version=1 #[min = 1, max = 99 billion] Minor version number. (intended for internal updates, for example based on CPU-usage, but can also be used for regular updates)
For each ratelimit a tokens inheritance strategy can be configured. This strategy will determine how to handle existing rate limits when replacing a configuration. If no strategy is configured it will default to 'RESET'.
Further explanation of the strategies can be found at Bucket4J TokensInheritanceStrategy explanation
bucket4j.filters[0].rate-limits[0].tokens-inheritance-strategy=RESET #[RESET, AS_IS, ADDITIVE, PROPORTIONALLY]This property is only mandatory when BOTH of the following statements apply to your configuration.
-
The rate-limit uses a different TokensInheritanceStrategy than 'RESET'
-
The rate-limit contains more than 1 bandwidth
This is required so Bucket4J knows how to map the current bandwidth tokens to the updated bandwidths. It is possible to configure id’s when 'RESET' strategy is applied, but the id’s should still be unique within the rate-limit then.
bucket4j.filters[0].rate-limits[0].bandwidths[0].id=bandwidthId #The id of the bandwidth; Optional when the rate-limit only contains 1 bandwidth or when using tokensInheritanceStrategy.RESET.An example on how to dynamically update a filter can be found at: Caffeine example project.
Some important considerations:
-
This is an experimental feature and might be subject to changes.
-
Configurations will be read from the cache during startup (when using a persistent cache). This means that putting corrupted configurations into the cache during runtime can cause the application to crash during startup.
-
Most configuration errors can be prevented by using the Jakarta validator to validate updated configurations. In the example this is done by adding @Valid to the request body method parameter, but it is also possible to @Autowire the Validator and use it directly to validate the configuration.
-
Some Filter properties are not intended to be modified during runtime. To simplify validating a configuration update the Bucket4JUtils.validateConfigurationUpdate method has been added. This method executes the following validations and will return a ResponseEntity:
-
old configuration != null → NOT_FOUND
-
new configuration has a higher version than the old configuration → BAD_REQUEST
-
filterMethod not changed → BAD_REQUEST
-
filterOrder not changed → BAD_REQUEST
-
cacheName not changed → BAD_REQUEST
-
-
The configCacheManager currently does not contain validation in the setValue method. The configuration should be validated before calling the this method.
Spring Boot ships with a great support for collecting metrics. This project automatically provides metric information about the consumed and rejected buckets. You can extend these information with configurable custom tags like the username or the IP-Address which can then be evaluated in a monitoring system like prometheus/grafana.
bucket4j:
enabled: true
filters:
- cache-name: buckets
filter-method: servlet
filter-order: 1
url: .*
metrics:
tags:
- key: IP
expression: getRemoteAddr()
types: REJECTED_COUNTER # for data privacy reasons the IP should only be collected on bucket rejections
- key: USERNAME
expression: "@securityService.username() != null ? @securityService.username() : 'anonym'"
- key: URL
expression: getRequestURI()
rate-limits:
- execute-condition: "@securityService.username() == 'admin'"
cache-key: "@securityService.username()?: getRemoteAddr()"
bandwidths:
- capacity: 30
time: 1
unit: minutesThis section is meant to help you migrate your application to new version of this starter project.
-
Removed deprecated 'bucket4j.filters[x].rate-limits[x].expression' property. Use 'bucket4j.filters[x].rate-limits[x].cache-key' instead.
-
three new metric counter are added per default (PARKED, INTERRUPTED and DELAYED)
-
Upgrade to Spring Boot 3
-
Spring Boot 3 requires Java 17 so use at least Java 17
-
Replaced Java 8 compatible Bucket4j dependencies
-
Exclude example webflux-infinispan due to startup problems
The version 0.8 tries to be compatible with Java 8 as long as Bucket4j is supporting Java 8. With the release of Bucket4j 8.0.0 Bucket4j decided to migrate to Java 11 but provides dedicated artifacts for Java 8. The project is switching to the dedicated artifacts which supports Java 8. You can read more about it here.
The property ..rate-limits[0].expression is renamed to ..rate-limits[0].cache-key. An Exception is thrown on startup if the expression property is configured.
To ensure that the property is not filled falsely the property is marked with @Null. This change requires a Bean Validation implementation.
To ensure that the Bucket4j property configuration is correct an Validation API implementation is required. You can add the Spring Boot Starter Validation which will automatically configures one.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>The refill speed of the Buckets can now configured explicitly with the Enum RefillSpeed. You can choose between a greedy or interval refill see the official documentation.
Before 0.8 the refill speed was configured implicitly by setting the fixed-refill-interval property explicit.
bucket4j.filters[0].rate-limits[0].bandwidths[0].fixed-refill-interval=0
bucket4j.filters[0].rate-limits[0].bandwidths[0].fixed-refill-interval-unit=minutesThese properties are removed and replaced by the following configuration:
bucket4j.filters[0].rate-limits[0].bandwidths[0].refill-speed=intervalYou can read more about the refill speed configuration here Refill Speed
The following list contains the Caching implementation which will be autoconfigured by this starter.
Reactive |
Name |
cache-to-use |
N |
jcache |
|
Yes |
jcache-ignite |
|
no |
hazelcast-spring |
|
yes |
hazelcast-reactive |
|
Yes |
infinispan |
|
No |
redis-jedis |
|
Yes |
redis-lettuce |
|
Yes |
redis-redisson |
Instead of determine the Caching Provider by the Bucket4j Spring Boot Starter project you can implement the SynchCacheResolver or the AsynchCacheResolver by yourself.
You can enable the cache auto configuration explicitly by using the cache-to-use property name or setting it to an invalid value to disable all auto configurations.
bucket4j.cache-to-use=jcache #Simple configuration to allow a maximum of 5 requests within 10 seconds independently from the user.
bucket4j:
enabled: true
filters:
- cache-name: buckets
url: .*
rate-limits:
- bandwidths:
- capacity: 5
time: 10
unit: secondsConditional filtering depending of anonymous or logged in user. Because the bucket4j.filters[0].strategy is first you don’t have to check in the second rate-limit that the user is logged in. Only the first one is executed.
bucket4j:
enabled: true
filters:
- cache-name: buckets
filter-method: servlet
url: .*
rate-limits:
- execute-condition: @securityService.notSignedIn() # only for not logged in users
cache-key: "getRemoteAddr()"
bandwidths:
- capacity: 10
time: 1
unit: minutes
- execute-condition: "@securityService.username() != 'admin'" # strategy is only evaluate first. so the user must be logged in and user is not admin
cache-key: @securityService.username()
bandwidths:
- capacity: 1000
time: 1
unit: minutes
- execute-condition: "@securityService.username() == 'admin'" # user is admin
cache-key: @securityService.username()
bandwidths:
- capacity: 1000000000
time: 1
unit: minutesConfiguration of multiple independently filters (servlet|gateway|webflux filters) with specific rate limit configurations.
bucket4j:
enabled: true
filters: # each config entry creates one servlet filter or other filter
- cache-name: buckets # create new servlet filter with bucket4j configuration
url: /admin*
rate-limits:
bandwidths: # maximum of 5 requests within 10 seconds
- capacity: 5
time: 10
unit: seconds
- cache-name: buckets
url: /public*
rate-limits:
- cache-key: getRemoteAddress() # IP based filter
bandwidths: # maximum of 5 requests within 10 seconds
- capacity: 5
time: 10
unit: seconds
- cache-name: buckets
url: /users*
rate-limits:
- skip-condition: "@securityService.username() == 'admin'" # we don't check the rate limit if user is the admin user
cache-key: "@securityService.username()?: getRemoteAddr()" # use the username as key. if authenticated use the ip address
bandwidths:
- capacity: 100
time: 1
unit: seconds
- capacity: 10000
time: 1
unit: minutes