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

[Adam Johnson]

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:

> The proposal seems to be a setting of the form:
>
> SECURITY_HEADERS = {
> 'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
> ...
> }
>
> Currently we have system checks to suggest
> setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision
> trying to keep these checks? It seems it'll be more complicated to parse
> and validate arbitrary string values instead of individual settings.
>
> It seems some headers may still need special handling in
> SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if
> request.is_secure().
> On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
>
>> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good.
>> Would love to get CORS into core too.
>>
>> The Opener-Policy ticket has been marked as someday/maybe because the
>> header is still not widely supported.
>>
>> On Thu, 20 Aug 2020 at 00:02, James Bennett  wrote:
>>
>>> While I think Adam's right that adding one or two new settings
>>> wouldn't be a problem, I do worry about the ongoing proliferation, and
>>> it's a thing that I keep wanting to try to find the time to work on
>>> but never actually succeed at.
>>>
>>> Separate from the suggestion of a generic way to add headers on every
>>> response, I've been leaning for a while toward the idea of
>>> consolidating the security-header settings the way we've already
>>> consolidated database and template settings. We can paint the bikeshed
>>> whatever color, but suppose for sake of an example name we add a
>>> SECURITY_HEADERS setting, with each one configured under its own key.
>>> That would allow X-Frame-Options, content sniffing, HSTS,
>>> Referrer-Policy, opener policy, and future stuff like CSP, built-in
>>> CORS, etc. to all be defined in a single place that doesn't
>>> proliferate a huge number of new settings, or require adding and
>>> supporting a new setting every time a new one comes along (which, with
>>> security headers, is about twice a week these days).
>>>
>>> For now I think the best thing would be to accept the opener-policy
>>> work as-is, then get consensus around a proposal for how future
>>> security headers should be handled.
>>>
>>> --
>>> 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/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%40mail.gmail.com
>>> .
>>>
>>
>>
>> --
>> 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 web visit
> https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com
> 
> .
>


-- 
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 web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0enPLL%2BQq0SLUMde%2B5H6RxuMZr%2BG1TFL3NC_iD%3Dp4-sg%40mail.gmail.com.

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

[Tim Graham]

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 AM UTC-5 Adam Johnson wrote:

> 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:
>
>> The proposal seems to be a setting of the form:
>>
>> SECURITY_HEADERS = {
>> 'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
>> ...
>> }
>>
>> Currently we have system checks to suggest 
>> setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision 
>> trying to keep these checks? It seems it'll be more complicated to parse 
>> and validate arbitrary string values instead of individual settings.
>>
>> It seems some headers may still need special handling in 
>> SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if 
>> request.is_secure().
>> On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
>>
>>> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. 
>>> Would love to get CORS into core too.
>>>
>>> The Opener-Policy ticket has been marked as someday/maybe because the 
>>> header is still not widely supported.
>>>
>>> On Thu, 20 Aug 2020 at 00:02, James Bennett  wrote:
>>>
 While I think Adam's right that adding one or two new settings
 wouldn't be a problem, I do worry about the ongoing proliferation, and
 it's a thing that I keep wanting to try to find the time to work on
 but never actually succeed at.

 Separate from the suggestion of a generic way to add headers on every
 response, I've been leaning for a while toward the idea of
 consolidating the security-header settings the way we've already
 consolidated database and template settings. We can paint the bikeshed
 whatever color, but suppose for sake of an example name we add a
 SECURITY_HEADERS setting, with each one configured under its own key.
 That would allow X-Frame-Options, content sniffing, HSTS,
 Referrer-Policy, opener policy, and future stuff like CSP, built-in
 CORS, etc. to all be defined in a single place that doesn't
 proliferate a huge number of new settings, or require adding and
 supporting a new setting every time a new one comes along (which, with
 security headers, is about twice a week these days).

 For now I think the best thing would be to accept the opener-policy
 work as-is, then get consensus around a proposal for how future
 security headers should be handled.

 -- 
 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/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%40mail.gmail.com
 .

