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

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

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, 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 

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

[Mariusz Felisiak]

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 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/475b0c2d-14f8-4a1e-8889-87783557cdc2n%40googlegroups.com.

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

[Caram]

Sorry, I meant to do that. Here's the link to the ticket:
https://code.djangoproject.com/ticket/32367

I get an output similar to that of the ticket when I run `./manage 
makemigrations`:

HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
AppConfig.default_auto_field attribute to point to a subclass of AutoField, 
e.g. 'django.db.models.BigAutoField'.
myapp.MyClass: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
AppConfig.default_auto_field attribute to point to a subclass of AutoField, 
e.g. 'django.db.models.BigAutoField'.

(duplicated about 30 times because I have many such classes) 

The primary key for these models has not changed since Django 0.90 and 
there was no issue in Django 3.1.
It started output HINT messages in Django 3.2 beta 1.
I have the same behaviour in Django 3.2 rc 1.

When I try the suggested workaround from the ticket, i.e.:
   DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

the migrations files contain the following migrations which I neeed to 
remove manually:

migrations.AlterField(
model_name='myclass',
name='id',
field=models.BigAutoField(auto_created=True, primary_key=True, 
serialize=False, verbose_name='ID'),
),

Caram

Le jeudi 25 mars 2021 à 15:55:27 UTC+1, timog...@gmail.com a écrit :

> Hi, It would be helpful to link to the ticket and/or explain the issue in 
> more detail.
>
> On Thursday, March 25, 2021 at 9:28:09 AM UTC-4 Caram wrote:
>
>>
>> This issue was raised in alpha1, but I still had the issue in beta1 and 
>> now also in rc1.
>>
>> As a result, I have to manually edit the migrations files and remove 
>> lines that alter fields to become BigField().
>>
>> Has this really been fixed? Am I missing something obvious?
>>
>> Caram
>>
>

-- 
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/8c50cb23-9fe2-44a2-afac-e0632b791476n%40googlegroups.com.

Addressing django and graphql ecosystem

[Diptesh Choudhuri]

Hello everyone, hope you are all doing well!

Despite there being a few tools to integrate GraphQL with Django, the 
community stance towards their union is "it could be much better". This is 
expected, since though these tools exist, they are not made with the best 
developer experience in mind. Their development is very slow if not 
completely unmaintained. Unfortunately this pitiable condition of Django 
and GraphQL turns many developers away from using Django for their GraphQL 
projects.
*Project
 
Idea*
I would like to work on a library that is tightly coupled to django's 
existing and foolproof concepts of Views and Models. Just like django rest 
framework has class based views like DetailView, ListView and the other 
concrete 
view classes 
,
 
I would like to implement them in this package.

Next, I plan to tackle authentication using both token and then using JWT. 
I have already implemented a package to achieve token based authentication 
using this  package and I 
plan to integrate it with this new project itself. JWT is slightly trickier 
for me and I would have to carefully plan how to go about implementing it.

Pagination is another complex topic which takes some time to develop 
schemas for. Though I have not figured out how to actually implement this 
yet, I will try to develop a basic plan to do it efficiently.

Exception handling is another core feature that needs to be taken special 
care of. As mentioned in this  answer, 
GraphQL generally returns a status code of either *200 *OR *500 (*if 
something went really bad). Since it is not possible for clients to check 
if a request actually succeeded on the basis of the returned status code, 
it becomes imperative to return error messages that clearly explain what 
went wrong. I plan to make error handling a breeze by making some helper 
modules.

Though there are existing (and arguably better) packages to do, I have also 
planned on creating serializers 
, if time 
permits me.

Finally, I have decided to build this package on top on ariadne 
 and not graphene-django 
*.* This is because 
there are various design flaws in the latter which make it very unwieldy to 
use, especially while trying to return errors in your response. Though 
ariadne is newer compared to graphene, it is generally, in my experience, 
more stable, easier to use and also support file uploads.

Please let me know what you think about this and whether I should go 
forward with this idea for GSOC.

Regards
Diptesh Choudhuri

PS: *I have also* *started preparing a very much work in progress proposal 
here 
,
 
if you are interested.*

-- 
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/37620d9a-7c28-471b-9fa8-d92d8ced6181n%40googlegroups.com.

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

[Tim Graham]

Hi, It would be helpful to link to the ticket and/or explain the issue in 
more detail.

On Thursday, March 25, 2021 at 9:28:09 AM UTC-4 Caram wrote:

>
> This issue was raised in alpha1, but I still had the issue in beta1 and 
> now also in rc1.
>
> As a result, I have to manually edit the migrations files and remove lines 
> that alter fields to become BigField().
>
> Has this really been fixed? Am I missing something obvious?
>
> Caram
>

-- 
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/7d7a94c3-e9bf-46bd-bebc-4fb35b97150cn%40googlegroups.com.

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

[Caram]

This issue was raised in alpha1, but I still had the issue in beta1 and now 
also in rc1.

As a result, I have to manually edit the migrations files and remove lines 
that alter fields to become BigField().

Has this really been fixed? Am I missing something obvious?

Caram

-- 
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/1c5c1726-f21c-42a9-97e2-857a83a44e58n%40googlegroups.com.

Fellow Reports -- March 2021

[Carlton Gibson]

Hi all. 


