Re: Improvements to the startproject template

[Hrushikesh Vaidya]

+1 for the config option with a custom users app

On Thursday, 21 April 2022 at 00:52:53 UTC+5:30 olivier...@gmail.com wrote:

> +1 for Adam's suggestion, I use it as well and like it very much.
>
> > root folder
> - manage.py
> - ...
> > myproject
> - __init__.py
> - settings.py
> - urls.py
> - ...
> > myapp
> - __init__.py
> - models.py
> - ...
>
> Pros:
> - everything is well namespaced under myproject (`myproject.settings`, 
> quite straightforward)
> - makes it clear that `settings.py`, `urls.py`, etc. concern the project 
> as a whole, and not just an app.
> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear 
> that myapp is part of this project)
> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so 
> the actual source stays clean from such files.
> - having a parent package allows (does not require) relative imports 
> across modules of the same project, which more clearly conveys that such 
> apps are tightly coupled
> - with manage.py still in the root folder, you don't need to cd into any 
> folder to start working
>
> I use it all the time.
>
> Cheers,
>
> Olivier
>
>
>
>
> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>
>> I prefer Adam's suggestion in the forum post as it lets you namespace 
>> everything under your project name nicely and avoids package name 
>> collisions, although it doesn't solve the problem of having two directories 
>> with the same name by default.
>>
>> That said, either would be an improvement on what we have so I'm in 
>> favour of either approach over doing nothing.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 20 Apr 2022 at 16:49, John M  wrote:
>>
>>> I do exactly this for every new Django project, so it's +1 from me as 
>>> well.
>>>
>>> John
>>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>>
>>> +1 for me - this would be really useful.
>>>
>>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org 
>>> wrote:
>>>
 Hi Tim,

 This feels like a good idea to me.

 Regards,
 Ian

 On Mon, 18 Apr 2022 at 18:17, Tim Allen  
 wrote:

> Greetings, friends! 
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such 
>as `settings.py`, `wsgi.py`, and the 
>root `urls.py` in `my_project/my_project`, they are created 
>in `my_project/config` 
>- start the project with a custom User model app, `users` 
>
> Over the years, I've taught or tutored over 100 Djangonauts starting 
> their first project. Having to distinguish between two directories with 
> the 
> same name is a constant pain point in the teaching process - "cd into 
> my_project ... no, the other one!"
>
>- The `config` option seemed to be the consensus from this thread 
>in the forum: Django New Project Structure/Name - Using Django - 
>Django Forum (djangoproject.com) 
>
> 
>  
>- Ticket: https://github.com/django/django/pull/15609 
>
> It is sometimes better to show rather than tell, so following our own 
> documentation and including a custom User model with the initial project 
> template reinforces the best practice that we explicitly point out in the 
> documentation.
>
>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) – 
>Django (djangoproject.com) 
> 
>- Avoids ever having this come up again: 
>
> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>  
>
> Here's a link to the PR: https://github.com/django/django/pull/15609
>
> My apologies for not starting with a discussion first. I'm an 
> infrequent contributor to the Django codebase!
>
> Regards,
>
> Tim
>
 -- 
> You received this message because you are subscribed to the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.com
>  
> 
> .
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to 

Re: Ticket #21289 - Login rate limiting

[Hrushikesh Vaidya]

On Tuesday, 5 April 2022 at 19:34:54 UTC+5:30 jacob...@gmail.com wrote:

>
>- Django doesn't have to store any state of users and/or IP addresses 
>attempting to log in
>
> We would still have to keep track of the rate of requests made by each 
user and/or IP if we want to respond with a > 400 
status code for a malicious client who bypasses the disabled button. So in 
effect this seems like rate-limiting on the backend
as well as (somewhat) on the frontend. Plus we would have to maintain some 
extra bit of JavaScript, and the quirks that come with it.

In my opinion, limiting the rate of requests to a small amount per minute 
should be a good enough initial solution,
and also solves the challenges raised in the discussion so far (to some 
extent).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2969d9d7-d55a-44a1-999a-d987fc29c572n%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

[Hrushikesh Vaidya]

Hi all,
I'm trying to work on adding rate-limiting to core as part of this year's 
GSoC, and I'd like to work on this 
ticket as a part of the project. I'm aiming to write an API for 
rate-limiting (which is a lot like django-ratelimit merged into core),
which we could use to add some default rate-limiting to the 
AuthenticationForm.

It seems like it's hard to add rate limiting to the form without 
introducing a DoS vector. The ideal solution would be a soft block
like a captcha, but that is not currently possible to do in the core. For 
now, I propose that we allow a small amount of login attempts
per minute - maybe 10 or so attempts per minute for each username and IP 
considered together, and then rate-limit using a fixed window.
The IP would come from a user-specified header configured by a setting.

