Re: Wanting to Contribute

[Carlton Gibson]

OK, this was reported as https://code.djangoproject.com/ticket/31765, 
something* to do with macOS's bundled SQLite. 
* technical term. 

There's a workaround in master — 
https://github.com/django/django/commit/80a8be03d9321669a239dbced8ac48a4e7e1
 
I assume you're running against that, so can you perhaps comment on the 
issue with your `platform.mac_ver()` and we can have a look. 

Thanks! 

On Tuesday, 12 January 2021 at 20:13:28 UTC+1 skyle...@gmail.com wrote:

> I got 'testing' returned. With that command I'm getting:
>
> (django-2) skylercain:~/code/django [master]$ python -c "import sqlite3; 
> print(sqlite3.sqlite_version)"
> 3.32.3
>
> Should I try an earlier version?
>
> On Tue, Jan 12, 2021 at 10:43 AM Carlton Gibson  
> wrote:
>
>> > I ran your code to set and test the DYLD_LIBRARY_PATH and the first 
>> example worked for me.
>>
>> Did it give None or ‘testing’ — only if the latter is the environment 
>> variable reaching the Python process. (So only they can you override the 
>> default version)
>>
>> ~ $ python -c "import sqlite3; print(sqlite3.sqlite_version)"
>> 3.32.3
>>
>> Minimum version is currently 3.8.3
>> https://docs.djangoproject.com/en/3.1/ref/databases/#sqlite-notes
>>
>>
>> On Tue, 12 Jan 2021 at 18:27, Skyler Cain  wrote:
>>
>>> I ran the code to ensure that JSON1 extension is working within sqlite3. 
>>> Can I check which version I need -- is that somewhere? Also if the JSON1 
>>> extension is working what other functionality do I need to check for? 
>>>
>>> I was not using a customly installed version of python -- which I've now 
>>> switched to. However I'm still getting the same error message. I ran your 
>>> code to set and test the DYLD_LIBRARY_PATH and the first example worked for 
>>> me.
>>>
>>> Thanks for your help I'd like to get everything working if possible then 
>>> move on to PostgreSQL.
>>>
>>> On Tue, Jan 12, 2021 at 9:13 AM Carlton Gibson  
>>> wrote:
>>>
 Hi Skyler. 

 Welcome. 

 That’ll be your SQLite version. 

 MacOS tends to bundle an old one — and updating can be a little tricky 
 because of the “System integrity protection”, not letting you specify a 
 DYLD_LIBRARY_PATH.

 See the instructions here for getting a newer SQLite version: 

 https://code.djangoproject.com/wiki/JSON1Extension

 It might not work because of SIP. 

 Try this: 

 ~ $ DYLD_LIBRARY_PATH="testing" python -c "import os; 
 print(os.getenv('DYLD_LIBRARY_PATH'))"
 None

 If you get that your Python is running via SIP. You’ll need to install 
 Python in your home folder somewhere. 

 I use pyenv but the shims that use still go view /bin/env, so SIP is in 
 play. 

 You have to do this kind of thing: 

 ~ $ DYLD_LIBRARY_PATH="testing" $(pyenv which python) -c "import os; 
 print(os.getenv('DYLD_LIBRARY_PATH'))"
 testing

 Hopefully that makes sense and helps. If not reply and I’ll see if I 
 can help some more. 

 You can always ignore the failure, or use Postgres: 
 https://postgresapp.com is a very easy to get going with. 

 Kind regards, Carlton 

 On Tue, 12 Jan 2021 at 16:50, Skyler Cain  wrote:

> Hello all!
>
> I've read this: 
> https://docs.djangoproject.com/en/3.1/intro/contributing/
>
> But after running my tests I get the following failure (when running 
> all or individual). Any thoughts / suggestions would be much appreciated.
>
> (django) skylercain:~/code/django/tests [master]$ ./runtests.py 
> schema.tests.SchemaTests.test_db_table
> Testing against Django installed in 
> '/Users/skylercain/code/django/django'
> Creating test database for alias 'default'...
> System check identified no issues (0 silenced).
> F
> ==
> FAIL: test_db_table (schema.tests.SchemaTests)
> Tests renaming of the table
> --
> Traceback (most recent call last):
>   File "/Users/skylercain/code/django/django/test/utils.py", line 382, 
> in inner
> return func(*args, **kwargs)
>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 
> 2339, in test_db_table
> self.assertForeignKeyExists(Book, "author_id", 
> "schema_otherauthor")
>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 
> 213, in assertForeignKeyExists
> self.assertEqual(constraint_fk, (expected_fk_table, field))
> AssertionError: Tuples differ: ('schema_author', 'id') != 
> ('schema_otherauthor', 'id')
>
> First differing element 0:
> 'schema_author'
> 'schema_otherauthor'
>
> - ('schema_author', 'id')
> + ('schema_otherauthor', 'id')
> ?  +
>
>
> 

Re: Wanting to Contribute

[Skyler Cain]

I got 'testing' returned. With that command I'm getting:

(django-2) skylercain:~/code/django [master]$ python -c "import sqlite3;
print(sqlite3.sqlite_version)"
3.32.3

Should I try an earlier version?

On Tue, Jan 12, 2021 at 10:43 AM Carlton Gibson 
wrote:

> > I ran your code to set and test the DYLD_LIBRARY_PATH and the first
> example worked for me.
>
> Did it give None or ‘testing’ — only if the latter is the environment
> variable reaching the Python process. (So only they can you override the
> default version)
>
> ~ $ python -c "import sqlite3; print(sqlite3.sqlite_version)"
> 3.32.3
>
> Minimum version is currently 3.8.3
> https://docs.djangoproject.com/en/3.1/ref/databases/#sqlite-notes
>
>
> On Tue, 12 Jan 2021 at 18:27, Skyler Cain  wrote:
>
>> I ran the code to ensure that JSON1 extension is working within sqlite3.
>> Can I check which version I need -- is that somewhere? Also if the JSON1
>> extension is working what other functionality do I need to check for?
>>
>> I was not using a customly installed version of python -- which I've now
>> switched to. However I'm still getting the same error message. I ran your
>> code to set and test the DYLD_LIBRARY_PATH and the first example worked for
>> me.
>>
>> Thanks for your help I'd like to get everything working if possible then
>> move on to PostgreSQL.
>>
>> On Tue, Jan 12, 2021 at 9:13 AM Carlton Gibson 
>> wrote:
>>
>>> Hi Skyler.
>>>
>>> Welcome.
>>>
>>> That’ll be your SQLite version.
>>>
>>> MacOS tends to bundle an old one — and updating can be a little tricky
>>> because of the “System integrity protection”, not letting you specify a
>>> DYLD_LIBRARY_PATH.
>>>
>>> See the instructions here for getting a newer SQLite version:
>>>
>>> https://code.djangoproject.com/wiki/JSON1Extension
>>>
>>> It might not work because of SIP.
>>>
>>> Try this:
>>>
>>> ~ $ DYLD_LIBRARY_PATH="testing" python -c "import os;
>>> print(os.getenv('DYLD_LIBRARY_PATH'))"
>>> None
>>>
>>> If you get that your Python is running via SIP. You’ll need to install
>>> Python in your home folder somewhere.
>>>
>>> I use pyenv but the shims that use still go view /bin/env, so SIP is in
>>> play.
>>>
>>> You have to do this kind of thing:
>>>
>>> ~ $ DYLD_LIBRARY_PATH="testing" $(pyenv which python) -c "import os;
>>> print(os.getenv('DYLD_LIBRARY_PATH'))"
>>> testing
>>>
>>> Hopefully that makes sense and helps. If not reply and I’ll see if I can
>>> help some more.
>>>
>>> You can always ignore the failure, or use Postgres:
>>> https://postgresapp.com is a very easy to get going with.
>>>
>>> Kind regards, Carlton
>>>
>>> On Tue, 12 Jan 2021 at 16:50, Skyler Cain  wrote:
>>>
 Hello all!

 I've read this:
 https://docs.djangoproject.com/en/3.1/intro/contributing/

 But after running my tests I get the following failure (when running
 all or individual). Any thoughts / suggestions would be much appreciated.

 (django) skylercain:~/code/django/tests [master]$ ./runtests.py
 schema.tests.SchemaTests.test_db_table
 Testing against Django installed in
 '/Users/skylercain/code/django/django'
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 F
 ==
 FAIL: test_db_table (schema.tests.SchemaTests)
 Tests renaming of the table
 --
 Traceback (most recent call last):
   File "/Users/skylercain/code/django/django/test/utils.py", line 382,
 in inner
 return func(*args, **kwargs)
   File "/Users/skylercain/code/django/tests/schema/tests.py", line
 2339, in test_db_table
 self.assertForeignKeyExists(Book, "author_id", "schema_otherauthor")
   File "/Users/skylercain/code/django/tests/schema/tests.py", line 213,
 in assertForeignKeyExists
 self.assertEqual(constraint_fk, (expected_fk_table, field))
 AssertionError: Tuples differ: ('schema_author', 'id') !=
 ('schema_otherauthor', 'id')

 First differing element 0:
 'schema_author'
 'schema_otherauthor'

 - ('schema_author', 'id')
 + ('schema_otherauthor', 'id')
 ?  +


 --
 Ran 1 test in 0.015s

 FAILED (failures=1)
 Destroying test database for alias 'default'...

 --
 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/75e140c4-facf-456f-8605-80a72662cf03n%40googlegroups.com
 

Re: Status of 3.2 release blockers.

[Paolo Melchiorre]

I agree with Adam.

I've also left a small comment on the PR.

Paolo