>>>
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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 web visit 
https://groups.google.com/d/msgid/django-developers/3ae8a31f-a53a-4415-8e51-6ce3faee85a1n%40googlegroups.com.

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

[Adam Johnson]

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_response(request)
response["Cross-Origin-Embedder-Policy"] = "require-corp"
return response

Also there are many non-security related headers one might want to add, so
having the ability to add them in a setting called SECURITY_HEADERS could
be confusing for maintenance.

On Tue, 19 Jan 2021 at 12:02, Tim Graham  wrote:

> 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 AM UTC-5 Adam Johnson wrote:
>
>> 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:
>>
>>> The proposal seems to be a setting of the form:
>>>
>>> SECURITY_HEADERS = {
>>> 'Strict-Transport-Security':
>>> 'max-age=60; includeSubDomains; preload',
>>> ...
>>> }
>>>
>>> Currently we have system checks to suggest
>>> setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision
>>> trying to keep these checks? It seems it'll be more complicated to parse
>>> and validate arbitrary string values instead of individual settings.
>>>
>>> It seems some headers may still need special handling in
>>> SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if
>>> request.is_secure().
>>> On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
>>>
 A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good.
 Would love to get CORS into core too.

 The Opener-Policy ticket has been marked as someday/maybe because the
 header is still not widely supported.

 On Thu, 20 Aug 2020 at 00:02, James Bennett  wrote:

> While I think Adam's right that adding one or two new settings
> wouldn't be a problem, I do worry about the ongoing proliferation, and
> it's a thing that I keep wanting to try to find the time to work on
> but never actually succeed at.
>
> Separate from the suggestion of a generic way to add headers on every
> response, I've been leaning for a while toward the idea of
> consolidating the security-header settings the way we've already
> consolidated database and template settings. We can paint the bikeshed
> whatever color, but suppose for sake of an example name we add a
> SECURITY_HEADERS setting, with each one configured under its own key.
> That would allow X-Frame-Options, content sniffing, HSTS,
> Referrer-Policy, opener policy, and future stuff like CSP, built-in
> CORS, etc. to all be defined in a single place that doesn't
> proliferate a huge number of new settings, or require adding and
> supporting a new setting every time a new one comes along (which, with
> security headers, is about twice a week these days).
>
> For now I think the best thing would be to accept the opener-policy
> work as-is, then get consensus around a proposal for how future
> security headers should be handled.
>
> --
> 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/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%40mail.gmail.com
> .
>


 --
 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> 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

Django 3.2 alpha 1 released.

[Carlton Gibson]

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 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/C1560E82-4D44-4A10-9D18-3B07D852B2E4%40gmail.com.

Fellow Reports -- January 2021

[Carlton Gibson]

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)
https://code.djangoproject.com/ticket/32319 -- Add support to 
HashedFilesMixin for ES modules (Accepted)
https://code.djangoproject.com/ticket/32313 -- Queryset in_bulk docs 
don't explicit field_name as kwarg only (Accepted)
https://code.djangoproject.com/ticket/32309 -- Allow including hidden 
directories for startproject/startapp --template (Accepted)



Reviewed:

https://github.com/django/django/pull/13532 -- Fixed #16117 -- Added 
decorators for admin action and display functions.
https://github.com/django/django/pull/11026 -- Fixed #29010, Fixed #29138 
-- Added limit_choices_to and to_field support to autocomplete fields
https://github.com/django/django/pull/12444 -- Fixed #31259 -- Added a dark 
theme in the admin module
https://github.com/django/django/pull/13435 -- Fixed #32018 -- Extracted 
admin colors into CSS variables.
https://github.com/django/django/pull/13832 -- Refs #25175 -- Removed 
postgresql_psycopg2 in django.db.utils.load_backend().
https://github.com/django/django/pull/13849 -- Refs #32191 -- Added 
Signer.sign_object()/unsign_object().
https://github.com/django/django/pull/13134 -- Fixed #31747 -- Fixed model 
enumeration via admin URLs.
https://github.com/django/django/pull/13834 -- Fixed #32313 -- Documnet 
keyword only argument in QuerySet.in_bulk docs.




