Re: Fellow Reports - August 2018

[Tim Graham]

Week ending August 25, 2018

Triaged

---

https://code.djangoproject.com/ticket/29697 - Complex query crashes with 
"missing FROM-clause entry for table" (accepted)

https://code.djangoproject.com/ticket/29701 - has_add_permission  in 
admin.TabularInline gives KeyError exception (duplicate)

https://code.djangoproject.com/ticket/29699 - Remove redirect loop warning 
re. using redirect_authenticated_user with permissions checking (invalid)

https://code.djangoproject.com/ticket/29708 - Deprecate PickleSerializer 
and move it out of core (someday/maybe)

https://code.djangoproject.com/ticket/29709 - Recommend django-pyodbc-azure 
instead of django-mssql as Microsoft SQL Server backend (fixed)

Authored

--

https://github.com/pennersr/django-allauth/pull/2093 - Add testing for 
Django 2.1

https://github.com/kennethreitz/dj-database-url/pull/109 - Add testing for 
Django 2.1

Reviewed/committed

--

https://github.com/django/django/pull/10285 - Fixed #29690 -- Fixed aligned 
 positioning for RTL languages in admin.

https://github.com/django/django/pull/10293 - Fixed #29625 -- Made 
Model.refresh_from_db() clear prefetch related caches.

https://github.com/django/django/pull/10316 - Fixed #29236 -- Fixed 
diffsettings crash if using settings.configure().

https://github.com/django/django/pull/10321 - Fixed #29689 -- Improved 
performance of FileSystemStorage.listdir() and FilePathField with 
os.scandir().

https://github.com/django/django/pull/9868 - Fixed #29695 -- Added system 
checks for admin's app dependencies and TEMPLATES setting.

https://github.com/django/django/pull/10323 - Fixed #29696 -- Prevented 
BaseModelFormSet.initial_form_count()'s from treating data={} as unbound.

https://github.com/django/django/pull/10324 - Fixed #29654 -- Made text 
truncation an ellipsis character instead of three dots.

https://github.com/django/django/pull/10312 - Fixed #29658 -- Registered 
model lookups in tests with a context manager.

https://github.com/django/django/pull/10326 - Fixed #29698 -- Fixed 
Field._check_choices() crash on invalid choices.

https://github.com/django/django/pull/10199 - Fixed #26352 -- Made system 
check allow ManyToManyField to target the same model if through_fields 
differs.

https://github.com/django/django/pull/10201 - Fixed #29570 -- Added check 
that MEDIA_URL isn't in STATIC_URL.

https://github.com/django/django/pull/10331 - Fixed #29705 -- Fixed 
ImageField RuntimeError crash for WebP files.

https://github.com/django/django/pull/10307 - Fixed #29704 -- Fixed 
manage.py test --testrunnner if it isn't followed by an equals sign.

https://github.com/django/django/pull/9673 - Fixed #29048 -- Added 
**extra_context arg to as_vendor() methods in database functions.

https://github.com/django/django/pull/9843 - Fixed #29226 -- Doc'd 
modify_settings() ordering considerations for Python < 3.6.
https://github.com/django/django/pull/10313 - Fixed #29687 -- Allowed the 
test client to serialize list/tuple as JSON.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/805310c9-6a74-4c3b-a2b7-ca4a9436cfd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate PickleSerializer for session serialization?

[Shai Berger]

On Sat, 25 Aug 2018 11:56:02 -0400
Michael Manfre  wrote:

> Anyone who uses it after reading the warning would likely still use
> it if it were in another package. A separate package is another "Are
> you sure?" step that they would likely ignore.

I disagree -- a separate package means that the idea of pickling the
session object into a cookie is removed from the Django documentation,
making people much less likely to stumble upon it and much more likely
to use safer serializations in relevant use-cases. It's not just an
"Are you sure?" -- they'd have to actively look for it.

+1 for footgun removal,