On Tue, Jan 12, 2021 at 5:59 PM Adam Johnson  wrote:
>
> I think it's worth merging into 3.2. The change is quite small, the potential 
> benefits are quite large, and some users live LTS to LTS so could be left 
> without an option for a long time.
>
> I've left some review comments on the PR.
>
> On Tue, 12 Jan 2021 at 15:29, Paul Ganssle  wrote:
>>
>> Yeah, sorry I didn't get around to this until so close to the deadline. 
>> December was a lot crazier for me than I had hoped. ☹
>>
>> One thing I'll note is that this PR to allow using zoneinfo timezones is 
>> mostly just adding tests. The substantive changes to the codebase are very 
>> light, and there should be no behavioral change for users of pytz or current 
>> users of other time zone providers (assuming such people exist). There 
>> appears to be a nominal attempt to support non-pytz zones in 
>> django.utils.timezones, so possibly this PR just improves support that was 
>> already intended to be present in the first place.
>>
>> I do think it would be good to make it possible for people to do some 
>> conversion over ahead of time if possible, particularly since no deprecation 
>> warnings will be issued prior to the change away from pytz.
>>
>> Best,
>> Paul
>>
>> On 1/12/21 10:12 AM, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> Paul Ganssle has followed up his earlier PoC PR, and the previous 
>> discussion, with a smaller PR in order to allow using zoneinfo timezones 
>> without an error:
>>
>> Add support for non-pytz zones
>> https://github.com/django/django/pull/13877
>>
>> The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to 
>> zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if 
>> needed.)
>>
>> First glance, it looks OK, great even (absolutely as expected from Paul).
>>
>> I don't have capacity to properly sit down with it before the feature freeze 
>> (due Thursday) though.
>> So if it were just me, I'd have to say it's too hot, too close to the 
>> deadline, and we should just target 4.0
>>
>> However, maybe others, and the Technical Board who have the authority to 
>> specify, think that this is something we should take the extra time if 
>> needed and make sure we get in for 3.2?
>> (Any extra eyes reviewing would help in that case.)
>>
>> As per Aymeric's point on the previous discussion, it's likely this doesn't 
>> affect most of our users.
>> Paul's concern is that Django incompatibility (along with Pandas he 
>> mentioned in discussion) is blocking adoption throughout the community.
>> That's not necessarily our problem, but maybe this is a small enough change 
>> that we should be flexible here?
>> With 3.2 being the next LTS, it'll be around for a while (which is relevant 
>> I think).
>>
>> Can I ask for opinions please? Again, the option is to say that we'll 
>> squeeze this in if review is fine.
>> The feature freeze isn't cast in stone, but we do have to draw the line 
>> somewhere.
>> This one is sufficiently interesting that Mariusz and I don't want to just 
>> decide with consultation.
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>>
>> On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote:
>>>
>>> Hi all,
>>>
>>> Happy New Year!
>>>
>>> Time to begin release process for the next major release, Django 3.2!
>>>
>>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>>>
>>> The 3.2 feature freeze is scheduled for January 14.
>>> We'll probably release the alpha that day.
>>>
>>> We have a few larger patches we want to finish reviewing:
>>>
>>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added support 
>>> for functional indexes.
>>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support 
>>> rotation of secret keys.
>>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted 
>>> admin colors into CSS variables.
>>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed #29138 -- 
>>> Added limit_choices_to and to_field support to autocomplete fields.
>>>
>>> We'll update this thread for any schedule changes.



-- 
Paolo Melchiorre

https://www.paulox.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/CAKFO%2Bx7sbbZCeJmPGmaf%2BfS8ASCYm-WVxS37nKZAEKFsJ%2BgxXA%40mail.gmail.com.

Re: Wanting to Contribute

[Carlton Gibson]

> I ran your code to set and test the DYLD_LIBRARY_PATH and the first
example worked for me.

Did it give None or ‘testing’ — only if the latter is the environment
variable reaching the Python process. (So only they can you override the
default version)

~ $ python -c "import sqlite3; print(sqlite3.sqlite_version)"
3.32.3

Minimum version is currently 3.8.3
https://docs.djangoproject.com/en/3.1/ref/databases/#sqlite-notes


On Tue, 12 Jan 2021 at 18:27, Skyler Cain  wrote:

> I ran the code to ensure that JSON1 extension is working within sqlite3.
> Can I check which version I need -- is that somewhere? Also if the JSON1
> extension is working what other functionality do I need to check for?
>
> I was not using a customly installed version of python -- which I've now
> switched to. However I'm still getting the same error message. I ran your
> code to set and test the DYLD_LIBRARY_PATH and the first example worked for
> me.
>
> Thanks for your help I'd like to get everything working if possible then
> move on to PostgreSQL.
>
> On Tue, Jan 12, 2021 at 9:13 AM Carlton Gibson 
> wrote:
>
>> Hi Skyler.
>>
>> Welcome.
>>
>> That’ll be your SQLite version.
>>
>> MacOS tends to bundle an old one — and updating can be a little tricky
>> because of the “System integrity protection”, not letting you specify a
>> DYLD_LIBRARY_PATH.
>>
>> See the instructions here for getting a newer SQLite version:
>>
>> https://code.djangoproject.com/wiki/JSON1Extension
>>
>> It might not work because of SIP.
>>
>> Try this:
>>
>> ~ $ DYLD_LIBRARY_PATH="testing" python -c "import os;
>> print(os.getenv('DYLD_LIBRARY_PATH'))"
>> None
>>
>> If you get that your Python is running via SIP. You’ll need to install
>> Python in your home folder somewhere.
>>
>> I use pyenv but the shims that use still go view /bin/env, so SIP is in
>> play.
>>
>> You have to do this kind of thing:
>>
>> ~ $ DYLD_LIBRARY_PATH="testing" $(pyenv which python) -c "import os;
>> print(os.getenv('DYLD_LIBRARY_PATH'))"
>> testing
>>
>> Hopefully that makes sense and helps. If not reply and I’ll see if I can
>> help some more.
>>
>> You can always ignore the failure, or use Postgres:
>> https://postgresapp.com is a very easy to get going with.
>>
>> Kind regards, Carlton
>>
>> On Tue, 12 Jan 2021 at 16:50, Skyler Cain  wrote:
>>
>>> Hello all!
>>>
>>> I've read this:
>>> https://docs.djangoproject.com/en/3.1/intro/contributing/
>>>
>>> But after running my tests I get the following failure (when running all
>>> or individual). Any thoughts / suggestions would be much appreciated.
>>>
>>> (django) skylercain:~/code/django/tests [master]$ ./runtests.py
>>> schema.tests.SchemaTests.test_db_table
>>> Testing against Django installed in
>>> '/Users/skylercain/code/django/django'
>>> Creating test database for alias 'default'...
>>> System check identified no issues (0 silenced).
>>> F
>>> ==
>>> FAIL: test_db_table (schema.tests.SchemaTests)
>>> Tests renaming of the table
>>> --
>>> Traceback (most recent call last):
>>>   File "/Users/skylercain/code/django/django/test/utils.py", line 382,
>>> in inner
>>> return func(*args, **kwargs)
>>>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 2339,
>>> in test_db_table
>>> self.assertForeignKeyExists(Book, "author_id", "schema_otherauthor")
>>>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 213,
>>> in assertForeignKeyExists
>>> self.assertEqual(constraint_fk, (expected_fk_table, field))
>>> AssertionError: Tuples differ: ('schema_author', 'id') !=
>>> ('schema_otherauthor', 'id')
>>>
>>> First differing element 0:
>>> 'schema_author'
>>> 'schema_otherauthor'
>>>
>>> - ('schema_author', 'id')
>>> + ('schema_otherauthor', 'id')
>>> ?  +
>>>
>>>
>>> --
>>> Ran 1 test in 0.015s
>>>
>>> FAILED (failures=1)
>>> Destroying test database for alias 'default'...
>>>
>>> --
>>> 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/75e140c4-facf-456f-8605-80a72662cf03n%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/TvGYJyj-ouo/unsubscribe
>> .
>> To unsubscribe from this group 

Re: Adding Origin header checking to CSRF middleware (#16010)

[Adam Johnson]

Hi Tim,

Thanks for working on this. I've put together some replies to your points
here.

On #1 - I think it's legitimate to have `CSRF_TRUSTED_ORIGINS` require the
schemes. I think the setting should have included them all along, since a
scheme is part of the definition of an origin. It's backwards incompatible
but the workaround when supporting multiple Django versions would be fairly
simple, for example:

```
CSRF_TRUSTED_ORIGINS = [
"example.com",
]
if django.VERSION >= (4, 0):
CSRF_TRUSTED_ORIGINS = [f"https://{origin}; for origin in
CSRF_TRUSTED_ORIGINS]
```

We could also provide temporary, immediately-deprecated support for origins
without schemes by interpreting them as "http" and "https" by default.

I didn't add the regex support to django-cors-headers and I don't like it,
since a malformed regex could cause a security hole.

On #2 - see above, no new setting.

On #3 - agreed. This will allow sites to drop the Referer header completely
for privacy, if they want, by setting SECURE_REFERRER_POLICY =
'no-referrer'.

On #4 - the "privacy-sensitive contexts" listed on OWASP all seem to be
things that would only trigger GET requests. It might even be legitimate to
fail CSRF if origin is null, since CSRF is skipped for GET's.

Thanks,

Adam

On Tue, 12 Jan 2021 at 12:18, Tim Graham  wrote:

> OWASP Cheat Sheet says, "It is important to note that [the SameSite
> Cookie] attribute should be implemented as an additional layer *defense
> in depth* concept. This attribute protects the user through the browsers
> supporting it, and it contains as well 2 ways to bypass it as mentioned in
> the following section
> .
> This attribute should not replace having a CSRF Token. Instead, it should
> co-exist with that token in order to protect the user in a more robust way."
> On Tuesday, January 12, 2021 at 5:44:56 AM UTC-5 jacob...@gmail.com wrote:
>
>> Shouldn't we consider to put the CSRF token onto the deprecation list
>> anyway?
>> All browsers released later than 2017 support the 'SameSite' cookie
>> attribute , making the CSRF token
>> obsolete.
>> I don't know what kind of policy the Django Project follows in
>> deprecating browsers, but we can expect
>> that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when
>> Django-4 (or maybe 5?) will be released.
>>
>> Strictly speaking, the CSRF token is a hack/workaround which in an ideal
>> world shouldn't be required anyway.
>> And it always has been painful having to fiddle with it in my Django Form
>> Views.
>>
>> Just my two cents,
>> Jacob
>>
> --
> 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/915ff447-502e-45c2-8d18-bf5bee848c52n%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/CAMyDDM2W4oqC4ZcC29YbeJ6uPP%2BV-q2B6Y%2Bg%3DCJver5ygArw8Q%40mail.gmail.com.

Re: Wanting to Contribute

[Skyler Cain]

I ran the code to ensure that JSON1 extension is working within sqlite3.
Can I check which version I need -- is that somewhere? Also if the JSON1
extension is working what other functionality do I need to check for?