Calendar Week 2 -- ending 17 January.


Triaged:

https://code.djangoproject.com/ticket/32347 -- ModelChoiceField does not 
provide value of invalid choice when raising ValidationError (wontfix)
https://code.djangoproject.com/ticket/32343 -- Chained autocomplete_fields 
in contrib.admin (wontfix)
https://code.djangoproject.com/ticket/32340 -- Usability issues with Django 
form fields expecting specific patterns (Accepted)
https://code.djangoproject.com/ticket/32339 -- Accessibility issues with 
Django forms as_table, as_ul, as_p rendering helpers (Accepted)
https://code.djangoproject.com/ticket/32312 -- Performance decrease 
following implementation of ASGI handler and coroutine-safety. (Accepted)



Reviewed:

https://github.com/django/django/pull/13891 -- Refs #31259 -- Changed the 
background color of messages in dark mode
https://github.com/django/django/pull/12553 -- Fixed #31358 -- Increased 
salt entropy of password hashers.
https://github.com/django/django/pull/13845 -- Bootstrapped Django 4.0.
https://github.com/django/django/pull/13880 -- Fixed #31259 -- Added a dark 
theme in the admin module
https://github.com/django/django/pull/11929 -- Fixed #26167 -- Added 
support for functional indexes.
https://github.com/django/django/pull/13362 -- Fixed #21936 -- Refactored 
DeleteView to work with SuccessMessageMixin.
https://github.com/django/django/pull/13134 -- Fixed #31747 -- Fixed model 
enumeration via admin URLs.
https://github.com/django/django/pull/13869 -- Fixed #32271 -- Improved 
consistency of docs CBV examples.
https://github.com/django/django/pull/11026 -- Fixed #29010, Fixed #29138 
-- Added limit_choices_to and to_field support to autocomplete fields
https://github.com/django/django/pull/13881 -- Refs #32311 -- Fixed 
CSRF_FAILURE_VIEW system check errors code.
https://github.com/django/django/pull/13835 -- Fixed #32311 -- Added system 
check for CSRF_FAILURE_VIEW setting.



Authored:

https://github.com/django/django/pull/13892 -- Updates for branching 
stable/3.2.x
https://github.com/pypa/trove-classifiers/pull/59 -- Added trove classifier 
for Django v3.2 #59



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/cec38be1-37d3-48a5-95f5-c0ebf6ca2f15n%40googlegroups.com.

Re: Generate JWTs with Django

[Carlton Gibson]

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 wrote:

> Hi all, I know this is an old thread, but I have a solution for SPAs using 
> httpOnly session cookies. Here is a demo with React and Django WITHOUT JWTs 
> with httpOnly cookies for session and csrf: 
> https://acwpython.pythonanywhere.com/authenticated/. The tutorial and 
> open source repository is found here: 
> https://github.com/Andrew-Chen-Wang/SPA-with-httponly-sessions .
>
> The original purpose of this thread was for SPA development, not really 
> for JWTs. I'm a maintainer at SimpleJWT, a repository that almost all 
> tutorials use to show React/SPA/JS Frameworks and Django integration. I 
> also agree with the security concerns for JWT usage on the browser. So I 
> made this demo and tutorial overnight to make sure everyone stops using 
> JWTs instead of sessions.
>
> Thanks for taking a look. Please spread the word to get people to stop 
> using JWTs instead of sessions.
> Cheers 
>
> On Monday, May 11, 2020 at 7:19:33 PM UTC-4 dans...@gmail.com wrote:
>
>> The place where JWT begins to get useful and important is when federated 
>> login capabilities end-up in your app. That sort of thing seems more 
>> the domain of python-social-auth packages like social-auth-core and 
>> social-auth-app-django.  Generating an authentication cookie doesn't 
>> require JWT - Django already does that.
>>
>> On Mon, May 11, 2020 at 9:37 AM Derek Adair  wrote:
>>
>>> Maybe we can update the docs to show how you you would might use some of 
 the signing primitives instead of JWTs, but this also sounds a bit 
 dangerous 🤷‍♂️ 

