Re: Adding a security concerned feature

[Arvind Nedumaran]

A security model doesn’t necessarily have to be any one thing that’s 
100% secure. It can be a combination of things which include 
“actual” security features as well as plain ol’ obscurity.


If I have to register the admin urls on a project, I make sure to setup 
django-honeypot and move the admin site to something non-standard.


Any one thing may not be doing much on it’s own. But the combination, 
if messy enough to make someone give up, will give you a better overall 
security situation.


Just my 2¢.

Onward,
Arvind

On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:


FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
compelling argument for recommending developers to change the default
"/admin" url.  Any security concerns would hopefully be addressed by 
actual
security safeguards rather than changing names to something 
non-standard.


On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 
carlton...@gmail.com

wrote:


On this topic, a ticket proposing to prepend the project name to the
`admin/` URL in the default project template was opened.
https://code.djangoproject.com/ticket/32209

Given that it's the exact discussion we're having here, I've paused 
that

to see if there's a consensus for a change.

Thanks. C.

On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com 
wrote:


 I've got this idea with the usage of json files that require some 
keys
which is authenticated for a single user which seems to excite me 
for fact
that if this was similar for admin/, then it'd give django a 
overhead

advantages for future use.

On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
wrote:


I think I'd come down as -1 for a system check here...

They're not costless, there's a tendency to want to add a new 
system
check for every possible configuration choice, but, beyond 
implementing and

maintaining, the danger is it leads to too much noise.
If you get a system check warning, you shouldn't be tempted to 
ignore
it. In general I think reserving the built-in checks slightly means 
they
don't get devalued. (Folks are free, and encouraged, to implement, 
and

share, their own checks to enforce project-level standards.)

I think it's not sufficiently clear-cut that using `/admin/` is a 
bad

idea to justify including a check.

(On a personal note, I like to use `/admin/`, configure nginx to 
only
serve the admin from the localhost, and then use an SSH tunnel to 
access it

remotely, so I'd have to silence a system check here.)

C.

On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
wrote:



Hi,

I wasn't convinced about changing the 'admin' path until recently. 
My

reasons to change the path of 'admin' are:

-A bit less likely to be affected by bugs like

https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
: at least the site wouldn't appear in automatic scans for
vulnerabilities (if checking Django versions based on the admin
template, etc.) . The bug/exploit might have been known before the 
fix
was implemented (and everyone updated) so I prefer to not be 
exposed

(or
less exposed)

-At the moment in Django there is no rate-limiting login attempts 
"out

of the box" so I prefer to avoid the opportunity if possible

-Partially out of my control: an 'admin' user might have used the 
same

password in another place and the password got leaked

Other people might have other reasons.

Cheers,

On Nov/18/2020, Tim Graham wrote:
I'm not convinced that a system check promoting security by 
obscurity

adds
much value. The original poster wrote "sometimes it can be a 
security
concern." Maybe that's the case (how so?) but for most sites I 
would

say

it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina

Estany

wrote:



Hi,

On Nov/16/2020, Carles Pina i Estany wrote:


Either way: I'd be happy to write a django check to make sure

that

'admin/' is not routed to admin.


Regarding this check: this morning I've done a very 
preliminary/for

fun

draft to play with.




https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1


I'm not sure what is the best way to check if /admin is routed 
to

django.contrib.admin. At the moment it's doing:

resolve(admin_url)._func_path == 
'django.contrib.admin.sites.index'


Yes, I know! :-)

I could also do something along the lines of:
resolve(admin_url).func.admin_site == admin.site

This causes problems on the unit test side (need to import

admin.site).

Still I don't really like it.

Does anyone have any better suggestions or comments? (or code

pointer).

Otherwise later on I'll have another look.

Thank you very much,

--
Carles Pina i Estany
https://carles.pina.cat



--
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: Adding a security concerned feature

[r...@whidbey.com]

FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a 
compelling argument for recommending developers to change the default 
"/admin" url.  Any security concerns would hopefully be addressed by actual 
security safeguards rather than changing names to something non-standard.

On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com 
wrote:

> On this topic, a ticket proposing to prepend the project name to the 
> `admin/` URL in the default project template was opened. 
> https://code.djangoproject.com/ticket/32209
>
> Given that it's the exact discussion we're having here, I've paused that 
> to see if there's a consensus for a change. 
>
> Thanks. C.
>
> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>
>>  I've got this idea with the usage of json files that require some keys 
>> which is authenticated for a single user which seems to excite me for fact 
>> that if this was similar for admin/, then it'd give django a overhead 
>> advantages for future use.
>>
>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
>> wrote:
>>
>>> I think I'd come down as -1 for a system check here... 
>>>
>>> They're not costless, there's a tendency to want to add a new system 
>>> check for every possible configuration choice, but, beyond implementing and 
>>> maintaining, the danger is it leads to too much noise. 
>>> If you get a system check warning, you shouldn't be tempted to ignore 
>>> it. In general I think reserving the built-in checks slightly means they 
>>> don't get devalued. (Folks are free, and encouraged, to implement, and 
>>> share, their own checks to enforce project-level standards.)
>>>
>>> I think it's not sufficiently clear-cut that using `/admin/` is a bad 
>>> idea to justify including a check. 
>>>
>>> (On a personal note, I like to use `/admin/`, configure nginx to only 
>>> serve the admin from the localhost, and then use an SSH tunnel to access it 
>>> remotely, so I'd have to silence a system check here.) 
>>>
>>> C.
>>>
>>> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany 
>>> wrote:
>>>

 Hi, 

 I wasn't convinced about changing the 'admin' path until recently. My 
 reasons to change the path of 'admin' are: 

 -A bit less likely to be affected by bugs like 

 https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
  
 : at least the site wouldn't appear in automatic scans for 
 vulnerabilities (if checking Django versions based on the admin 
 template, etc.) . The bug/exploit might have been known before the fix 
 was implemented (and everyone updated) so I prefer to not be exposed 
 (or 
 less exposed) 

 -At the moment in Django there is no rate-limiting login attempts "out 
 of the box" so I prefer to avoid the opportunity if possible 

 -Partially out of my control: an 'admin' user might have used the same 
 password in another place and the password got leaked 

 Other people might have other reasons. 

 Cheers, 

 On Nov/18/2020, Tim Graham wrote: 
 > I'm not convinced that a system check promoting security by obscurity 
 adds 
 > much value. The original poster wrote "sometimes it can be a security 
 > concern." Maybe that's the case (how so?) but for most sites I would 
 say 
 > it's not. 
 > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina 
 Estany 
 > wrote: 
 > 
 > > 
 > > Hi, 
 > > 
 > > On Nov/16/2020, Carles Pina i Estany wrote: 
 > > 
 > > > Either way: I'd be happy to write a django check to make sure 
 that 
 > > > 'admin/' is not routed to admin. 
 > > 
 > > Regarding this check: this morning I've done a very preliminary/for 
 fun 
 > > draft to play with. 
 > > 
 > > 
 > > 
 https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
  
 > > 
 > > I'm not sure what is the best way to check if /admin is routed to 
 > > django.contrib.admin. At the moment it's doing: 
 > > 
 > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index' 
 > > 
 > > Yes, I know! :-) 
 > > 
 > > I could also do something along the lines of: 
 > > resolve(admin_url).func.admin_site == admin.site 
 > > 
 > > This causes problems on the unit test side (need to import 
 admin.site). 
 > > Still I don't really like it. 
 > > 
 > > Does anyone have any better suggestions or comments? (or code 
 pointer). 
 > > Otherwise later on I'll have another look. 
 > > 
 > > Thank you very much, 
 > > 
 > > -- 
 > > Carles Pina i Estany 
 > > https://carles.pina.cat 
 > > 
 > 
 > -- 
 > You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to 

Re: Revisiting Python support for after Django 3.2 LTS

[Andrew Godwin]

I agree we should not be quite so beholden to our existing Python version 
policy - that was mostly to get us out of the early 3.x era. Now things are 
more stable, I'd support a policy that is much more like "any stable version of 
Python currently out there and supported".

Andrew

-- 
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/e1f40b9d-a017-4507-b855-2055713d960e%40www.fastmail.com.

Fellow Reports -- November 2020

[Carlton Gibson]

Hi all. 


Calendar Week 45 -- ending 08 November.


Triaged:

https://code.djangoproject.com/ticket/32174 -- Error page can sometimes be 
very slow (wontfix)
https://code.djangoproject.com/ticket/31508 -- ASGI Lifespan Support 
(wontfix)
https://code.djangoproject.com/ticket/32170 -- Admin select_related is 
different to the models select related (needsinfo)
https://code.djangoproject.com/ticket/31550 -- AssertionError raised by 
test_file_response method of ASGITest class. (Accepted)
https://code.djangoproject.com/ticket/32156 -- Add __class_getitem__ to 
support runtime type parameters for more classes (needsinfo)
https://code.djangoproject.com/ticket/32165 -- Add pre-commit Hooks 
(needsinfo)



Reviewed:

https://github.com/django/django/pull/13647 -- Refs #31910 -- Fixed 
GeoQuerySetTest.test_geoagg_subquery() test on Oracle 18c.
https://github.com/django/django/pull/13557 -- Fixed #31235 -- Updated 
assertQuerysetEqual to compare querysets directly.
https://github.com/django/django/pull/12928 -- Fixed #25791 -- Implement 
autoreload behaviour for cached template loader
https://github.com/django/django/pull/13607 -- Fixed #22276 -- Fixed crash 
when formset management form is invalid.
https://github.com/django/django/pull/13557 -- Fixed #31235 -- Updated 
assertQuerysetEqual to compare querysets directly.
https://github.com/django/django/pull/13389 -- Fixed #31983 -- Added system 
check for file system caches location.
https://github.com/django/django/pull/13201 -- Fixed #30801 -- Added 
examples of alternatives to signals
https://github.com/django/django/pull/13636 -- Implementation of ASGI 
Lifespan protocol
https://github.com/django/django/pull/13629 -- Refs #32061 -- Fixed 
test_crash_password_does_not_leak() crash on Windows.
https://github.com/django/django/pull/13632 -- Fixed #32162 -- Fixed 
setting Content-Length header in AsyncRequestFactory.
https://github.com/django/django/pull/13633 -- 
asgi.tests.ASGITest.test_file_response passes on Windows 10.0.18362



Authored:

https://github.com/django/django/pull/13635 -- Fixed #32159 -- Ensured 
AsyncRequestFactory correctly sets headers.





Calendar Week 46 -- ending 15 November.


Triaged:

https://code.djangoproject.com/ticket/32189 -- test.client.AsyncClient 
request POST failing (Invalid)
https://code.djangoproject.com/ticket/32187 -- The .select_related is not 
necessary in the .update documentation (Accepted)
https://code.djangoproject.com/ticket/32186 -- Applications `ready()` 
method doesnt called when apps author missed to define 
`default_app_config` (Duplicate of #31180)
https://code.djangoproject.com/ticket/32188 -- Pipenv latest version of 
Django is 3.0.11 rather than 3.1.* (Invalid)
https://code.djangoproject.com/ticket/32185 -- Add anchors to django code 
style docs (wontfix)
https://code.djangoproject.com/ticket/27807 -- Overriding username 
validators doesnt work as documented (wontfix)
https://code.djangoproject.com/ticket/32184 -- `manage.py migrate 
--noinput` should not delete stale modules (wontfix)



Reviewed:

https://github.com/django/djangoproject.com/pull/998 -- Fix color contrast
https://github.com/django/django/pull/13669 -- Fixed #32187 -- Removed 
unnecessary select_related in queries doc.
https://github.com/django/django/pull/12387 -- Fixed #31216 -- Added 
support for colorama terminal colors on Windows.
https://github.com/django/django/pull/13114 -- Fixed #27807 -- Made 
username validation configurable through AUTH_USERNAME_VALIDATORS setting
https://github.com/django/django/pull/12449 -- Fixed #31262 -- Allowed 
dictionaries in Field.choices for named groups.
https://github.com/django/django/pull/13649 -- Fixed #32176 -- Clarified 
filesystem cache docs.
https://github.com/django/django/pull/13659 -- Removed unnecessary 
__str__() methods in tests models.
https://github.com/django/django/pull/13648 -- Refs #32074 -- Fixed 
handling memoryview content by HttpResponse on Python 3.10+.
https://github.com/django/django/pull/13134 -- Fixed #31747 -- Fixed model 
enumeration via admin URLs.



Kind Regards,

Carlton


-- 
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/13775cc1-0d8a-4f58-bcf2-7a546f98dc3an%40googlegroups.com.

Re: Adding a security concerned feature

[Carlton Gibson]

On this topic, a ticket proposing to prepend the project name to the 
`admin/` URL in the default project template was opened. 
https://code.djangoproject.com/ticket/32209

Given that it's the exact discussion we're having here, I've paused that to 
see if there's a consensus for a change. 

Thanks. C.

On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:

>  I've got this idea with the usage of json files that require some keys 
> which is authenticated for a single user which seems to excite me for fact 
> that if this was similar for admin/, then it'd give django a overhead 
> advantages for future use.
>
> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
> wrote:
>
>> I think I'd come down as -1 for a system check here... 
>>
>> They're not costless, there's a tendency to want to add a new system 
>> check for every possible configuration choice, but, beyond implementing and 
>> maintaining, the danger is it leads to too much noise. 
>> If you get a system check warning, you shouldn't be tempted to ignore it. 
>> In general I think reserving the built-in checks slightly means they don't 
>> get devalued. (Folks are free, and encouraged, to implement, and share, 
>> their own checks to enforce project-level standards.)
>>
>> I think it's not sufficiently clear-cut that using `/admin/` is a bad 
>> idea to justify including a check. 
>>
>> (On a personal note, I like to use `/admin/`, configure nginx to only 
>> serve the admin from the localhost, and then use an SSH tunnel to access it 
>> remotely, so I'd have to silence a system check here.) 
>>
>> C.
>>
>> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:
>>
>>>
>>> Hi, 
>>>
>>> I wasn't convinced about changing the 'admin' path until recently. My 
>>> reasons to change the path of 'admin' are: 
>>>
>>> -A bit less likely to be affected by bugs like 
>>>
>>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>>>  
>>> : at least the site wouldn't appear in automatic scans for 
>>> vulnerabilities (if checking Django versions based on the admin 
>>> template, etc.) . The bug/exploit might have been known before the fix 
>>> was implemented (and everyone updated) so I prefer to not be exposed (or 
>>> less exposed) 
>>>
>>> -At the moment in Django there is no rate-limiting login attempts "out 
>>> of the box" so I prefer to avoid the opportunity if possible 
>>>
>>> -Partially out of my control: an 'admin' user might have used the same 
>>> password in another place and the password got leaked 
>>>
>>> Other people might have other reasons. 
>>>
>>> Cheers, 
>>>
>>> On Nov/18/2020, Tim Graham wrote: 
>>> > I'm not convinced that a system check promoting security by obscurity 
>>> adds 
>>> > much value. The original poster wrote "sometimes it can be a security 
>>> > concern." Maybe that's the case (how so?) but for most sites I would 
>>> say 
>>> > it's not. 
>>> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
>>> > wrote: 
>>> > 
>>> > > 
>>> > > Hi, 
>>> > > 
>>> > > On Nov/16/2020, Carles Pina i Estany wrote: 
>>> > > 
>>> > > > Either way: I'd be happy to write a django check to make sure that 
>>> > > > 'admin/' is not routed to admin. 
>>> > > 
>>> > > Regarding this check: this morning I've done a very preliminary/for 
>>> fun 
>>> > > draft to play with. 
>>> > > 
>>> > > 
>>> > > 
>>> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>>>  
>>> > > 
>>> > > I'm not sure what is the best way to check if /admin is routed to 
>>> > > django.contrib.admin. At the moment it's doing: 
>>> > > 
>>> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index' 
>>> > > 
>>> > > Yes, I know! :-) 
>>> > > 
>>> > > I could also do something along the lines of: 
>>> > > resolve(admin_url).func.admin_site == admin.site 
>>> > > 
>>> > > This causes problems on the unit test side (need to import 
>>> admin.site). 
>>> > > Still I don't really like it. 
>>> > > 
>>> > > Does anyone have any better suggestions or comments? (or code 
>>> pointer). 
>>> > > Otherwise later on I'll have another look. 
>>> > > 
>>> > > Thank you very much, 
>>> > > 
>>> > > -- 
>>> > > Carles Pina i Estany 
>>> > > https://carles.pina.cat 
>>> > > 
>>> > 
>>> > -- 
>>> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.
>>>  
>>>
>>>
>>> -- 
>>> Carles Pina i Estany 
>>> https://carles.pina.cat 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to 

Re: Quick Filter in the Admin Sidebar

[Tom Carrick]

I haven't looked at the gist, but I think in principle it's a good idea.
ctrl+f isn't ideal.

I think we need to be careful that the UX is good, if we go with this.

Tom

On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov  wrote:

> Yeah, that's why I came up with that idea. There are two projects, 44
> models on one, 57 models on another. It's very hard to navigate
>
> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com:
>
>> I found this feature very helpful. I'm maintaining two sites with more
>> than 20 models registered in the admin and some time is annoying when I try
>> to find the one I'm looking for
>>
>> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim
>> Milovanov escribió:
>>
>>> Hey guys,
>>>
>>> I've posted a ticket  with
>>> a proposal to add a quick filtering feature to the sidebar.
>>> To see it in action just replace the content of nav_sidebar.html by this
>>> gist
>>> 
>>>
>>> Does it worth adding to the admin features? Hope for any feedback.
>>>
>>> Thanks,
>>> Maxim
>>>
>> --
> 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/8376528d-a2df-43b0-829e-43a49bd44dddn%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaCHxNsukZXUZv9dOtsag9en6fZn0OdaFSMOvWknUkJ%2Bw%40mail.gmail.com.

Re: Quick Filter in the Admin Sidebar

[Maxim Milovanov]

Yeah, that's why I came up with that idea. There are two projects, 44 
models on one, 57 models on another. It's very hard to navigate

четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com: 

> I found this feature very helpful. I'm maintaining two sites with more 
> than 20 models registered in the admin and some time is annoying when I try 
> to find the one I'm looking for
>
> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim 
> Milovanov escribió:
>
>> Hey guys,
>>
>> I've posted a ticket  with 
>> a proposal to add a quick filtering feature to the sidebar.
>> To see it in action just replace the content of nav_sidebar.html by this 
>> gist 
>> 
>>
>> Does it worth adding to the admin features? Hope for any feedback.
>>
>> Thanks,
>> Maxim
>>
>

-- 
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/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com.

Re: CAUTION

[Carlton Gibson]

Hi. Welcome. 

Check out the Contributing Guide: 
https://docs.djangoproject.com/en/dev/internals/contributing/ 


I hope that helps. 
Carlton


> On 19 Nov 2020, at 10:46, Himanshu Poptani  
> wrote:
> 
> Ya i know this is gonna be really silly . But how to start contributing in 
> Django Open Source? 
> I am an intermediate in the topic.
> As being a Community Please Help.
> 
> -- 
> 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/4be863a0-e4fb-445e-848f-057efff60630n%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DCDE7A58-0E6C-421C-8A3B-1C8E3F65AC43%40gmail.com.

Re: Quick Filter in the Admin Sidebar

[Yasiel Cabrera]

I found this feature very helpful. I'm maintaining two sites with more than 
20 models registered in the admin and some time is annoying when I try to 
find the one I'm looking for

El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim 
Milovanov escribió:

> Hey guys,
>
> I've posted a ticket  with a 
> proposal to add a quick filtering feature to the sidebar.
> To see it in action just replace the content of nav_sidebar.html by this 
> gist 
>
> Does it worth adding to the admin features? Hope for any feedback.
>
> Thanks,
> Maxim
>

-- 
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/dbb9d7f7-e1a5-44be-a868-9b30e3bc8d4dn%40googlegroups.com.

CAUTION

[Himanshu Poptani]

Ya i know this is gonna be really silly . But how to start contributing 
in Django Open Source? 
I am an intermediate in the topic.
As being a Community Please Help.

-- 
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/4be863a0-e4fb-445e-848f-057efff60630n%40googlegroups.com.

Re: Adding a security concerned feature

[Shoury Sharma]

 I've got this idea with the usage of json files that require some keys
which is authenticated for a single user which seems to excite me for fact
that if this was similar for admin/, then it'd give django a overhead
advantages for future use.

On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
wrote:

> I think I'd come down as -1 for a system check here...
>
> They're not costless, there's a tendency to want to add a new system check
> for every possible configuration choice, but, beyond implementing and
> maintaining, the danger is it leads to too much noise.
> If you get a system check warning, you shouldn't be tempted to ignore it.
> In general I think reserving the built-in checks slightly means they don't
> get devalued. (Folks are free, and encouraged, to implement, and share,
> their own checks to enforce project-level standards.)
>
> I think it's not sufficiently clear-cut that using `/admin/` is a bad idea
> to justify including a check.
>
> (On a personal note, I like to use `/admin/`, configure nginx to only
> serve the admin from the localhost, and then use an SSH tunnel to access it
> remotely, so I'd have to silence a system check here.)
>
> C.
>
> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:
>
>>
>> Hi,
>>
>> I wasn't convinced about changing the 'admin' path until recently. My
>> reasons to change the path of 'admin' are:
>>
>> -A bit less likely to be affected by bugs like
>>
>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>> : at least the site wouldn't appear in automatic scans for
>> vulnerabilities (if checking Django versions based on the admin
>> template, etc.) . The bug/exploit might have been known before the fix
>> was implemented (and everyone updated) so I prefer to not be exposed (or
>> less exposed)
>>
>> -At the moment in Django there is no rate-limiting login attempts "out
>> of the box" so I prefer to avoid the opportunity if possible
>>
>> -Partially out of my control: an 'admin' user might have used the same
>> password in another place and the password got leaked
>>
>> Other people might have other reasons.
>>
>> Cheers,
>>
>> On Nov/18/2020, Tim Graham wrote:
>> > I'm not convinced that a system check promoting security by obscurity
>> adds
>> > much value. The original poster wrote "sometimes it can be a security
>> > concern." Maybe that's the case (how so?) but for most sites I would
>> say
>> > it's not.
>> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany
>> > wrote:
>> >
>> > >
>> > > Hi,
>> > >
>> > > On Nov/16/2020, Carles Pina i Estany wrote:
>> > >
>> > > > Either way: I'd be happy to write a django check to make sure that
>> > > > 'admin/' is not routed to admin.
>> > >
>> > > Regarding this check: this morning I've done a very preliminary/for
>> fun
>> > > draft to play with.
>> > >
>> > >
>> > >
>> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>> > >
>> > > I'm not sure what is the best way to check if /admin is routed to
>> > > django.contrib.admin. At the moment it's doing:
>> > >
>> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
>> > >
>> > > Yes, I know! :-)
>> > >
>> > > I could also do something along the lines of:
>> > > resolve(admin_url).func.admin_site == admin.site
>> > >
>> > > This causes problems on the unit test side (need to import
>> admin.site).
>> > > Still I don't really like it.
>> > >
>> > > Does anyone have any better suggestions or comments? (or code
>> pointer).
>> > > Otherwise later on I'll have another look.
>> > >
>> > > Thank you very much,
>> > >
>> > > --
>> > > Carles Pina i Estany
>> > > https://carles.pina.cat
>> > >
>> >
>> > --
>> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.
>>
>>
>> --
>> Carles Pina i Estany
>> https://carles.pina.cat
>>
> --
> 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/61afea37-34af-4271-91cb-e4a116c1eb71n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Re: Adding a security concerned feature

[Carlton Gibson]

I think I'd come down as -1 for a system check here... 

They're not costless, there's a tendency to want to add a new system check 
for every possible configuration choice, but, beyond implementing and 
maintaining, the danger is it leads to too much noise. 
If you get a system check warning, you shouldn't be tempted to ignore it. 
In general I think reserving the built-in checks slightly means they don't 
get devalued. (Folks are free, and encouraged, to implement, and share, 
their own checks to enforce project-level standards.)

I think it's not sufficiently clear-cut that using `/admin/` is a bad idea 
to justify including a check. 

(On a personal note, I like to use `/admin/`, configure nginx to only serve 
the admin from the localhost, and then use an SSH tunnel to access it 
remotely, so I'd have to silence a system check here.) 

C.

On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:

>
> Hi,
>
> I wasn't convinced about changing the 'admin' path until recently. My 
> reasons to change the path of 'admin' are:
>
> -A bit less likely to be affected by bugs like
>
> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
> : at least the site wouldn't appear in automatic scans for
> vulnerabilities (if checking Django versions based on the admin
> template, etc.) . The bug/exploit might have been known before the fix
> was implemented (and everyone updated) so I prefer to not be exposed (or
> less exposed)
>
> -At the moment in Django there is no rate-limiting login attempts "out
> of the box" so I prefer to avoid the opportunity if possible
>
> -Partially out of my control: an 'admin' user might have used the same
> password in another place and the password got leaked
>
> Other people might have other reasons.
>
> Cheers,
>
> On Nov/18/2020, Tim Graham wrote:
> > I'm not convinced that a system check promoting security by obscurity 
> adds 
> > much value. The original poster wrote "sometimes it can be a security 
> > concern." Maybe that's the case (how so?) but for most sites I would say 
> > it's not.
> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
> > wrote:
> > 
> > >
> > > Hi,
> > >
> > > On Nov/16/2020, Carles Pina i Estany wrote:
> > >
> > > > Either way: I'd be happy to write a django check to make sure that
> > > > 'admin/' is not routed to admin.
> > >
> > > Regarding this check: this morning I've done a very preliminary/for fun
> > > draft to play with.
> > >
> > >
> > > 
> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
> > >
> > > I'm not sure what is the best way to check if /admin is routed to
> > > django.contrib.admin. At the moment it's doing:
> > >
> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
> > >
> > > Yes, I know! :-)
> > >
> > > I could also do something along the lines of:
> > > resolve(admin_url).func.admin_site == admin.site
> > >
> > > This causes problems on the unit test side (need to import admin.site).
> > > Still I don't really like it.
> > >
> > > Does anyone have any better suggestions or comments? (or code pointer).
> > > Otherwise later on I'll have another look.
> > >
> > > Thank you very much,
> > >
> > > -- 
> > > Carles Pina i Estany
> > > https://carles.pina.cat
> > >
> > 
> > -- 
> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com
> .
>
> -- 
> Carles Pina i Estany
> https://carles.pina.cat
>

-- 
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/61afea37-34af-4271-91cb-e4a116c1eb71n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Paolo Melchiorre]

Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  wrote:
> ...
> Thus on the current policy we should drop support for both Python 3.6 and 
> Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
> ...
> I think we should drop Python 3.6 at this time ...
>
> I think though that dropping support for Python 3.7 would be a little 
> aggressive ...

I agree with you.

Python 3.7 is still the default version in the stable version of
Debian 10 (Buster) with LTS until 2024.

Kind regards,
Paolo
-- 
Paolo Melchiorre

https://www.paulox.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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx67iV6ENfs1WF7eGo9qMr%2BAMVpKOOJ9JZ_pwSWfsJeSgg%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Jure Erznožnik]

Maybe I'm getting old, but:

This is going extremely (too?) fast. I don't think Ubuntu LTS releases
provide Python versions in time before the release chosen for the LTS
becomes expired. I've definitely had an issue like this with
django-channels and its required redis version.

So if I choose a few different LTSs for my server deployments, all of
them dropping support so aggressively, I will end up with something
out of date for a good portion of my server lifetime. For example,
Ubuntu 20.04 will be supported until 2025, but it is using python 3.7
which will only be supported until 2023... So if I want to keep
up-to-date, I will have to move to 22.04 as soon as it gets out. Same
with any Django LTS, same with any other thingy LTS. All of that often
requiring custom builds because maybe some other LTS won't be
supporting the new versions yet...

OTOH, the new features are so nice to use...

So, maybe we don't really have to be SO strict dropping support?

LP,
Jure

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  wrote:
>
> Hi all.
>
> The Python version support policy reads [0]: "Typically, we will support a 
> Python version up to and including the first Django LTS release whose 
> security support ends after security support for that version of Python ends. 
> For example, Python 3.3 security support ends September 2017 and Django 1.8 
> LTS security support ends April 2018. Therefore Django 1.8 is the last 
> version to support Python 3.3."
>
> Updating that to current numbers we have:
>
> Python  EOL [1]
> 3.6 2021-12-23
> 3.7 2023-06-27
> 3.8 2024-10
> 3.9 2025-10
>
> Compared with the next two LTS versions for Django
>
> Django  EOL [2]
> 3.2 2024-04
> 4.2 2026-04
>
> By my reckoning this makes Django 3.2 "the first Django LTS release whose 
> security support ends after security support for that version of Python ends" 
> for both Python 3.6 and Python 3.7.
>
> Thus on the current policy we should drop support for both Python 3.6 and 
> Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
>
> I'm not sure what I think about that. I started writing this thinking just 
> about Python 3.6 — and then I looked up the dates.
>
> I think we should drop Python 3.6 at this time. asyncio is still evolving and 
> there are API changes between 3.6 and 3.7 that I think we need to get the 
> other side of.
>
> I think though that dropping support for Python 3.7 would be a little 
> aggressive — it will still have ≈18months of life at the point Django 4.0 is 
> released.
>
> I've argued previously for a loosening in the policy here[3]. Roughly, unless 
> there are technical reasons to advance, the situation I'd like is that, if 
> you have a (python-)supported version of Python then you can `pip install 
> Django` and get the latest major version. That is, roughly, the ideally, we'd 
> follow Python's support versions policy. (The flip side being I think we 
> should probably be actively dropping support for versions of Python as they 
> go EOL, even if between LTS versions.)
>
> With the change to Python's new annual release cycle[4], we're going to need 
> to adjust the policy somehow. Python 3.8 will be EOL for a full 2 years 
> before Django 4.2 is itself EOL.
>
> Can I ask for consideration and ideas at this stage, which hopefully can lead 
> to a fresh consensus?
>
> Thanks!
>
> Kind regards,
> Carlton
>
> [0] 
> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
> [1] https://devguide.python.org/#status-of-python-branches
> [2] https://www.djangoproject.com/download/#supported-versions
> [3] https://groups.google.com/g/django-developers/c/YDJwI7uvgxU/m/c0ZPHaXZFQAJ
> [4] https://www.python.org/dev/peps/pep-0602/
>
> --
> 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/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJ%3D9zieOHxefv%2BpUF%2BT2xch-N%2BWusMeeaFv%3DGzFhHY_LNw%3DfAw%40mail.gmail.com.

Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

Hi all. 

The Python version support policy reads [0]: "Typically, we will support a 
Python version up to and including the first Django LTS release whose 
security support ends after security support for that version of Python 
ends. For example, Python 3.3 security support ends September 2017 and 
Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is 
the last version to support Python 3.3."

Updating that to current numbers we have: 

Python  EOL [1]
3.6 2021-12-23
3.7 2023-06-27
3.8 2024-10
3.9 2025-10

Compared with the next two LTS versions for Django

Django  EOL [2]
3.2 2024-04
4.2 2026-04

By my reckoning this makes Django 3.2 "the first Django LTS release whose 
security support ends after security support for that version of Python 
ends" for *both *Python 3.6 and Python 3.7. 

Thus on the current policy we should drop support for *both *Python 3.6 and 
Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0. 

I'm not sure what I think about that. I started writing this thinking just 
about Python 3.6 — and then I looked up the dates. 

I think we *should* drop Python 3.6 at this time. asyncio is still evolving 
and there are API changes between 3.6 and 3.7 that I think we need to get 
the other side of. 

I think though that dropping support for Python 3.7 would be a *little 
aggressive *— it will still have ≈18months of life at the point Django 4.0 
is released. 

I've argued previously for a loosening in the policy here[3]. Roughly, 
unless there are technical reasons to advance, the situation I'd like is 
that, if you have a (python-)supported version of Python then you can `pip 
install Django` and get the latest major version. That is, roughly, the 
ideally, we'd follow Python's support versions policy. (The flip side being 
I think we should probably be actively dropping support for versions of 
Python as they go EOL, even if between LTS versions.) 

With the change to Python's new annual release cycle[4], we're going to 
need to adjust the policy somehow. Python 3.8 will be EOL for a full 2 
years before Django 4.2 is itself EOL.

Can I ask for consideration and ideas at this stage, which hopefully can 
lead to a fresh consensus?

Thanks! 

Kind regards, 
Carlton

[0] 
https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
[1] https://devguide.python.org/#status-of-python-branches
[2] https://www.djangoproject.com/download/#supported-versions
[3] 
https://groups.google.com/g/django-developers/c/YDJwI7uvgxU/m/c0ZPHaXZFQAJ
[4] https://www.python.org/dev/peps/pep-0602/

-- 
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/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%40googlegroups.com.