I was not using a customly installed version of python -- which I've now
switched to. However I'm still getting the same error message. I ran your
code to set and test the DYLD_LIBRARY_PATH and the first example worked for
me.

Thanks for your help I'd like to get everything working if possible then
move on to PostgreSQL.

On Tue, Jan 12, 2021 at 9:13 AM Carlton Gibson 
wrote:

> Hi Skyler.
>
> Welcome.
>
> That’ll be your SQLite version.
>
> MacOS tends to bundle an old one — and updating can be a little tricky
> because of the “System integrity protection”, not letting you specify a
> DYLD_LIBRARY_PATH.
>
> See the instructions here for getting a newer SQLite version:
>
> https://code.djangoproject.com/wiki/JSON1Extension
>
> It might not work because of SIP.
>
> Try this:
>
> ~ $ DYLD_LIBRARY_PATH="testing" python -c "import os;
> print(os.getenv('DYLD_LIBRARY_PATH'))"
> None
>
> If you get that your Python is running via SIP. You’ll need to install
> Python in your home folder somewhere.
>
> I use pyenv but the shims that use still go view /bin/env, so SIP is in
> play.
>
> You have to do this kind of thing:
>
> ~ $ DYLD_LIBRARY_PATH="testing" $(pyenv which python) -c "import os;
> print(os.getenv('DYLD_LIBRARY_PATH'))"
> testing
>
> Hopefully that makes sense and helps. If not reply and I’ll see if I can
> help some more.
>
> You can always ignore the failure, or use Postgres:
> https://postgresapp.com is a very easy to get going with.
>
> Kind regards, Carlton
>
> On Tue, 12 Jan 2021 at 16:50, Skyler Cain  wrote:
>
>> Hello all!
>>
>> I've read this: https://docs.djangoproject.com/en/3.1/intro/contributing/
>>
>> But after running my tests I get the following failure (when running all
>> or individual). Any thoughts / suggestions would be much appreciated.
>>
>> (django) skylercain:~/code/django/tests [master]$ ./runtests.py
>> schema.tests.SchemaTests.test_db_table
>> Testing against Django installed in '/Users/skylercain/code/django/django'
>> Creating test database for alias 'default'...
>> System check identified no issues (0 silenced).
>> F
>> ==
>> FAIL: test_db_table (schema.tests.SchemaTests)
>> Tests renaming of the table
>> --
>> Traceback (most recent call last):
>>   File "/Users/skylercain/code/django/django/test/utils.py", line 382, in
>> inner
>> return func(*args, **kwargs)
>>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 2339,
>> in test_db_table
>> self.assertForeignKeyExists(Book, "author_id", "schema_otherauthor")
>>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 213,
>> in assertForeignKeyExists
>> self.assertEqual(constraint_fk, (expected_fk_table, field))
>> AssertionError: Tuples differ: ('schema_author', 'id') !=
>> ('schema_otherauthor', 'id')
>>
>> First differing element 0:
>> 'schema_author'
>> 'schema_otherauthor'
>>
>> - ('schema_author', 'id')
>> + ('schema_otherauthor', 'id')
>> ?  +
>>
>>
>> --
>> Ran 1 test in 0.015s
>>
>> FAILED (failures=1)
>> Destroying test database for alias 'default'...
>>
>> --
>> 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/75e140c4-facf-456f-8605-80a72662cf03n%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/TvGYJyj-ouo/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/CAJwKpyQh32UYkxAHma-wRY3WhY36oiuWjhmLCGLm4%2BxGHAgvRQ%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 

Re: Status of 3.2 release blockers.

[Adam Johnson]

I think it's worth merging into 3.2. The change is quite small, the
potential benefits are quite large, and some users live LTS to LTS so could
be left without an option for a long time.

I've left some review comments on the PR.

On Tue, 12 Jan 2021 at 15:29, Paul Ganssle  wrote:

> Yeah, sorry I didn't get around to this until so close to the deadline.
> December was a lot crazier for me than I had hoped. ☹
>
> One thing I'll note is that this PR to allow using zoneinfo timezones is
> *mostly* just adding tests. The substantive changes to the codebase are
> very light, and there should be no behavioral change for users of pytz or
> current users of other time zone providers (assuming such people exist).
> There appears to be a nominal attempt to support non-pytz zones in
> django.utils.timezones, so possibly this PR just improves support that was
> already intended to be present in the first place.
>
> I do think it would be good to make it possible for people to do *some*
> conversion over ahead of time if possible, particularly since no
> deprecation warnings will be issued prior to the change away from pytz.
>
> Best,
> Paul
>
> On 1/12/21 10:12 AM, Carlton Gibson wrote:
>
> Hi all.
>
> Paul Ganssle has followed up his earlier PoC PR, and the previous
> discussion ,
> with a smaller PR in order to *allow* using zoneinfo timezones without an
> error:
>
> Add support for non-pytz zones
> https://github.com/django/django/pull/13877
>
> The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to
> zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if
> needed.)
>
> First glance, it looks OK, great even (absolutely as expected from Paul).
>
> I don't have capacity to properly sit down with it before the feature
> freeze (due Thursday) though.
> So if it were just me, I'd have to say it's too hot, too close to the
> deadline, and we should just target 4.0
>
> However, maybe others, and the Technical Board who have the authority to
> specify, think that this is something we should take the extra time if
> needed and make sure we get in for 3.2?
> (Any extra eyes reviewing would help in that case.)
>
> As per Aymeric's point on the previous discussion, it's likely this
> doesn't affect most of our users.
> Paul's concern is that Django incompatibility (along with Pandas he
> mentioned in discussion) is blocking adoption throughout the community.
> That's not necessarily our problem, but maybe this is a small enough
> change that we should be flexible here?
> With 3.2 being the next LTS, it'll be around for a while (which is
> relevant I think).
>
> Can I ask for opinions please? Again, the option is to say that we'll
> squeeze this in if review is fine.
> The feature freeze isn't cast in stone, but we do have to draw the line
> somewhere.
> This one is sufficiently interesting that Mariusz and I don't want to just
> decide with consultation.
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
>
>
>
> On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote:
>
>> Hi all,
>>
>> Happy New Year!
>>
>> Time to begin release process for the next major release, Django 3.2!
>>
>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>>
>> The 3.2 feature freeze is scheduled for January 14.
>> We'll probably release the alpha that day.
>>
>> We have a few larger patches we want to finish reviewing:
>>
>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added
>> support for functional indexes.
>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support
>> rotation of secret keys.
>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted
>> admin colors into CSS variables.
>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed #29138
>> -- Added limit_choices_to and to_field support to autocomplete fields.
>>
>> We'll update this thread for any schedule changes.
>>
>> 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/cc28eb1d-3f24-4103-8a57-6835e775b11an%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
> 

Re: Wanting to Contribute

[Carlton Gibson]

Hi Skyler.

Welcome.

That’ll be your SQLite version.

MacOS tends to bundle an old one — and updating can be a little tricky
because of the “System integrity protection”, not letting you specify a
DYLD_LIBRARY_PATH.

See the instructions here for getting a newer SQLite version:

https://code.djangoproject.com/wiki/JSON1Extension

It might not work because of SIP.

Try this:

~ $ DYLD_LIBRARY_PATH="testing" python -c "import os;
print(os.getenv('DYLD_LIBRARY_PATH'))"
None

If you get that your Python is running via SIP. You’ll need to install
Python in your home folder somewhere.

I use pyenv but the shims that use still go view /bin/env, so SIP is in
play.

You have to do this kind of thing:

~ $ DYLD_LIBRARY_PATH="testing" $(pyenv which python) -c "import os;
print(os.getenv('DYLD_LIBRARY_PATH'))"
testing

Hopefully that makes sense and helps. If not reply and I’ll see if I can
help some more.

You can always ignore the failure, or use Postgres:
https://postgresapp.com is a very easy to get going with.

Kind regards, Carlton

On Tue, 12 Jan 2021 at 16:50, Skyler Cain  wrote:

> Hello all!
>
> I've read this: https://docs.djangoproject.com/en/3.1/intro/contributing/
>
> But after running my tests I get the following failure (when running all
> or individual). Any thoughts / suggestions would be much appreciated.
>
> (django) skylercain:~/code/django/tests [master]$ ./runtests.py
> schema.tests.SchemaTests.test_db_table
> Testing against Django installed in '/Users/skylercain/code/django/django'
> Creating test database for alias 'default'...
> System check identified no issues (0 silenced).
> F
> ==
> FAIL: test_db_table (schema.tests.SchemaTests)
> Tests renaming of the table
> --
> Traceback (most recent call last):
>   File "/Users/skylercain/code/django/django/test/utils.py", line 382, in
> inner
> return func(*args, **kwargs)
>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 2339,
> in test_db_table
> self.assertForeignKeyExists(Book, "author_id", "schema_otherauthor")
>   File "/Users/skylercain/code/django/tests/schema/tests.py", line 213, in
> assertForeignKeyExists
> self.assertEqual(constraint_fk, (expected_fk_table, field))
> AssertionError: Tuples differ: ('schema_author', 'id') !=
> ('schema_otherauthor', 'id')
>
> First differing element 0:
> 'schema_author'
> 'schema_otherauthor'
>
> - ('schema_author', 'id')
> + ('schema_otherauthor', 'id')
> ?  +
>
>
> --
> Ran 1 test in 0.015s
>
> FAILED (failures=1)
> Destroying test database for alias 'default'...
>
> --
> 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/75e140c4-facf-456f-8605-80a72662cf03n%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/CAJwKpyQh32UYkxAHma-wRY3WhY36oiuWjhmLCGLm4%2BxGHAgvRQ%40mail.gmail.com.

Wanting to Contribute

[Skyler Cain]

Hello all!

I've read this: https://docs.djangoproject.com/en/3.1/intro/contributing/

But after running my tests I get the following failure (when running all or 
individual). Any thoughts / suggestions would be much appreciated.

(django) skylercain:~/code/django/tests [master]$ ./runtests.py 
schema.tests.SchemaTests.test_db_table
Testing against Django installed in '/Users/skylercain/code/django/django'
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
F
==
FAIL: test_db_table (schema.tests.SchemaTests)
Tests renaming of the table
--
Traceback (most recent call last):
  File "/Users/skylercain/code/django/django/test/utils.py", line 382, in 