>>>
>>> As someone hoodwinked into believing JWT was the way... I'd absolutely 
>>> LOVE a clear and concise write up on how I might get my single page js apps 
>>> to communicate securely with projects like Django Rest. 
>>>
>>> Thanks for closing the door on JWT for me James.
>>>
>>> -- 
>>>
>> 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/adc7a8eb-6100-4639-af98-4bca9afaad0b%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/5f14dd99-f73c-4415-ac94-95c6560f7d74n%40googlegroups.com.

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 urlpatterns matches a URL, it should be applied before my
own urlpatterns. I read that it's not recommended to set
*AdminSite.final_catch_all_view* to false, and I think it should be better
that the "catch all" urlpattern will be applied after all urlpatterns,
including those I defined in my website. Is it possible to add the "catch
all" urlpattern as the very last urlpattern, after the website's defined
urlpatterns? I think this makes more sense.

Thanks,
אורי
u...@speedy.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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com.

Re: Generate JWTs with Django

[Andrew Wang]

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 task. This
article: https://www.valentinog.com/blog/webpack-django/ talks about two
reasons (besides people bandwagoning off SimpleJWT tutorials and making
their own): webpack maintainability and in general the JS bundles growing
too big and thus slowing dev time. I think *even if* there is wide adoption
for webpack, because of the JS bundles continuously growing (being a huge
turn-off once you have a semi-production-grade SPA repository), I proposed
a moderate idea:

To fix this, I'm going to develop a middleware as described in issue #3
here:
https://github.com/Andrew-Chen-Wang/SPA-with-httponly-sessions/issues/3
It'll use JWT when you're delivering on Node and SessionMiddleware when
delivering your bundles via staticfiles. That way, a webpack loader is not
needed and development time is extremely fast. Deploy your staticfiles on
GitHub pages with the provided action; use React hot-reloading during
development so you don't need a webpack loader, split chunking, etc..

But thanks for taking a look! I'll update this thread once more when I
develop a package or just create that middleware.

Cheers,
Andrew

On Tue, Jan 19, 2021 at 9:55 AM Carlton Gibson 
wrote:

> 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 wrote:
>
>> Hi all, I know this is an old thread, but I have a solution for SPAs
>> using httpOnly session cookies. Here is a demo with React and Django
>> WITHOUT JWTs with httpOnly cookies for session and csrf:
>> https://acwpython.pythonanywhere.com/authenticated/. The tutorial and
>> open source repository is found here:
>> https://github.com/Andrew-Chen-Wang/SPA-with-httponly-sessions .
>>
>> The original purpose of this thread was for SPA development, not really
>> for JWTs. I'm a maintainer at SimpleJWT, a repository that almost all
>> tutorials use to show React/SPA/JS Frameworks and Django integration. I
>> also agree with the security concerns for JWT usage on the browser. So I
>> made this demo and tutorial overnight to make sure everyone stops using
>> JWTs instead of sessions.
>>
>> Thanks for taking a look. Please spread the word to get people to stop
>> using JWTs instead of sessions.
>> Cheers
>>
>> On Monday, May 11, 2020 at 7:19:33 PM UTC-4 dans...@gmail.com wrote:
>>
>>> The place where JWT begins to get useful and important is when federated
>>> login capabilities end-up in your app. That sort of thing seems more
>>> the domain of python-social-auth packages like social-auth-core and
>>> social-auth-app-django.  Generating an authentication cookie doesn't
>>> require JWT - Django already does that.
>>>
>>> On Mon, May 11, 2020 at 9:37 AM Derek Adair  wrote:
>>>
 Maybe we can update the docs to show how you you would might use some
