Django security releases issued: 3.2.2, 3.1.10, and 2.2.22

2021-05-06 Thread Mariusz Felisiak

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2021/may/06/security-releases/

--
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/1d51daf2-5cb1-fcee-a721-977dd5e66ed6%40gmail.com.


Re: Fellow Reports - April 2021

2021-05-06 Thread Mariusz Felisiak
Week ending May 2, 2021

*Triaged: *
   https://code.djangoproject.com/ticket/32682 - Deleting objects after 
searching related many to many field crashes the admin page (accepted) 
   https://code.djangoproject.com/ticket/32685 - Add feature to preserve 
order in .filter(field__in=list) query (wontfix) 
   https://code.djangoproject.com/ticket/32680 - Add an option to display 
inlines as a table without forms. (wontfix) 
   https://code.djangoproject.com/ticket/32688 - The ON CONFLICT sql suffix 
creates a syntax error on m2m inserts (invalid) 
   https://code.djangoproject.com/ticket/29168 - Document how to write a 
custom lookup where the rhs comes before the lhs (invalid) 
   https://code.djangoproject.com/ticket/32690 - Q object __or__ appears to 
get all dunder related's default columns and queryset raises 
ProgrammingError. (accepted) 
   https://code.djangoproject.com/ticket/26368 - Order of &-ing Q objects 
affects results in edge case (duplicate) 
   https://code.djangoproject.com/ticket/32691 - Django 3.2 boolean field 
SQL output is causing a performance regression in MySQL. (invalid) 
   https://code.djangoproject.com/ticket/32692 - Django 3.2 automatic 
AppConfig discovery breaks projects working in 3.1.8 (invalid) 
   https://code.djangoproject.com/ticket/32689 - Infinite AlterField 
Migrations due to default callable object missmatch (invalid) 
   https://code.djangoproject.com/ticket/32696 - Display Changed Value in 
History Form Django Admin (invalid) 
   https://code.djangoproject.com/ticket/32697 - Older versions of Django 
insist on converting BigAutoField back to AutoField (invalid) 
   https://code.djangoproject.com/ticket/32698 - Move 
HttpRequest.get_raw_uri() to ExceptionReporter._get_raw_insecure_uri(). 
(accepted) 
   https://code.djangoproject.com/ticket/32695 - Create Permissions with 
create() instead of bulk_create() to send signal (wontfix) 
   https://code.djangoproject.com/ticket/23572 - Exception on Custom 
Lookups when right value is None. (fixed) 

*Reviewed/committed: *
   https://github.com/django/django/pull/14308 - Fixed #32681 -- Fixed 
VariableDoesNotExist when rendering some admin template. 
   https://github.com/django/django/pull/14314 - Fixed #32686 -- Removed 
unnecessary semicolon on collected multiline SQL for RunSQL. 
   https://github.com/django/django/pull/14315 - Fixed #32687 -- Restored 
passing process’ environment to underlying tool in dbshell on PostgreSQL. 
   https://github.com/django/django/pull/14309 - Fixed #32632, Fixed #32657 
-- Removed flawed support for Subquery deconstruction. 
   https://github.com/django/django/pull/14320 - Cleaned up handling of 
alias reuse with filtered relations. 
   https://github.com/django/django/pull/14323 - Fixed #32675 -- Doc'd that 
autodector changes might cause generation of no-op migrations. 
   https://github.com/django/django/pull/14330 - Fixed capitalization of 
"ECMAScript" and "JavaScript". 
   https://github.com/django/django/pull/14317 - Refs #32178 -- Doc'd 
DatabaseFeatures.django_test_skips/django_test_expected_failures in 
contributing guide. 
   https://github.com/django/django/pull/14331 - Fixed #32698 -- Moved 
HttpRequest.get_raw_uri() to ExceptionReporter._get_raw_insecure_uri(). 
   https://github.com/django/django/pull/14306 - Fixed #32678 -- Removed 
SECURE_BROWSER_XSS_FILTER setting. 

*Reviewed: *
   https://github.com/django/django/pull/14328 - Refs #32674 -- Noted that 
auto-created through table PKs cannot be automatically migrated. 

*Authored: *
   https://github.com/django/django/pull/14312 - Refs 32637 -- Made 
technical 404 debug page display exception message when URL is resolved. 
   https://github.com/django/django/pull/14313 - Fixed #32682 -- Made admin 