Shai.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20180826000928.010da0fb.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Feedback wanted for API to support for multi file upload

[Johannes Hoppe]

Hi there!

I do need some feedback on the best public API to implement multi file 
support to Django forms.

Context:

Up until now Django forms do not support multi file upload. You will need 
to write your own view to handle the files as described here:
https://docs.djangoproject.com/en/2.1/topics/http/file-uploads/#uploading-multiple-files

Of course it is not too hard to implement actual multi file support as I 
have been showcasing here:
https://github.com/django/django/pull/9011/files

The question is now to best add support for multiple file uploads without 
wrecking backwards compatibility?

As Tim wisely mentioned, it might be confusing to add a `multiple` argument 
to the FileField while also having the 
attrs={'multiple': True}
still in the mix.

My suggestion would be to add the new keyword argument which enable the new 
behavior and keep the attr-thing as is.
I could add a warning if someone uses the "old" style. It is a bit 
suggestive though.

What do you think, mabe look at the documentation changes in the PR for 
more context.

Best
-Joe

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e71675d3-be96-4189-b0c1-038774626284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add autocomplete attribute to contrib.auth fields?

[Tom Forbes]

I don’t have much to add other than it’s pretty common for pentests to flag
autocomplete being enabled on sensitive fields (email/password) and
recommend disabling it (autocomplete=off). While I’m not sure if I agree
with that recommendation in some situations you have little choice but to
follow it.




On 25 August 2018 at 16:54:08, Tim Graham (timogra...@gmail.com) wrote:

Browser support looks somewhat limited, so I wanted to ask if there are any
concerns or drawbacks with adding
autocomplete=username/email/current-password/new-password to contrib.auth's
forms?


Pull request: ​https://github.com/django/django/pull/9921


>From the ticket [https://code.djangoproject.com/ticket/29379]:


The most useful one is autocomplete=new-password, which prevents browsers
prefill with current password, Chrome will also suggest a random strong
password for users who turned on account sync.
Related docs:
​
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
​
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
​
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/d398c554-3fe2-4e0f-9deb-a61dabc4cbf3%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJMektU_6pQ6vXnRrBHEisGbUzp8sm-cE2m0-597dShHGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate PickleSerializer for session serialization?

[Michael Manfre]

I have no strong opinion about keeping it verse moving it. The docs already
provide a sufficient warning about the risks of using it. Anyone who uses
it after reading the warning would likely still use it if it were in
another package. A separate package is another "Are you sure?" step that
they would likely ignore.

Regards,
Michael Manfre

On Sat, Aug 25, 2018 at 9:12 AM Tim Graham  wrote:

> Alex proposed:
>
> ---
>
> Pickle serializer has long been known to be dangerous. This is mitigated
> by requiring MAC on pickle in cookies, but nevertheless, RCEs continue to
> happen: ​
> https://blog.scrt.ch/2018/08/24/remote-code-execution-on-a-facebook-server/
>
>
> To further discourage it's use, we should consider deprecating
> PickleSerializer and moving it into a third party package.
>
> https://code.djangoproject.com/ticket/29708
> ---
>
> I don't see much advantage to a separate package for 10 lines of code:
>
> import pickle
>
> class PickleSerializer:
> """
> Simple wrapper around pickle to be used in signing.dumps and
> signing.loads.
> """
> protocol = pickle.HIGHEST_PROTOCOL
>
> def dumps(self, obj):
> return pickle.dumps(obj, self.protocol)
>
> def loads(self, data):
> return pickle.loads(data)
>
> I'm not sure that removing it from Django would improve security (since
> Django 1.6, JSONSerializer is the default session serializer). Thoughts?
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/37fe5ab5-6d30-45bd-8bdd-a11f0170209c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvCPMa0nuwdJcwSNtjBRhfHgoF%2Bx-j2t4m7r2nRZi6fGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Add autocomplete attribute to contrib.auth fields?

[Tim Graham]