> of the signing primitives instead of JWTs, but this also sounds a bit
> dangerous 🤷‍♂️
>

 As someone hoodwinked into believing JWT was the way... I'd absolutely
 LOVE a clear and concise write up on how I might get my single page js apps
 to communicate securely with projects like Django Rest.

 Thanks for closing the door on JWT for me James.

 --

>>> 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/adc7a8eb-6100-4639-af98-4bca9afaad0b%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/6oS9R2GwO4k/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/5f14dd99-f73c-4415-ac94-95c6560f7d74n%40googlegroups.com
> 
> .
>

-- 
You received this me

Re: final_catch_all_view

[Adam Johnson]

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
...
] + urls[-1]

‪On Tue, 19 Jan 2021 at 16:06, ‫אורי‬‎  wrote:‬

> 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 urlpatterns matches a URL, it should be applied before my
> own urlpatterns. I read that it's not recommended to set
> *AdminSite.final_catch_all_view* to false, and I think it should be
> better that the "catch all" urlpattern will be applied after all
> urlpatterns, including those I defined in my website. Is it possible to add
> the "catch all" urlpattern as the very last urlpattern, after the website's
> defined urlpatterns? I think this makes more sense.
>
> Thanks,
> אורי
> u...@speedy.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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com
> 
> .
>


-- 
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 web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com.

Re: final_catch_all_view

[Carlton Gibson]

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 latter but it’s up to
you to decide how serious that is for your site. It was the behaviour for
≈15 years before someone mentioned it, so exactly how serious it is for
most sites if debatable.

I seem to recall though that you commented on the other thread that you use
HTTP Basic Auth to protect the admin site, as an additional layer. If so,
unauthorised access is blocked before ever reaching Django, so you can turn
off the catch all view without a worry.

HTH

Kind regards, Carlton


On Tue, 19 Jan 2021 at 17:55, Adam Johnson  wrote:

> 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
> ...
> ] + urls[-1]
>
> ‪On Tue, 19 Jan 2021 at 16:06, ‫אורי‬‎  wrote:‬
>
>> 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 urlpatterns matches a URL, it should be applied before my
>> own urlpatterns. I read that it's not recommended to set
>> *AdminSite.final_catch_all_view* to false, and I think it should be
>> better that the "catch all" urlpattern will be applied after all
>> urlpatterns, including those I defined in my website. Is it possible to add
>> the "catch all" urlpattern as the very last urlpattern, after the website's
>> defined urlpatterns? I think this makes more sense.
>>
>> Thanks,
>> אורי
>> u...@speedy.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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> 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 web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.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/CAJwKpyT9YpwE1DWT-huHC_MKkcPf-adHyAr%3DirbDtcsFNoPW7A%40mail.gmail.com.

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"
urlpattern, and one calling both functions and concatenating the lists.
This way I will be able to define the first function in my own AdminSite
class, add my own urlpatterns and return the list, and Django will do
everything else for me. Instead of using *urls[:-1]* and *urls[-1]*, there
should be functions returning these lists, which I will be able to override
and add my own urlpatterns. I think this approach is better than relying on
the number of "catch all" urlpatterns to be 1.

Also, this feature will break all Django admin sites, unless the name of
the function *AdminSite.get_urls* will remain the same and this function
will not change, but the 2 other functions will be new functions and Django
will call the third function (with all urls) instead of calling
*AdminSite.get_urls*.

אורי
u...@speedy.net


On Tue, Jan 19, 2021 at 6:55 PM Adam Johnson  wrote:

> 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
> ...
> ] + urls[-1]
>
> ‪On Tue, 19 Jan 2021 at 16:06, ‫אורי‬‎  wrote:‬
>
>> 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 urlpatterns matches a URL, it should be applied before my
>> own urlpatterns. I read that it's not recommended to set
>> *AdminSite.final_catch_all_view* to false, and I think it should be
>> better that the "catch all" urlpattern will be applied after all
>> urlpatterns, including those I defined in my website. Is it possible to add
>> the "catch all" urlpattern as the very last urlpattern, after the website's
>> defined urlpatterns? I think this makes more sense.
>>
>> Thanks,
>> אורי
>> u...@speedy.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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> 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 web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.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/CABD5YeEHrLnKQ9jLu3jcx-9cnj3RzZyo9sw5oUcxJD06LGWpvw%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Claude Paroz]

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 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/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

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 like “If you’re not on the
LTS, then you need to think about updating Python and Django in line with
the release cadence” then MAYBE we could drop 3.7 (say — I didn’t look at
the dates again) after 4.0, obliging people to move up then.

In general what do we think about that kind of thought? It seems to be
Tim’s point about being stranded without security cover, yes?

My thought there is that we could quite reasonably say, “You should be on
the LTS, that’s why we go to all the work of maintaining it” for such a
case, but I don’t know if that’s defensible.

The other point was the size of the CI matrix (which the LTS makes larger
still...)

Not sure.
C.

On Tue, 19 Jan 2021 at 18:20, Claude Paroz  wrote:

> 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 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/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%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/CAJwKpyQxWkRehcm%2BxdZXo%2Bi-XvWNhdLNk9W-_iRAa81SEvEoTA%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Claude Paroz]

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 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/be97212d-00b8-4f9a-b8c7-1753580b8123n%40googlegroups.com.

Permission to discuss

[Benny]

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 to not violate any spamming/advertising policy, I’d like to ask 
permission before launching an email to either (or both) groups. And to that 
point, would permission to discuss here apply to the users group, or should I 
ask there as well?

Best,
Benny

-- 
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/A9A09FB5-C0D1-4DC0-ABFD-A5F671F700E0%40twosensedesign.com.

Re: Permission to discuss

[Tim Graham]

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 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 to not violate any spamming/advertising policy, I’d like to ask 
> permission before launching an email to either (or both) groups. And to 
> that point, would permission to discuss here apply to the users group, or 
> should I ask there as well?
>
> Best,
> Benny

-- 
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/1964547a-09bb-4166-b637-a21541628b78n%40googlegroups.com.

Re: Permission to discuss

[Adam Johnson]

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  wrote:

> 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 to not violate any spamming/advertising policy, I’d like to ask
> permission before launching an email to either (or both) groups. And to
> that point, would permission to discuss here apply to the users group, or
> should I ask there as well?
>
> Best,
> Benny
>
> --
> 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/A9A09FB5-C0D1-4DC0-ABFD-A5F671F700E0%40twosensedesign.com
> .
>


-- 
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 web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1pzxTbGsUVhnJwOoZh3%2BdFGEJwzoLEWmU65FMvGt%3DyBQ%40mail.gmail.com.

Re: Permission to discuss

[Benny]

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 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  wrote:
>> 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 to not violate any spamming/advertising policy, I’d like to ask 
>> permission before launching an email to either (or both) groups. And to that 
>> point, would permission to discuss here apply to the users group, or should 
>> I ask there as well?
>> 
>> Best,
>> Benny
>> 
>> -- 
>> 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/A9A09FB5-C0D1-4DC0-ABFD-A5F671F700E0%40twosensedesign.com.
> 
> 
> -- 
> 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 web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1pzxTbGsUVhnJwOoZh3%2BdFGEJwzoLEWmU65FMvGt%3DyBQ%40mail.gmail.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/497DAF77-192E-4F76-9387-E86B7ADCC936%40twosensedesign.com.