changelist use Exists() instead of distinct() for preventing duplicates. 
   https://github.com/django/django/pull/14329 - Refs #32682 -- Renamed 
lookup_needs_distinct() to lookup_spawns_duplicates(). 
   https://github.com/django/django/pull/14335 - Fixed #32653 -- Made 
quoting names in the Oracle backend consistent with db_table.

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/cea9389c-e2cd-4133-8fe7-bf5e95cae164n%40googlegroups.com.


Re: On adding comments to database schema

2021-05-06 Thread Jared Chung
KimSoungRyoul would you like help with writing the docs and tests for this? 
I'd like to contribute to Django in some way and this is a feature my 
company would greatly value (we have Data Scientists and DBAs interacting 
with db tables managed by Django, so having comment documentation at the DB 
level would have a huge positive impact). It looks like you received 
feedback on your PR  and 
Mariusz pointed out that docs and tests are needed. I'd be happy to help 
out with the docs and tests if I can. You're marked as ticket owner right 
now on ticket 18468 . Please 
let me know!
*(Disclosure: I'm new to contributing to Django, and hopeful that this can 
be a good ticket for me to start with. I've been using Django now for a 
decade and am excited to start giving back!)*

On Saturday, May 2, 2020 at 10:24:46 PM UTC-7 kimsou...@gmail.com wrote:

> I'm sorry if I sounded like I was pushing you. 
>
> even missing checklist
>
>
> 2020년 5월 3일 일요일 오전 1시 42분 2초 UTC+9, Mariusz Felisiak 님의 말:
>
>> Asking for a review on multiple channels doesn't help. You need to be 
>> patient, we have many PRs in review queue. Please check "Patch review 
>> checklist" [1]. At first glance, docs are missing.
>>
>> [1] 
>> https://docs.djangoproject.com/en/3.0/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>>
>

-- 
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/62705a74-f16d-42c3-b440-4e3e7628351cn%40googlegroups.com.


Re: On adding comments to database schema