Browser support looks somewhat limited, so I wanted to ask if there are any 
concerns or drawbacks with adding 
autocomplete=username/email/current-password/new-password to contrib.auth's 
forms?


Pull request: ​https://github.com/django/django/pull/9921


>From the ticket [https://code.djangoproject.com/ticket/29379]:


The most useful one is autocomplete=new-password, which prevents browsers 
prefill with current password, Chrome will also suggest a random strong 
password for users who turned on account sync.
Related docs:
​
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
​
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
​
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d398c554-3fe2-4e0f-9deb-a61dabc4cbf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Deprecate PickleSerializer for session serialization?

[Tim Graham]

Alex proposed:

---

Pickle serializer has long been known to be dangerous. This is mitigated by 
requiring MAC on pickle in cookies, but nevertheless, RCEs continue to 
happen: ​
https://blog.scrt.ch/2018/08/24/remote-code-execution-on-a-facebook-server/


To further discourage it's use, we should consider deprecating 
PickleSerializer and moving it into a third party package.

https://code.djangoproject.com/ticket/29708
---

I don't see much advantage to a separate package for 10 lines of code:

import pickle

class PickleSerializer:
"""
Simple wrapper around pickle to be used in signing.dumps and
signing.loads.
"""
protocol = pickle.HIGHEST_PROTOCOL

def dumps(self, obj):
return pickle.dumps(obj, self.protocol)

def loads(self, data):
return pickle.loads(data)

I'm not sure that removing it from Django would improve security (since 
Django 1.6, JSONSerializer is the default session serializer). Thoughts?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37fe5ab5-6d30-45bd-8bdd-a11f0170209c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model default modelform

[Jamesie Pic]

Hi Claude,

Thanks for your feedback, it's a great idea to make modelform a callable
registry instance or something.

In some project we're going to try to acheive this kind of coupling and
work with Python components instead of templates for example:

status = CharField(components=dict(form=MyStatusField, table=MyStatusCell,
card=MyStatusCard))

But this happens would happen in a router class, not directly in the model:
then you could remove Field.formfield() method.

Have a great day

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-CzyJLNddpW2xq6LhGseeqQG0PzukzoQodCvJ8d2PYTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Aymeric Augustin]

Hello Nils,

> On 23 Aug 2018, at 19:33, Nils Fredrik Gjerull  wrote:
> 
> How can we move forward on supporting XML serialization of HTML5 (XHTML5)?
> 
> When I created the pull-request I did not think it would be very
> controversial. After all, the XML style of writing HTML has been used
> for years. I guess many are not aware that HTML5 comes in two flavors
> and it creates confusion.

You may have missed that Django made the opposite move over the last couple 
years. You don't appear to be aware of the corresponding discussions.

You should review these discussions, compile a list of the reasons why these 
changes were made, and brining counter-arguments if you want to reverse course.

Best regards,

-- 
Aymeric.


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F254D803-F27D-4556-9E64-697F830E1E8C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Model default modelform

[Claude Paroz]

Le vendredi 24 août 2018 11:35:43 UTC+2, Jamesie Pic a écrit :
>
> Thank for your feedback.
>
> It's the eternal misunderstanding of django's pattern, confusion between 
> table, and model, model is de factores what couples table and form, I've 
> posted articles about it already. I call this the elephant in the room but 
> if I'm the only one to see it it means it's my mistake. 
>

It is not (your mistake). I understand your proposal as an extension of the 
Field.formfield() API to the model level. I already wished that 
functionality in several of my projects, to define some sort of canonical 
form used for some model throughout Django. However, the current 
formfield() API showed some weaknesses (didn't search, but I know there 
were discussion on this list about this). So the whole tying between models 
and forms would benefit for a large-scale refactoring, probably following 
some registration pattern. If I had unlimited time, that's something I 
would have tried to tackle.

Sorry, that doesn't help much.

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/984332c6-a27a-4f7e-a7db-c16cf45a0740%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.