id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
37288	Add first-class rate limiting support for Django views	Bader Eddine Benhirt		"Django currently doesn't provide a built-in general-purpose mechanism for rate limiting HTTP views.

Applications that need to protect endpoints against excessive requests currently rely on third-party packages, custom middleware, reverse proxies, or framework-specific solutions such as Django REST Framework throttling.

I propose adding a small, framework-level rate limiting abstraction to Django that can be used by regular function-based and class-based views.

A possible API could look like:


{{{
@rate_limit(""api"")
def index(request):
    ...


@rate_limit(""api"", methods={""POST"", ""PUT""})
def edit(request):
    ...


@rate_limit(""exports"", tokens=5)
def export(request):
    ...

Rate limit policies could be defined centrally in settings:

RATE_LIMITS = {
    ""api"": {
        ""rate"": ""100/m"",
        ""key"": ""ip"",
    },
    ""exports"": {
        ""rate"": ""10/h"",
        ""key"": ""user"",
    },
}

}}}

When a request exceeds its configured limit, Django could return an HTTP 429 Too Many Requests response and optionally include a Retry-After header.

The implementation should ideally support:

function-based views and class-based views.

    - authenticated-user and IP-based keys.
    - custom callable keys.
    - HTTP-method-specific limits.
    - multiple rate limits on the same view.
    - configurable request/token cost.
    - Django's cache abstraction as a storage backend.
    - synchronous and asynchronous views.
    - 429 Too Many Requests and Retry-After.
    - safe and clearly documented concurrency semantics.

There is already ticket #21289 concerning login rate limiting in contrib.auth, but this proposal would provide a more general primitive for Django HTTP views rather than being specific to authentication.

Similar declarative approaches now exist in other frameworks. For example, Symfony 8.1 introduced a controller-level #[RateLimit] attribute. This proposal would not aim to reproduce Symfony's API, but rather explore a Django-native equivalent.

An important design question is whether this belongs in Django core or should remain a third-party package. If considered suitable for core, I would be interested in working on the implementation."	New feature	new	HTTP handling	6.1	Normal		rate-limiting security http views middleware cache	Bader Eddine Benhirt	Unreviewed	0	0	0	0	0	0