flexmeasures.api.common.rate_limiting
Rate limiting for the FlexMeasures API.
Two limits apply:
a generous default limit on every endpoint under
/api/, anda stricter limit on the endpoints that trigger expensive computation (scheduling and forecasting).
Both are configurable (see FLEXMEASURES_API_DEFAULT_RATE_LIMIT and FLEXMEASURES_API_TRIGGER_RATE_LIMIT),
and both can be overridden per account, by assigning the account a Plan with
default_rate_limit and/or trigger_rate_limit set (see flexmeasures.data.models.user.Plan).
The special value “unlimited” exempts an account from a limit.
The two limits count differently. The default limit counts every request, including those we refuse (so that a client hammering us with bad credentials is bounded, too). The trigger limit only counts triggers we accepted, because it exists to protect the expensive computation which those set in motion: a client whose payload we rejected did not cost us a schedule, and should not pay for one.
Note that the limiter runs before authentication, so unauthenticated callers are counted by IP address.
Functions
- flexmeasures.api.common.rate_limiting.default_key_func() str
Count requests against the user, or against the IP address if unauthenticated.
- flexmeasures.api.common.rate_limiting.limit_triggers()
Decorator for endpoints which trigger expensive computation, like scheduling.
- flexmeasures.api.common.rate_limiting.rate_limit_exceeded_handler(error)
Respond to a hit rate limit like we respond to other API errors.
The Retry-After and X-RateLimit-* headers are added by the limiter itself, after this request.
- flexmeasures.api.common.rate_limiting.register_at(app: Flask)
Set up rate limiting, storing counts in the Redis we already connected to.