Calendar Week 9 -- ending 07 March.


Triaged:

https://code.djangoproject.com/ticket/32504 -- Update admins jQuery 
to 3.6.X. (Accepted)
https://code.djangoproject.com/ticket/32412 -- User.has_perm should forward 
**kwargs to allow more flexibility in authentication backends (wontfix)
https://code.djangoproject.com/ticket/32484 -- Cant access inherited 
fields from multi-table inherited model when using apps from 
MigrationExecutor (needsinfo)
https://code.djangoproject.com/ticket/32464 -- Enable detaching 
of file from FileField and ImageField (wontfix)
https://code.djangoproject.com/ticket/32493 -- Remove unnecessary use of 
never_cache in admin views (Accepted)



Reviewed:

https://github.com/django/django/pull/13299 -- Fixed #31867 -- Made 
TabularInline handling of hidden fields with view-only permissions 
consistent with StackedInline.
https://code.djangoproject.com/ticket/28426 -- Add HTTP authentication 
support to startproject --template
https://github.com/django/django/pull/14075 -- Refs #32483 -- Docd 
caveat about using JSONField key transforms to booleans with 
QuerySet.values()/values_list() on SQLite.
https://github.com/django/django/pull/14056 -- Fixed #27854 -- Added system 
check for nonexistent directories in STATICFILES_DIRS setting.
https://github.com/django/django/pull/13981 -- Refs #32412 -- Adjusted 
Contributing Guide start page.
https://github.com/django/django/pull/14072 -- Updated links to 
djangoproject.com/code.djangoproject.com repositories.
https://github.com/django/django/pull/14066 -- Fixed #32493 - Remove 
unnecessary uses of never_cache from admin views



Authored:

https://github.com/django/channels/pull/1645 -- Adjusted tox config for 
Django 3.2 beta.




Calendar Week 10 -- ending 14 March.


Triaged:

https://code.djangoproject.com/ticket/32513 -- SQLite3 Backend Falsly 
claims SQLite does not support Timezone aware DateTimes (invalid)
https://code.djangoproject.com/ticket/32518 -- Document that 
QuerySet.contains() should not be overused. (Accepted)
https://code.djangoproject.com/ticket/32531 -- Cache key not learnt for 304 
responses — view must keep redoing work until fresh request 
comes in! (invalid)
https://code.djangoproject.com/ticket/32535 -- Include reference to 
DEBUG_PROPAGATE_EXCEPTIONS in middleware docs (Accepted)
https://code.djangoproject.com/ticket/32523 -- Warn when trying to use a 
widget as a field in a form (wontfix)



Reviewed:

https://github.com/django/django/pull/14104 -- Fixed #32529 -- Delayed 
creating a test suite in build_suite().
https://code.djangoproject.com/ticket/26790 -- Move 
BaseUserManager.normalize_email() to AbstractUser
https://github.com/django/django/pull/14090 -- Add a message to new 
contributors when they open a PR
https://github.com/django/django/pull/14106 -- Removed unnecessary lines in 
test_has_view_or_change_permission_required().
https://github.com/django/django/pull/14031 -- Fixed #32466 -- Changed 
to_field_name for m2m releations to pk
https://github.com/django/django/pull/14095 -- Refs #32018 -- Corrected 
color variable for toggle links in admin.
https://github.com/django/django/pull/14096 -- Refs #32018 -- Used 
--darkened-bg for pre elements.
https://github.com/django/djangoproject.com/pull/1039 -- Switch Dockerfile 
to Python 3.6 #1039
https://github.com/django/djangoproject.com/pull/1069 -- Added missing 
translatable strings in docs template.
https://github.com/django/django/pull/14097 -- Updated link to Selenium 
webdrivers.
https://github.com/django/django/pull/14086 -- Server sent events



Authored:

https://github.com/django/djangoproject.com/pull/1073 -- Updated Sentry SDK.
https://github.com/django/djangoproject.com/pull/1072 -- Refs #1052 -- 
Added max_value validation to donations.





Calendar Week 11 -- ending 21 March.


Released Django 3.2rc1


Triaged:

https://code.djangoproject.com/ticket/32567 -- Issues with : 
and | characters in URLs when using LiveServerTestCase on 
Windows (Accepted)
https://code.djangoproject.com/ticket/32565 -- Extract URL resolver view 
strings mapping to admindocs (Accepted)
https://code.djangoproject.com/ticket/32563 -- Cannot override database 
used with RelatedManager (invalid)
https://code.djangoproject.com/ticket/32562 -- Broken Authentication 
(Insecure CSRF and Session ID) (needsinfo)
https://code.djangoproject.com/ticket/32561 -- Unpacking request.GET into a 
function call turns the values into lists with one item. (invalid)
https://code.djangoproject.com/ticket/32543 -- Add `search_help_text` to 
`admin.ModelAdmin` (Accepted)
https://code.djangoproject.com/ticket/32513 -- SQLite3 Backend Falsly 
claims SQLite does not support Timezone aware DateTimes (wontfix)
https://code.djangoproject.com/ticket/32552 -- Change DiscoverRunner to use 
a logger instead of print (Accepted)



Reviewed:

https://github.com/django/django/pull/14031 -- Fixed #32466 -- Corrected 
autocomplete to_field resolution for complex cases.