inner
return func(*args, **kwargs)
  File "/Users/skylercain/code/django/tests/schema/tests.py", line 2339, in 
test_db_table
self.assertForeignKeyExists(Book, "author_id", "schema_otherauthor")
  File "/Users/skylercain/code/django/tests/schema/tests.py", line 213, in 
assertForeignKeyExists
self.assertEqual(constraint_fk, (expected_fk_table, field))
AssertionError: Tuples differ: ('schema_author', 'id') != 
('schema_otherauthor', 'id')

First differing element 0:
'schema_author'
'schema_otherauthor'

- ('schema_author', 'id')
+ ('schema_otherauthor', 'id')
?  +


--
Ran 1 test in 0.015s

FAILED (failures=1)
Destroying test database for alias 'default'...

-- 
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/75e140c4-facf-456f-8605-80a72662cf03n%40googlegroups.com.

Re: Status of 3.2 release blockers.

[Paul Ganssle]

Yeah, sorry I didn't get around to this until so close to the deadline.
December was a lot crazier for me than I had hoped. ☹

One thing I'll note is that this PR to allow using zoneinfo timezones is
/mostly/ just adding tests. The substantive changes to the codebase are
very light, and there should be no behavioral change for users of pytz
or current users of other time zone providers (assuming such people
exist). There appears to be a nominal attempt to support non-pytz zones
in django.utils.timezones, so possibly this PR just improves support
that was already intended to be present in the first place.

I do think it would be good to make it possible for people to do /some/
conversion over ahead of time if possible, particularly since no
deprecation warnings will be issued prior to the change away from pytz.

Best,
Paul

On 1/12/21 10:12 AM, Carlton Gibson wrote:
> Hi all. 
>
> Paul Ganssle has followed up his earlier PoC PR, and the previous
> discussion
> , with a
> smaller PR in order to *allow* using zoneinfo timezones without an error:
>
> Add support for non-pytz zones
> https://github.com/django/django/pull/13877
>
> The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to
> zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if
> needed.) 
>
> First glance, it looks OK, great even (absolutely as expected from Paul). 
>
> I don't have capacity to properly sit down with it before the feature
> freeze (due Thursday) though. 
> So if it were just me, I'd have to say it's too hot, too close to the
> deadline, and we should just target 4.0
>
> However, maybe others, and the Technical Board who have the authority
> to specify, think that this is something we should take the extra time
> if needed and make sure we get in for 3.2? 
> (Any extra eyes reviewing would help in that case.) 
>
> As per Aymeric's point on the previous discussion, it's likely this
> doesn't affect most of our users. 
> Paul's concern is that Django incompatibility (along with Pandas he
> mentioned in discussion) is blocking adoption throughout the community. 
> That's not necessarily our problem, but maybe this is a small enough
> change that we should be flexible here? 
> With 3.2 being the next LTS, it'll be around for a while (which is
> relevant I think). 
>
> Can I ask for opinions please? Again, the option is to say that we'll
> squeeze this in if review is fine. 
> The feature freeze isn't cast in stone, but we do have to draw the
> line somewhere.
> This one is sufficiently interesting that Mariusz and I don't want to
> just decide with consultation. 
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>
>
>
>
> On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote:
>
> Hi all,
>
> Happy New Year! 
>
> Time to begin release process for the next major release, Django 3.2!
>
> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>
> The 3.2 feature freeze is scheduled for January 14. 
> We'll probably release the alpha that day.
>
> We have a few larger patches we want to finish reviewing:
>
> https://github.com/django/django/pull/11929 - Fixed #26167 --
> Added support for functional indexes.
> https://github.com/django/django/pull/13618 - Fixed 30360 --
> Support rotation of secret keys.
> https://github.com/django/django/pull/13435 - Fixed #32018 --
> Extracted admin colors into CSS variables.
> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed
> #29138 -- Added limit_choices_to and to_field support to
> autocomplete fields.
>
> We'll update this thread for any schedule changes. 
>
> 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/cc28eb1d-3f24-4103-8a57-6835e775b11an%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/7e22fc29-d4eb-1141-e389-56d2ace9a0af%40ganssle.io.

Re: Status of 3.2 release blockers.

[Carlton Gibson]

Hi all. 

Paul Ganssle has followed up his earlier PoC PR, and the previous discussion 
, with a 
smaller PR in order to *allow* using zoneinfo timezones without an error:

Add support for non-pytz zones
https://github.com/django/django/pull/13877

The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to 
zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if 
needed.) 

First glance, it looks OK, great even (absolutely as expected from Paul). 

I don't have capacity to properly sit down with it before the feature 
freeze (due Thursday) though. 
So if it were just me, I'd have to say it's too hot, too close to the 
deadline, and we should just target 4.0

However, maybe others, and the Technical Board who have the authority to 
specify, think that this is something we should take the extra time if 
needed and make sure we get in for 3.2? 
(Any extra eyes reviewing would help in that case.) 

