Re: Rethink (?) how we handle security headers.

I'd imagined the setting would be more like a roll-up of the existing settings, so no need for parsing: SECURITY_HEADERS = { "REFERRER_POLICY": "same-origin", "HSTS": { "PRELOAD": True, "SECONDS": 1_000_000, }, } On Tue, 19 Jan 2021 at 01:30, Tim Graham wrote: > Th

Re: Rethink (?) how we handle security headers.

I guess there have been a few different proposals here, but I imagined SECURITY_HEADERS would allow setting any security-related header without making changes in Django. If the setting is more than header/value pairs, then it seems this won't be the case. On Tuesday, January 19, 2021 at 4:39:54

Re: Rethink (?) how we handle security headers.

I don't see the need for adding a setting to add headers to outgoing responses. A middleware to do so is a handful of lines: class SecurityHeadersMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get

Django 3.2 alpha 1 released.

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2021/jan/19/django-32-alpha-1-released/ -- You received this message because you are subscribed to the Google Groups "Django

Fellow Reports -- January 2021

Hi all. Calendar Week 1 -- ending 10 January. Triaged: https://code.djangoproject.com/ticket/32324 -- Wrapping the header in base.html of contrib.abmin in {% blocks %}. (Accepted) https://code.djangoproject.com/ticket/32316 -- Access __file__ lazily rather than at module level (Accepted) h

Re: Generate JWTs with Django

Hi Andrew, Thanks for updating — that's really interesting to look at. I think a few more examples like this around the community would be handy to break the "Must use JWT" presumption that I think there is. Kind Regards, Carlton On Saturday, 16 January 2021 at 16:46:35 UTC+1 Andrew Wang w

final_catch_all_view

Hi, I installed Django 3.2 alpha and found out the change related to *final_catch_all_view*. I use *AdminSite* in my websites and I added some urlpatterns to the default urlpatterns. However, I want my urlpatterns to be after Django core's urlpatterns and not before them, so if a Django core urlpa

Re: Generate JWTs with Django

Hey Carlton, Thanks! There's actually already a package (django-webpack-loader) designed to handle exactly what I did, but being a maintainer of SimpleJWT made me realize most Django devs weren't using it. I basically almost completely blame all the tutorials that keep using SimpleJWT to do the ta

Re: final_catch_all_view

I don't see the need for any change - you can insert your custom URL's before the catch-all view with a subclass of AdminSite like so: class MyAdminSite(AdminSite): def get_urls(self): urls = super().get_urls() return urls[:-1] + [ # custom urls ...

Re: final_catch_all_view

Hey Uri, The “not recommended” amounts to a trade-off: adjust your URL patterns (Adam’s approach looks good if you really must insert them after the admin URLs) or allow a potential leakage of what model exist to someone probing the site. Turning off the catch-all view potentially allows the latt

Re: final_catch_all_view

Hi Adam, I think it's better not to rely on the number of "catch all" urlpatterns to be 1. I suggest it's better to separate *AdminSite.get_urls* into 3 functions - one returning all urls like before (without the "catch all" urlpattern), one returning a list containing only the "catch all" urlpatt

Re: Revisiting Python support for after Django 3.2 LTS

Like others in this thread, I think that dropping Python 3.7 for Django 4.0 is too aggressive, even if it complies with the written policy. So I would plead for an exception and ask to keep Python 3.7 for Django 4.0 at least. Is there support for this idea here? Claude -- You received this mes

Re: Revisiting Python support for after Django 3.2 LTS

HI Claude. Thanks for following up on this. I’d **like** to follow a slower policy — I’d more or less like us to be able to say that if you’re on a non-EOL Python we support you. BUT I’m struggling to think how we manage it, given Tim’s points. If we were to make a bit more explicit something

Re: Revisiting Python support for after Django 3.2 LTS

When I see that Python 3.7 will be supported the whole time of the 4.0 support period, it's enough for me. For the rest, let the people choose and see by themselves through the support graphs what their interest is. I think we should stop patronizing developers. Claude -- You received this me

Permission to discuss

Hi developers, I have an idea for a Django related project and I’d like to get input from users and developers before I decide to move forward with it. This does not directly apply to the Django backend or development, but I do believe input from the developers would be just as valuable. So as

Re: Permission to discuss

django-users is suitable for that. This mailing list is limited to discussion of the development of Django itself. On Tuesday, January 19, 2021 at 4:56:47 PM UTC-5 Benny wrote: > Hi developers, > > I have an idea for a Django related project and I’d like to get input from > users and developers

Re: Permission to discuss

I don't think that's appropriate to post on either mailing list. These mailing lists have thousands of members so must be kept on topic. The "Show & Tell" section on the forum would be a better place to post this: https://forum.djangoproject.com/c/projects/11 On Tue, 19 Jan 2021 at 21:56, Benny w

Re: Permission to discuss

Thanks for your quick responses. Adam, I was not even aware of the Show & Tell section. I’ll definitely look into that. Benny > On Jan 19, 2021, at 4:20 PM, Adam Johnson wrote: > >  > I don't think that's appropriate to post on either mailing list. These > mailing lists have thousands of me