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

[chris.j...@gmail.com]

On Friday, March 26, 2021 at 1:16:30 AM UTC-7 Adam Johnson wrote:

> That would be counter to how all current dict based settings work, so I 
> think it would be too surprising. 
>

I see. The django.conf.settings object should only include the raw settings 
data and not auxiliary objects that can depend on that data. In that case, 
my suggestion can be taken as an alternative API to a 
"get_security_header()" function. It can be an dict-like object imported 
from a module as opposed to being accessed through django.conf.settings. 
One advantage of a dict-like object over a single function is that has the 
ability to grow helper methods over time in addition to the dict-like 
accesses. That could be useful in different contexts. A precedent for this 
is the django.db.connections object, which is a ConnectionHandler object 
constructed from settings and that supports some dict-like operations.

--Chris
 

>
> On Fri, 26 Mar 2021 at 05:35, chris.j...@gmail.com  
> wrote:
>
>> I just came across this thread after seeing a related PR. Rather than a 
>> "get_security_header()" function, couldn't Django make the setting an 
>> object that is accessed by the user like a dict, but internally (underneath 
>> the hood) it tries from a user-defined dict and then falls back to a value 
>> in a Django-defined dict of defaults?
>>
>> --Chris
>>
>>
>> On Sunday, January 24, 2021 at 1:08:24 PM UTC-8 timog...@gmail.com wrote:
>>
>>> If we go with something like:
>>>
>>> SECURITY_HEADERS = {
>>> "REFERRER_POLICY": "same-origin",
>>> "HSTS": {
>>> "PRELOAD": True,
>>> "SECONDS": 1_000_000,
>>>  },
>>> }
>>>
>>> should we have an empty dictionary as the default or a dictionary with 
>>> defaults for all settings? 
>>>
>>> A drawback of an empty dictionary is that any code that wants to 
>>> retrieve a setting has to do something like 
>>> settings.SECURITY_HEADERS.get('REFERRER_POLICY', '') which 
>>> means the fallback value is duplicated every place the setting is 
>>> consulted.  Maybe a way to mitigate that is to add a 
>>> "get_security_header()" function that retrieves from django.conf.settings 
>>> (user-defined settings) and falls back to some defaults.
>>>
>>> A drawback of a fully-populated default is that overriding it either 
>>> requires users to redefine the entire dictionary or writing code like:
>>>
>>> from django.conf.global_settings import SECURITY_HEADERS
>>> SECURITY_HEADERS['REFERRER_POLICY'] = '...'
>>>
>>> If users redefine the entire dictionary, then adding new 
>>> SECURITY_HEADERS options in future Django versions will require something 
>>> like "get_security_header()" since we won't be able to assume the key is 
>>> there in projects upgrading from older versions.
>>>
>>> I'm not so sure the benefit of consolidating to a single setting is 
>>> worth this additional complexity.
>>> On Tuesday, January 19, 2021 at 8:27:58 AM UTC-5 Adam Johnson wrote:
>>>
 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 nee

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

[Mariusz Felisiak]

Hi Caram,

Django doesn't perform any DDL operations outside of migrations. You've 
probably set DEFAULT_AUTO_FIELD to BigAutoField, then you generated and run 
the migrations which caused some failures. We can check migration failures 
if you can provide a small project to reproduce.

Best,
Mariusz

-- 
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/9b97fe35-af0b-4435-96b5-ba710cb2eab9n%40googlegroups.com.

Re: Update - MSSQL support for Django

[Florian Apolloner]

Maybe wait with featuring till the licensing issues are cleared up. 
https://github.com/microsoft/mssql-django/issues/15 does not leave a good 
impression on a first glance.

On Friday, March 26, 2021 at 1:48:50 PM UTC+1 wi...@wsvincent.com wrote:

> Yes, what Adam said! We'll certainly feature the project next week in 
> Django News and would happily also include a blog post etc on the project :)
>
> On Friday, March 26, 2021 at 7:56:11 AM UTC-4 Adam Johnson wrote:
>
>> Great work Warren and co! I see you already have a number of stars on 
>> GitHub.
>>
>> A promotional blog post could help get the word out as well. If you do 
>> write one, submit your blog's Django-specific feed to "Community blog 
>> posts" on https://www.djangoproject.com/community/ and it will get 
>> picked up by many readers. You can also send it to Jeff Triplett and Will 
>> Vincent who run Django News ( https://django-news.com/ ).
>>
>> On Fri, 19 Mar 2021 at 23:56, Warren Chu  wrote:
>>
>>> Hi All, 
>>>
>>> We've released the preview version 1.0b1 of the Microsoft SQL Server 3rd 
>>> Party Backend for Django. This version supports Django 2.2, 3.0 and 3.1.
>>>
>>> What's coming up next between now and GA release? We are re-adding 
>>> optional regex support, so that the regex DLL file is downloadable from a 
>>> trusted Microsoft downloads page. This file can then be installed in SQL 
>>> Server via our project script. This follows our organizational security 
>>> best practices.
>>>
>>> If you have any questions, feel free to post here in the Django 
>>> Developer forum, or via Github issues at: 
>>> https://github.com/microsoft/mssql-django
>>>
>>> Thanks,
>>> Warren
>>>
>>> -- 
>>> 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/93188f91-c638-4e4d-89ee-e4b63585ab38n%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/4cec142a-49a2-4046-8e5b-0754d7c382d0n%40googlegroups.com.

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

[Caram]

I'm now discovering that some INT keys were subrepticely converting to 
BIGINT in the database without me noticing. And there is no BigAutoField in 
any of the migrations.

More worrying, there seem to have been several other unwanted changes:
1. NOT NULL changed to DEFAULT NULL (or the other way round for some 
models). The model has not changed in any way recently however.
2. FOREIGN KEY contraints gone missing. I'm currently going through an old 
mysql backup to get them back.

Cheers,
Caram

Le vendredi 26 mars 2021 à 11:30:44 UTC+1, Mariusz Felisiak a écrit :

> Can you provide a small project to reproduce?
>
> Best,
> Mariusz
>

-- 
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/5cc8b42e-cedd-420d-86ee-442e166b81edn%40googlegroups.com.

Re: Steps To Contribute ?

['Adam Johnson' via Django developers (Contributions to Django itself)]

Welcome!

There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/

If you’re looking to work with the code base (for documentation or code),
check out the “Advice for New Contributors” section:
https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
. Then see if you can work through the “Writing Your First Patch” tutorial:
https://docs.djangoproject.com/en/stable/intro/contributing/ .

If you get stuck or have questions, post back here or in the “Mentorship”
section on the forum:
https://forum.djangoproject.com/c/internals/mentorship/10

Hope that helps,

Adam

On Fri, 26 Mar 2021 at 11:36, Huzaifa  wrote:

> Hi,
>
> I'm Huzaifa. I am new to this group and wanna contribute to Django. May I
> please get a detailed overview of how I should start contributing? Hoping
> for a quick and positive reply.
>
> Thanks,
> Huzaifa
>
> --
> 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/0fa7fa89-e65b-43b4-a998-bc4838e1326bn%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/CAMyDDM0-v46dDTz3z6qGaZbdfNniR9%3D3xctO6LZyr80LBEUDOQ%40mail.gmail.com.

Steps To Contribute ?

[Huzaifa]

Hi,

I'm Huzaifa. I am new to this group and wanna contribute to Django. May I 
please get a detailed overview of how I should start contributing? Hoping 
for a quick and positive reply.

Thanks,
Huzaifa

-- 
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/0fa7fa89-e65b-43b4-a998-bc4838e1326bn%40googlegroups.com.

Re: Update - MSSQL support for Django

[wi...@wsvincent.com]

Yes, what Adam said! We'll certainly feature the project next week in 
Django News and would happily also include a blog post etc on the project :)

On Friday, March 26, 2021 at 7:56:11 AM UTC-4 Adam Johnson wrote:

> Great work Warren and co! I see you already have a number of stars on 
> GitHub.
>
> A promotional blog post could help get the word out as well. If you do 
> write one, submit your blog's Django-specific feed to "Community blog 
> posts" on https://www.djangoproject.com/community/ and it will get picked 
> up by many readers. You can also send it to Jeff Triplett and Will Vincent 
> who run Django News ( https://django-news.com/ ).
>
> On Fri, 19 Mar 2021 at 23:56, Warren Chu  wrote:
>
>> Hi All, 
>>
>> We've released the preview version 1.0b1 of the Microsoft SQL Server 3rd 
>> Party Backend for Django. This version supports Django 2.2, 3.0 and 3.1.
>>
>> What's coming up next between now and GA release? We are re-adding 
>> optional regex support, so that the regex DLL file is downloadable from a 
>> trusted Microsoft downloads page. This file can then be installed in SQL 
>> Server via our project script. This follows our organizational security 
>> best practices.
>>
>> If you have any questions, feel free to post here in the Django Developer 
>> forum, or via Github issues at: https://github.com/microsoft/mssql-django
>>
>> Thanks,
>> Warren
>>
>> -- 
>> 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/93188f91-c638-4e4d-89ee-e4b63585ab38n%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/b8c19fa7-2e0d-4d88-8050-f6e47be36f96n%40googlegroups.com.

Re: GSOC intro and guidance

['Adam Johnson' via Django developers (Contributions to Django itself)]

Welcome Raj,

Have you had a look at the GSoC wiki page?
https://code.djangoproject.com/wiki/SummerOfCode2021 . Do you have any
ideas what you'd like to work on?

I'll also paste below my normal reply for anyone seeking to contribute.

Thanks,

Adam

--

There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/

If you’re looking to work with the code base (for documentation or code),
check out the “Advice for New Contributors” section:
https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
. Then see if you can work through the “Writing Your First Patch” tutorial:
https://docs.djangoproject.com/en/stable/intro/contributing/ .

If you get stuck or have questions, post back here or in the “Mentorship”
section on the forum:
https://forum.djangoproject.com/c/internals/mentorship/10

Thanks,

Adam

On Sat, 20 Mar 2021 at 21:02, Raj Desai  wrote:

> Hi everyone,
> I am a sophomore student from India and have been working with Django for
> 2 years and had an amazing experience, got many opportunities because of
> it, and am still identifying myself as a Django developer. But I think it's
> high time I start contributing to the framework itself and so I wanna work
> on it. GSOC is a great start to it. I know I am late but better late than
> never. So any guidance or discussions are welcome. Would love to interact
> with the mentors too.
>
> --
> 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/69b88b67-ee8e-4a81-af2a-bbacd8fed60an%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/CAMyDDM1MPsXhuM%3DDCxiB8%3DmN2q_D9XT%2By7i-zNayUEU6oo8PyA%40mail.gmail.com.

Re: Update - MSSQL support for Django

['Adam Johnson' via Django developers (Contributions to Django itself)]

Great work Warren and co! I see you already have a number of stars on
GitHub.

A promotional blog post could help get the word out as well. If you do
write one, submit your blog's Django-specific feed to "Community blog
posts" on https://www.djangoproject.com/community/ and it will get picked
up by many readers. You can also send it to Jeff Triplett and Will Vincent
who run Django News ( https://django-news.com/ ).

On Fri, 19 Mar 2021 at 23:56, Warren Chu  wrote:

> Hi All,
>
> We've released the preview version 1.0b1 of the Microsoft SQL Server 3rd
> Party Backend for Django. This version supports Django 2.2, 3.0 and 3.1.
>
> What's coming up next between now and GA release? We are re-adding
> optional regex support, so that the regex DLL file is downloadable from a
> trusted Microsoft downloads page. This file can then be installed in SQL
> Server via our project script. This follows our organizational security
> best practices.
>
> If you have any questions, feel free to post here in the Django Developer
> forum, or via Github issues at: https://github.com/microsoft/mssql-django
>
> Thanks,
> Warren
>
> --
> 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/93188f91-c638-4e4d-89ee-e4b63585ab38n%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/CAMyDDM3VX%2B%2Bkm5fDY1r1yD8ZkgK9S_s%3D91HCf6_EQDkfnzPY_w%40mail.gmail.com.

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

[Mariusz Felisiak]

Can you provide a small project to reproduce?

Best,
Mariusz

-- 
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/7ec9eda9-0e8f-40b0-be3f-6f5d59769c60n%40googlegroups.com.

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

[Caram Dache]

My bad, I should have read the documentation more thoroughly before.

However, when I set DEFAULT_AUTO_FIELD to BigAutoField and run the
migration, I get errors like the following. This was what troubled me in
the first place:

django.db.utils.IntegrityError: (1452, 'Cannot add or update a child row: a
foreign key constraint fails (`djpat`.`#sql-bb7_1e84`, CONSTRAINT
`myapp_logentry_extension_id_8856aeec_fk` FOREIGN KEY (`extension_id`)
REFERENCES `myapp_extension` (`id`))')

Caram

Le jeu. 25 mars 2021 à 18:07, Mariusz Felisiak 
a écrit :

> Caram, I don't see any issue here. As far as I'm aware you're using the
> auto-created primary key. If you want to get rid of warnings and avoid
> unwanted migrations in the future, set DEFAULT_AUTO_FIELD
> 
> to AutoField
> 
> .
>
> See release notes
> 
> for more details.
>
> #32367 is about inherited PKs, so it's not related with your report.
>
> Best,
> Mariusz
>
> --
> 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/bwP-ft6aXdI/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/475b0c2d-14f8-4a1e-8889-87783557cdc2n%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/CAMApSx2poMnBe_MjS%3D6MCMNhaKi4sDKe-2A-x6jfbrizxSUVPw%40mail.gmail.com.

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

['Adam Johnson' via Django developers (Contributions to Django itself)]

That would be counter to how all current dict based settings work, so I
think it would be too surprising.

On Fri, 26 Mar 2021 at 05:35, chris.j...@gmail.com 
wrote:

> I just came across this thread after seeing a related PR. Rather than a
> "get_security_header()" function, couldn't Django make the setting an
> object that is accessed by the user like a dict, but internally (underneath
> the hood) it tries from a user-defined dict and then falls back to a value
> in a Django-defined dict of defaults?
>
> --Chris
>
>
> On Sunday, January 24, 2021 at 1:08:24 PM UTC-8 timog...@gmail.com wrote:
>
>> If we go with something like:
>>
>> SECURITY_HEADERS = {
>> "REFERRER_POLICY": "same-origin",
>> "HSTS": {
>> "PRELOAD": True,
>> "SECONDS": 1_000_000,
>>  },
>> }
>>
>> should we have an empty dictionary as the default or a dictionary with
>> defaults for all settings?
>>
>> A drawback of an empty dictionary is that any code that wants to retrieve
>> a setting has to do something like
>> settings.SECURITY_HEADERS.get('REFERRER_POLICY', '') which
>> means the fallback value is duplicated every place the setting is
>> consulted.  Maybe a way to mitigate that is to add a
>> "get_security_header()" function that retrieves from django.conf.settings
>> (user-defined settings) and falls back to some defaults.
>>
>> A drawback of a fully-populated default is that overriding it either
>> requires users to redefine the entire dictionary or writing code like:
>>
>> from django.conf.global_settings import SECURITY_HEADERS
>> SECURITY_HEADERS['REFERRER_POLICY'] = '...'
>>
>> If users redefine the entire dictionary, then adding new SECURITY_HEADERS
>> options in future Django versions will require something like
>> "get_security_header()" since we won't be able to assume the key is there
>> in projects upgrading from older versions.
>>
>> I'm not so sure the benefit of consolidating to a single setting is worth
>> this additional complexity.
>> On Tuesday, January 19, 2021 at 8:27:58 AM UTC-5 Adam Johnson wrote:
>>
>>> 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, 

Re: Django Project idea query

[Muskan Vaswan]

This is something that I find myself interested in too! Specifically in the 
part involving AVS.

Here is a little confusion I have:
So far, ASV hasn't been integrated into djangobench repo itself (If I'm not 
missing anything too crucial). So, most of the work that has been put in 
thus far has been on this repository 
 by David Smith, right?
Would a task for GSoC be then, to migrate more of Django's benchmarks to 
ASV, and add them to this repository? Or would it be to add AVS to the 
django/djangobench repository itself? Basically, where would we be expected 
to contribute, in other words, to which of the repositories would it make 
more sense to contribute to?

*Khushi*, having a shared interest in this topic that has so many 
possibilities, it perhaps might be helpful for us to navigate the project 
together and help each other out! 

Regards
Muskan Vaswan


On Wednesday, 24 March 2021 at 16:38:39 UTC+5:30 khushik...@gmail.com wrote:

> Hello Carlton!
> Thank you for guiding me, I am looking into the bugs and will let you know 
> if I am stuck anywhere.
> I appreciate that you were able to give some suggestions on how to move 
> forward.
> Yours sincerely
> Khushi
>
> On Wednesday, 24 March 2021 at 14:24:29 UTC+5:30 carlton...@gmail.com 
> wrote:
>
>> Hi Khushi. 
>>
>> Thanks for the interest. This is a good topic. 
>>
>> Particularly with the async changes it's really important that we can 
>> profile changes. 
>> See https://github.com/django/django/pull/13651
>> This adds async signal dispatch, which would allow us a fully-async 
>> request-response pathway (assuming you didn't use sync components inside 
>> that)
>> *but *it's currently stalled for the performance concerns. 
>> That's just one example. 
>>
>> From https://github.com/django/djangobench/issues/38
>> First step I'd say is to see if you can set up the benchmarking (and ASV) 
>> locally, and get playing with it. 
>> Then I'd play a bit and comment with your first impressions (I'd say 
>> 'findings' but that might imply more than you really need — just get going)
>>
>> David has been pushing the effort there, in his free time, and I'm quite 
>> sure he'd welcome input. 
>> I know others are very keen in this area and will jump in as soon as you 
>> show progress. 
>>
>> Hopefully that gets you started. (Summary: Get up and running, then I'm 
>> sure you can get more feedback.) 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote:
>>
>>> Hello All!
>>> I am participating in GSOC 2021. I was looking at some of the project 
>>> lists and I am interested in the Django Benchmarking project idea. I would 
>>> like to know more about the tasks and operations involved in this project 
>>> idea. I am looking forward to contributing to the Django committee with my 
>>> work.
>>> Thank you
>>>
>>>  
>>>
>>

-- 
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/e141e3c8-5962-4e74-97c7-09b2d9dbc33cn%40googlegroups.com.