As per Aymeric's point on the previous discussion, it's likely this doesn't 
affect most of our users. 
Paul's concern is that Django incompatibility (along with Pandas he 
mentioned in discussion) is blocking adoption throughout the community. 
That's not necessarily our problem, but maybe this is a small enough change 
that we should be flexible here? 
With 3.2 being the next LTS, it'll be around for a while (which is relevant 
I think). 

Can I ask for opinions please? Again, the option is to say that we'll 
squeeze this in if review is fine. 
The feature freeze isn't cast in stone, but we do have to draw the line 
somewhere.
This one is sufficiently interesting that Mariusz and I don't want to just 
decide with consultation. 

Thanks. 

Kind Regards,

Carlton




On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote:

> Hi all,
>
> Happy New Year! 
>
> Time to begin release process for the next major release, Django 3.2!
>
> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>
> The 3.2 feature freeze is scheduled for January 14. 
> We'll probably release the alpha that day.
>
> We have a few larger patches we want to finish reviewing:
>
> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added 
> support for functional indexes.
> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support 
> rotation of secret keys.
> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted 
> admin colors into CSS variables.
> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed #29138 
> -- Added limit_choices_to and to_field support to autocomplete fields.
>
> We'll update this thread for any schedule changes. 
>
> 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/cc28eb1d-3f24-4103-8a57-6835e775b11an%40googlegroups.com.

Re: Humanize duration fields

[Yasiel Cabrera]

I haven't any implementation yet. I'm going to do an implementation trying 
to reuse the naturaltime translations and I'm going back here with it

El martes, 12 de enero de 2021 a la(s) 06:05:57 UTC-5, Adam Johnson 
escribió:

> This seems like a sensible addition, and could possibly reuse the 
> translated strings from within naturaltime. Have you got an example 
> implementation?
>
> On Mon, 11 Jan 2021 at 22:52, Yasiel Cabrera  wrote:
>
>> Hey guys,
>>
>> I'm starting this thread to consult if make sense add a new filter 
>> (naturalduration) in django.contrib.humanize to humanize duration fields. 
>> Duration fields are native in django since 1.8 version I believe but there 
>> is not native way to humanize them as I see.
>>
>> If you approve the proposal, I can create the filter & docs.
>>
>> Cheers,
>> Yasiel Cabrera 
>>
>> -- 
>> 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/ec808bc6-b101-4fd5-8118-086532d72f57n%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/32d142d6-c482-444e-995e-48e5fad76d17n%40googlegroups.com.

Re: Adding Origin header checking to CSRF middleware (#16010)

[Tim Graham]

OWASP Cheat Sheet says, "It is important to note that [the SameSite 
Cookie] attribute should be implemented as an additional layer *defense in 
depth* concept. This attribute protects the user through the browsers 
supporting it, and it contains as well 2 ways to bypass it as mentioned in 
the following section 
. 
This attribute should not replace having a CSRF Token. Instead, it should 
co-exist with that token in order to protect the user in a more robust way."
On Tuesday, January 12, 2021 at 5:44:56 AM UTC-5 jacob...@gmail.com wrote:

> Shouldn't we consider to put the CSRF token onto the deprecation list 
> anyway?
> All browsers released later than 2017 support the 'SameSite' cookie 
> attribute , making the CSRF token 
> obsolete.
> I don't know what kind of policy the Django Project follows in deprecating 
> browsers, but we can expect 
> that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when 
> Django-4 (or maybe 5?) will be released.
>
> Strictly speaking, the CSRF token is a hack/workaround which in an ideal 
> world shouldn't be required anyway.
> And it always has been painful having to fiddle with it in my Django Form 
> Views.
>
> Just my two cents,
> Jacob 
>

-- 
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/915ff447-502e-45c2-8d18-bf5bee848c52n%40googlegroups.com.

Re: Humanize duration fields

[Adam Johnson]

This seems like a sensible addition, and could possibly reuse the
translated strings from within naturaltime. Have you got an example
implementation?

On Mon, 11 Jan 2021 at 22:52, Yasiel Cabrera  wrote:

> Hey guys,
>
> I'm starting this thread to consult if make sense add a new filter
> (naturalduration) in django.contrib.humanize to humanize duration fields.
> Duration fields are native in django since 1.8 version I believe but there
> is not native way to humanize them as I see.
>
> If you approve the proposal, I can create the filter & docs.
>
> Cheers,
> Yasiel Cabrera
>
> --
> 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/ec808bc6-b101-4fd5-8118-086532d72f57n%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/CAMyDDM1ZkonbuYtuXnD6pcO4hL_QdgEqNPtFkE4K1_otzb7eYA%40mail.gmail.com.

Re: Adding Origin header checking to CSRF middleware (#16010)

[Jacob Rief]

Shouldn't we consider to put the CSRF token onto the deprecation list 
anyway?
All browsers released later than 2017 support the 'SameSite' cookie 
attribute , making the CSRF token 
obsolete.
I don't know what kind of policy the Django Project follows in deprecating 
browsers, but we can expect 
that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when 
Django-4 (or maybe 5?) will be released.

Strictly speaking, the CSRF token is a hack/workaround which in an ideal 
world shouldn't be required anyway.
And it always has been painful having to fiddle with it in my Django Form 
Views.

Just my two cents,
Jacob 

-- 
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/311bb8a8-5d84-4111-91ee-619ae8e8782an%40googlegroups.com.