I think this would work better for good actors by allowing them to try 
again immediately after a few incorrect passwords, and limit bad actors 
significantly.
We will make the rate, the key, etc. for the enforced rate-limit 
customizable, as you can read in my proposal for the implementation here 

.

Thanks,
Hrushikesh

On Monday, 27 July 2020 at 20:25:35 UTC+5:30 Adam Johnson wrote:

> Hi Claude,
>
> A delay of 5 seconds seems quite long. Often I fail to log into a site due 
> to mis-selection of credentials from my password manager, so I can resubmit 
> a login form within 1-2 seconds. A real rate-limiting solution has the 
> advantage of buckets of requests per time period, allowing users a few 
> rapid attempts before being locked.
>
> Additionally, the default PBKDF2 hasher already enforces a (smaller) 
> arbitrary delay via its algorithm iterations. I can't find a source but I 
> think I remember reading it should be tuned to take about 100ms. This is 
> about 1.5 orders of magnitude less than a 5 second delay, which is perhaps 
> not so significant in terms of password brute-forcing (less difference than 
> one extra password character). Not sure if 100ms is where Django's current 
> default ends up on a modern CPU, but we probably aren't far off given we 
> increase the iterations according to a formula that roughly tracks Moore's 
> law.
>
> I'd rather see something like django-ratelimit merged to core. It's more 
> general purpose so users can reuse and customize it, and we could 
> potentially use it for other features in Django too.
>
> Thanks,
>
> Adam
>
> On Mon, 27 Jul 2020 at 12:13, Claude Paroz  wrote:
>
>> Hi all,
>>
>> I thought a bit about login rate limiting again in recent times.
>> https://code.djangoproject.com/ticket/21289
>>
>> We know that there are some packages (django-ratelimit, django-defender,
>> etc.) that can do the job, but the main issue here is to provide a
>> *default* behavior for any fresh new Django project.
>>
>> A must-read on this subject is:
>> https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
>>
>> I would like to suggest one mitigation measure for default Django, which
>> seems to me the least controversial, considering that hard-locking by
>> username and/or ip address can open Denial of Service vectors which may
>> or may not be acceptable for some sites.
>>
>> My suggestion is to add a time delay of 5 seconds in the
>> contrib.auth.forms.AuthenticationForm after the first failure on any
>> username. This choice of 5 seconds is a compromise between not too much
>> annoying users after a failed login attempt, and still set a significant
>> throttling limit for some brute force attacks. You can consider that
>> after a failed login, a real user will spend at least 2-3 seconds just
>> to re-enter a new password and re-submit the form, so the real wait
>> penalty should not be more than 2-3 seconds.
>>
>> This is of course NOT the panacea against all type of brute force
>> attacks, as you can read on the OWASP article above. But it appears to
>> me as a reasonable measure that can be widely accepted by most Django
>> projects that use the default authentication form.
>>
>> The WIP PR is available here:
>> https://github.com/django/django/pull/13242
>>
>> Kind regards,
>>
>> Claude
>> -- 
>> www.2xlibre.net
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/49b80757-9117-fa11-3f53-731af1f0c206%402xlibre.net
>> .
>>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the 

Re: Proposals of GSOC.

[Hrushikesh Vaidya]

This  is the one 
listed in the wiki.
This  is 
one from last year.
This  
is one from 2020.

On Thursday, 10 March 2022 at 09:04:59 UTC+5:30 sarthak...@gmail.com wrote:

> Can anyone share me old proposals of GSOC for django software application. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/90c88f01-44ff-4c52-af48-611fb753e812n%40googlegroups.com.

GSoC 2022 project viability - adding rate-limiting to core

[Hrushikesh Vaidya]

As per this discussion 

 
on the Django Forum, there is some concern about adding 
rate-limiting to core as a part of this year's GSoC. The project is listed 
on this wiki page 

. 

The main concern is, paraphrasing @claudep, that it would be very easy to 
introduce DoS
vectors to pretty much all Django applications if rate-limiting is not 
used/configured 
properly. If users currently use a third party application to implement 
rate-limiting, its 
security is their responsibility. But if we add rate-limiting to core, it 
would become our 
responsibility to make sure that we don't introduce DoS vectors to 
unsuspecting users' 
applications.

I would love to work on this project, but I wanted to address this risk and 
confirm that this 
project is still viable.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfaacfda-c359-4c89-9f3b-e9c05a2c0766n%40googlegroups.com.