2021-05-06 Thread Jared Chung
KimSoungRyoul it looks like there is feedback on the PR you created (PR 
#12605 ) and Marius also 
pointed out that docs and tests are missing. Would you like help with the 
docs and tests? We've recently added some data scientists and dbas to our 
team and I immediately saw the significant value in ticket 28822 
. You're marked as the ticket 
owner right now, but I'd love to help out with docs and tests if you feel 
that the rest of the implementation is solid (or if you are willing to 
update your PR based on the feedback from Mads Jensen (atombrella).
*(Full disclosure: I'm new to contributing to django, but hoping that this 
can be my first contribution. I've been thankful to use Django at work for 
9 years now!)* 


On Saturday, May 2, 2020 at 10:24:46 PM UTC-7 kimsou...@gmail.com wrote:

> I'm sorry if I sounded like I was pushing you. 
>
> even missing checklist
>
>
> 2020년 5월 3일 일요일 오전 1시 42분 2초 UTC+9, Mariusz Felisiak 님의 말:
>
>> Asking for a review on multiple channels doesn't help. You need to be 
>> patient, we have many PRs in review queue. Please check "Patch review 
>> checklist" [1]. At first glance, docs are missing.
>>
>> [1] 
>> https://docs.djangoproject.com/en/3.0/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>>
>

-- 
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/0f963398-7733-4cd6-9b5f-600945030b36n%40googlegroups.com.


Re: On adding comments to database schema

2021-05-06 Thread Tom Carrick
It's funny that you bring this up, I was actually looking at this today and
thinking about picking it up next week.

Jared, the PR was closed without any comment from the author and is
seemingly abandoned. I think it's safe for you to assign the ticket to
yourself and continue the work in a new PR at this point - that was going
to be my plan, anyway.

Tom

On Thu, 6 May 2021 at 15:16, Jared Chung  wrote:

> KimSoungRyoul would you like help with writing the docs and tests for
> this? I'd like to contribute to Django in some way and this is a feature my
> company would greatly value (we have Data Scientists and DBAs interacting
> with db tables managed by Django, so having comment documentation at the DB
> level would have a huge positive impact). It looks like you received
> feedback on your PR  and
> Mariusz pointed out that docs and tests are needed. I'd be happy to help
> out with the docs and tests if I can. You're marked as ticket owner right
> now on ticket 18468 . Please
> let me know!
> *(Disclosure: I'm new to contributing to Django, and hopeful that this can
> be a good ticket for me to start with. I've been using Django now for a
> decade and am excited to start giving back!)*
>
> On Saturday, May 2, 2020 at 10:24:46 PM UTC-7 kimsou...@gmail.com wrote:
>
>> I'm sorry if I sounded like I was pushing you.
>>
>> even missing checklist
>>
>>
>> 2020년 5월 3일 일요일 오전 1시 42분 2초 UTC+9, Mariusz Felisiak 님의 말:
>>
>>> Asking for a review on multiple channels doesn't help. You need to be
>>> patient, we have many PRs in review queue. Please check "Patch review
>>> checklist" [1]. At first glance, docs are missing.
>>>
>>> [1]
>>> https://docs.djangoproject.com/en/3.0/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>>>
>> --
> 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/62705a74-f16d-42c3-b440-4e3e7628351cn%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/CAHoz%3DMbaEAaV1nt9dL576RvLzDSL_LacJ-fRLAe4Bwo416HDfA%40mail.gmail.com.


Re: APPEND_SLASH behavior

2021-05-06 Thread Florian Apolloner
Hi,

I took a quick glance (literally just that) at the pull requests. I do like 
the one that offers a way to abort early inside a prefix -- this is a nice 
optimization and as well might open interesting options for specialized 
catch all views. I am not convinced about the backtracking PR, which 
problems does this solve in reality? What does this mean for features like 
atomic requests -- it is still just one request after all… 

Cheers,
Florian

On Wednesday, May 5, 2021 at 7:21:01 PM UTC+2 atd...@gmail.com wrote:

> Ok I see better.
> Talking about efficiency, I take this opportunity to link here the 
> following draft PR I made: Backtracking URL Resolver 
>  and Provide ability to 
> abort URL resolution early , 
> which, if implemented in the right way, may help make URL resolving more 
> efficient and more flexible too.
>
> I understand that you may not have time to review  or maybe this is not 
> something you are planning to put into Django right now, but I would be 
> very happy to have any feedback on it!
>
> Le mercredi 5 mai 2021 à 17:19:43 UTC+2, f.apo...@gmail.com a écrit :
>
>> On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote:
>>
>>> In both cases however, the current check being done in the 
>>> process_response method for the CommonMiddleware(here 
>>> )
>>>  
>>> seems irrelevant to me unless I am missing *something*. 
>>>
>>
>> You are most likely not missing anything and we also noticed that when 
>> fixing the admin enumeration stuff. But we did not get around to fixing it 
>> yet. That said, I think doing this in process_response would be preferable 
>> over doing it in process_request so the extra checks when the URL is valid 
>> (the common case) are reduced. Resolving URLs can take a bit, especially 
>> when the urlconf is long and as such I'd like to get that check out of the 
>> "hot" code path. Only doing the redirect in the case of a failing resolve 
>> in the first place would probably make this more efficient.
>>
>> Cheers,
>> Florian
>>
>

-- 
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/4550509b-e628-47f9-b635-b4d6b74414e5n%40googlegroups.com.


Re: APPEND_SLASH behavior

2021-05-06 Thread Tidiane Dia
Hi, thanks for giving it a look. 

The PR are based on existing tickets so these are not my ideas. The relevant 
ticket  for the backtracking 
URL contains valuable information about its benefits and why the author 
requested the feature. The idea is to  "provide a way to pass control back 
to the URL router to try the remaining routes" if a certain route matched 
at first but doesn't want to handle this request and want to pass the 
control to another view -- see this comment 
 for 
an example of issue it would solve in reality --



Le jeudi 6 mai 2021 à 19:32:59 UTC+2, f.apo...@gmail.com a écrit :

> Hi,
>
> I took a quick glance (literally just that) at the pull requests. I do 
> like the one that offers a way to abort early inside a prefix -- this is a 
> nice optimization and as well might open interesting options for 
> specialized catch all views. I am not convinced about the backtracking PR, 
> which problems does this solve in reality? What does this mean for features 
> like atomic requests -- it is still just one request after all… 
>
> Cheers,
> Florian
>
> On Wednesday, May 5, 2021 at 7:21:01 PM UTC+2 atd...@gmail.com wrote:
>
>> Ok I see better.
>> Talking about efficiency, I take this opportunity to link here the 
>> following draft PR I made: Backtracking URL Resolver 
>>  and Provide ability to 
>> abort URL resolution early , 
>> which, if implemented in the right way, may help make URL resolving more 
>> efficient and more flexible too.
>>
>> I understand that you may not have time to review  or maybe this is not 
>> something you are planning to put into Django right now, but I would be 
>> very happy to have any feedback on it!
>>
>> Le mercredi 5 mai 2021 à 17:19:43 UTC+2, f.apo...@gmail.com a écrit :
>>
>>> On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote:
>>>
 In both cases however, the current check being done in the 
 process_response method for the CommonMiddleware(here 
 )
  
 seems irrelevant to me unless I am missing *something*. 

>>>
>>> You are most likely not missing anything and we also noticed that when 
>>> fixing the admin enumeration stuff. But we did not get around to fixing it 
>>> yet. That said, I think doing this in process_response would be preferable 
>>> over doing it in process_request so the extra checks when the URL is valid 
>>> (the common case) are reduced. Resolving URLs can take a bit, especially 
>>> when the urlconf is long and as such I'd like to get that check out of the 
>>> "hot" code path. Only doing the redirect in the case of a failing resolve 
>>> in the first place would probably make this more efficient.
>>>
>>> Cheers,
>>> Florian
>>>
>>

-- 
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/41821059-b9a5-433b-b08d-78e3d99d84dcn%40googlegroups.com.


Re: APPEND_SLASH behavior

2021-05-06 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)
>
> That said, I think doing this in process_response would be preferable over
> doing it in process_request so the extra checks when the URL is valid (the
> common case) are reduced. Resolving URLs can take a bit, especially when
> the urlconf is long and as such I'd like to get that check out of the "hot"
> code path. Only doing the redirect in the case of a failing resolve in the
> first place would probably make this more efficient.


I agree. I guess it might need a deprecation cycle to move it to
process_response though?

On Thu, 6 May 2021 at 19:21, Tidiane Dia  wrote:

> Hi, thanks for giving it a look.
>
> The PR are based on existing tickets so these are not my ideas. The relevant
> ticket  for the backtracking
> URL contains valuable information about its benefits and why the author
> requested the feature. The idea is to  "provide a way to pass control back
> to the URL router to try the remaining routes" if a certain route matched
> at first but doesn't want to handle this request and want to pass the
> control to another view -- see this comment
> 
> for an example of issue it would solve in reality --
>
>
>
> Le jeudi 6 mai 2021 à 19:32:59 UTC+2, f.apo...@gmail.com a écrit :
>
>> Hi,
>>
>> I took a quick glance (literally just that) at the pull requests. I do
>> like the one that offers a way to abort early inside a prefix -- this is a
>> nice optimization and as well might open interesting options for
>> specialized catch all views. I am not convinced about the backtracking PR,
>> which problems does this solve in reality? What does this mean for features
>> like atomic requests -- it is still just one request after all…
>>
>> Cheers,
>> Florian
>>
>> On Wednesday, May 5, 2021 at 7:21:01 PM UTC+2 atd...@gmail.com wrote:
>>
>>> Ok I see better.
>>> Talking about efficiency, I take this opportunity to link here the
>>> following draft PR I made: Backtracking URL Resolver
>>>  and Provide ability to
>>> abort URL resolution early ,
>>> which, if implemented in the right way, may help make URL resolving more
>>> efficient and more flexible too.
>>>
>>> I understand that you may not have time to review  or maybe this is not
>>> something you are planning to put into Django right now, but I would be
>>> very happy to have any feedback on it!
>>>
>>> Le mercredi 5 mai 2021 à 17:19:43 UTC+2, f.apo...@gmail.com a écrit :
>>>
 On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote:

> In both cases however, the current check being done in the
> process_response method for the CommonMiddleware(here
> )
> seems irrelevant to me unless I am missing *something*.
>

 You are most likely not missing anything and we also noticed that when
 fixing the admin enumeration stuff. But we did not get around to fixing it
 yet. That said, I think doing this in process_response would be preferable
 over doing it in process_request so the extra checks when the URL is valid
 (the common case) are reduced. Resolving URLs can take a bit, especially
 when the urlconf is long and as such I'd like to get that check out of the
 "hot" code path. Only doing the redirect in the case of a failing resolve
 in the first place would probably make this more efficient.

 Cheers,
 Florian

>>> --
> 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/41821059-b9a5-433b-b08d-78e3d99d84dcn%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/CAMyDDM0JaMmkBp00TfaK59Brk1WFS8tHdgyt55i3pDtJhY5j2w%40mail.gmail.com.