Re: Adding a security concerned feature

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 admi

Re: Adding a security concerned feature

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 Th

Re: Revisiting Python support for after Django 3.2 LTS

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 receiv

Fellow Reports -- November 2020

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_

Re: Adding a security concerned feature

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

Re: Quick Filter in the Admin Sidebar

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 >

Re: Quick Filter in the Admin Sidebar

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 regis

Re: CAUTION

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 rea

Re: Quick Filter in the Admin Sidebar

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

CAUTION

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)

Re: Adding a security concerned feature

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:

Re: Adding a security concerned feature

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

Re: Revisiting Python support for after Django 3.2 LTS

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 droppin

Re: Revisiting Python support for after Django 3.2 LTS

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 fe

Revisiting Python support for after Django 3.2 LTS

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 an