Feedback/Discussion for Adding Rate-Limiting to Core - GSoC 2022

Django Internals Mentorship
1

Hi all, I’ve started this discussion to get a better idea of the project specifications for this year’s GSoC project on adding rate-limiting to core. I find this idea very exciting! In my opinion, django-ratelimit is a great example of exactly how we may want to implement rate-limiting, but I wanted to raise a few points for discussion.

  1. The primary way to use rate-limiting would be via a decorator, just like the one provided by django-ratelimit. Would we want some other way to use it, maybe a mixin for CBVs?

  2. django-ratelimit provides custom middleware to handle rate-limited requests. Would we want to provide that same middleware in the core? That does seem to make sense, but I wanted to make sure that others agree.

  3. django-ratelimit's decorators allow you to “group” together views and set combined rate-limits on them. Do we want to have that as an option in core? I, personally, don’t see much value coming from it, but maybe someone does find it useful.

Moreover, I have a few ideas beyond what the third party package provides -

  1. A setting to allow the user to choose whether they want to use the cache or the database for rate-limit checks. django-axes provides an option like this one.

  2. A setting to set the default value for the rate-limit. Users will be able to override this per-view, but a global default might also be useful.

I’d love to hear everyone’s feedback :smiley:

2

Another idea, as suggested in the mailing list thread for adding rate-limiting to contrib.auth, is adding a default rate-limiting solution for every new Django project.

a “battery-included” framework like Django should include at least a basic brute force protection.

A new boolean setting that turns on/off basic rate-limiting for the AuthenticationForm would be useful. This would of course be on top of the more general purpose rate-limiting API that this project will provide, and this API should be able to override this generic protection.

3

I’d imagine a middleware solution, setting a default, customisable by per-view.

Check out @claudep’s draft PR, and the discussion on that.

Checkout the issues (and the history of issues) on django-ratelimit. Are there issues that keep coming up? I don’t know the answer there without looking, but if that project could start fresh, what would you/they do different? (We have a chance to learn)

What’s a realistic scope for your GSoC project? (Beware too many feature. Equally be ambitious.)

Given that there’s already some prior art here, a good proposal will show that it’s taken into account previous attempts.

But, beyond that, you’re free to suggest an API that you thinks works. (What would you want to write as a user of Django when you’re working on your site?)

HTH

1 Like
4

The main difficulty for core integration is that rate-limiting is very easily adding new DOS vectors to applications. So if you decide to rate limit your app with a third party app like django-ratelimit, it’s your responsibility to do it and YOU take the risk (and can quickly uninstall the third-party if needed). If the functionality is integrated into Django core, suddenly it’s Django responsibility to ensure that no DOS vectors are added more or less by default to all Django applications. Ouch…

1 Like
5

That is true. We will have to document this risk explicitly and extensively, and advise users to only use rate-limiting when when no DoS can occur.

6

@claudep not committing you to anything, do you think these issues insurmountable? (High-level takes) Thanks.

7

Difficult to say. Developers mailing list may tell us more…