Hi all,
I have finished a first draft of my proposal for adding rate-limiting to core, and I wanted to run it by the mentors and the community before I submit it.
How is it looking for a first draft? Please let me know if some parts are unclear. The link is (same as above) - GSoC 2022 Django Proposal - Google Docs
Thanks for your help!
Hi @hrushikeshrv — thanks for this — Initial glance looks good. I shall have a longer read over the weekend. 
Thanks for your feedback!
HI @hrushikeshrv.
I had two main thoughts from the draft proposal:
You’re taking a lot of inspiration from django-ratelimit. That’s OK, but it might be good to specify what are non-goals for this project, and so what the space is for third party packages after the project (if any). Is there a base target and then a stretch goal? What do you feel confident to get done vs what’s more ambitious? (Thinking in these terms should help to give a little life to the schedule outline.
On the security side, I guess the big issue is the DoS possibility (rather than the IP address identification issue). Given that, sure, don’t enable by default… But the original motivation here is the ticket to add some kind of rate-limiting to the provided login views. Is there nothing we safely can do by default here? Something maybe not perfect but better than nothing? — You don’t necessarily need an answer here already, but an approach to the Django-developers mailing list explaining the issue, and asking input would start a discussion, and show you’d thought it through clearly to this point already. (Part of the project can be getting input from experienced community members.)
I hope that helps.
Kind Regards,
Carlton
Thanks @carltongibson, that helps me reorient the proposal a little bit. The proposal timeline was a little lackluster, but I wasn’t sure what was missing.
I do have a few ideas about the default rate limiting for authentication views, but I’m not so sure if they will be our best option. I’ll post on the developers’ mailing list soon, get some feedback, and incorporate it into the proposal.
Thank you for your help!
Hi @hrushikeshrv — Super
Yeah… — it doesn’t have to be the final implementation already at this stage… — there’s a whole project ahead 
But some ideas are good to prime a good response (I hope that makes sense.)
Kind Regards,
Carlton
@hrushikeshrv Let’s see what the mailing list says, but make sure you read the previous discussion e.g. https://groups.google.com/g/django-developers/c/_BG3Df0gKGc/m/uJLl_b4CCgAJ — there’s some good points there. C.
@carltongibson Yes, that thread and the discussion on the WIP PR did give me an idea that I think would be good approach to add basic rate-limiting to authentication. Now that we will have a more extensive rate-limiting API thanks to this project, we will be able to set a reasonable small rate limit by default, something like 15 requests per minute, and allow users to completely customize any parameter they want. I think that doing it this way takes into consideration most of the points raised in the mailing list thread, including what @adamchainz says in this message about mis-selection of credentials, and having buckets of requests per time period.
Moreover, another thing we can do for users with more advanced needs is allow them to implement their own rate-limiting logic using the low-level API that will be developed as part of this project. Since I plan to add rate-limiting to the AuthenticationForm using this low-level API itself, we could have the default implementation, or users could pass their own rate-checking function that will be run instead of the default check.
These ideas came to me very recently, so they may have some holes possibly, but I think they sound reasonable. What do you think?
I think, at this stage, outlining the options, and problems/unknowns, plus allowing some time at the beginning of the project to narrow these down is OK. (Part of the fun is in working it out 
)
Got it! I’ve done that and I think I’m almost done with the proposal, too. I’ve just added a few paragraphs to the Project Specification and Implementation Details, and reorganized the timeline. Could you please take a look at the final draft? (same link - GSoC 2022 Proposal - Google Docs)
Thank you so much for your help!
Hi @hrushikeshrv I don’t know if you looked at django-axes already.
Just wanted to make sure you’d seen it.
Yes, I’ve actually used it in a project before to implement login rate-limiting.
Hi @carltongibson, I got to know that my proposal for rate-limiting wasn’t accepted this year. I was excited to be working on this project, but nevertheless, I will maintain the same excitement while applying again next March!
Could you please give me some feedback about my proposal, maybe some places it could have been better or fell short, so I could avoid that next year?
Also, is there any way I can still work on parts of this project - like maybe adding a basic rate-limit to the AuthenticationForm? The mailing list hasn’t reached a consensus yet, but it would be helpful to have some rate-limiting solution included by default that users can turn off. In either case, thank you so much your help while I was writing my proposal. I will be applying again next year!
Hey @hrushikeshrv — thanks for the follow-up. Sorry your proposal wasn’t picked up this time.
The mailing list hasn’t reached a consensus yet…
I think that’s the issue currently. It seems there are as many different opinions as there are folks to ask, and so it’s difficult to see the way forward. The next stage here is more discussion on options, but that needs to happen before a project… — I feel bad, because your proposal was good, but it’s too open still.
One example raised was UI: do we simply block requests after a cut-off, or so we offer some sort of Captcha, to allow people just typing it in badly? — I’m not sure that was something desired or targeted, but it was raised as a Not considered.
A good question would be, what do they do in Rails-land ? A simple cached value per-URL likely isn’t a big DoS vector (any more that various others that already exist) so if we can show what’s used in other frameworks without issue there’s a case for doing similar in Django.
Then, a basic solution for some views ·e.g. the log-in views, as a proof-of-concept might be worth putting together. That allows folks to opt-in, and give it a try. This is often the way to get things moving forward.
Maybe the topic is too variable for core, and then keeping third-party packages in play would be the way forward. This would be to close the original ticket as wontfix — but if we have to go that way I’d want a decent topic page pointing folks to solutions — I think that not having any story here is a gap.
The danger is always that the idea grows in scope until there are too many variables to reach an agreement. Pinning it down to something small and concrete is the antidote to that.
Make sense?
Thanks for your response. I agree that the topic itself has a lot of variables that make it hard to reach agreement on the exact implementation.
Can we do this now before we decide to close the ticket as a wontfix? Since the mailing list discussion hasn’t reached a conclusion and the ticket is already a few years old. If we do reach an agreement, we can always remove/update it.
Yes, that’s the if we can’t fix it solution.
If you wanted to draft that up, I’d be happy to review, and it would be a good contribution!
Normally we don’t reference third-party packages, but I think in this case it would be valuable to link to django-axes and django-ratelimit (and others?) as mature options.