Re: Fellow Reports - August 2018
Week ending August 18, 2018 Triaged --- https://code.djangoproject.com/ticket/29676 - has_add_permission() returning False in TabularInline form raises exception in contrib.admin (duplicate) https://code.djangoproject.com/ticket/29678 - inspectdb fails on MySQL 8 with " 'utf8' is currently an alias for the character set UTF8MB3" (invalid) https://code.djangoproject.com/ticket/29681 - Support XHTML5 (XML serialization of HTML5) (wontfix) https://code.djangoproject.com/ticket/29682 - Admin change form crashes if a view-only model's form has field not on the model (accepted) https://code.djangoproject.com/ticket/29679 - select_related() crashes with "ORA-00918: column ambiguously defined" on Oracle (needsinfo) https://code.djangoproject.com/ticket/29673 - Thread urlconf isn't reset after response complete (needsinfo) Authored -- https://github.com/django/django/pull/10311 - Refs #29426 -- Made UUIDField render values with dashes. https://github.com/django/django/pull/10317 - Fixed #29682 -- Fixed admin change form crash if a view-only model's form has an extra field. Reviewed/committed -- https://github.com/django/django/pull/10288 - Fixed #29662 -- Allowed test client to accept structured suffix JSON content types. https://github.com/django/django/pull/10276 - Fixed #29644 -- Made SearchQuery.__str__() reflect negation and grouping. https://github.com/django/django/pull/10286 - Fixed #29646 -- Doc'd the validators that each model and form field uses. https://github.com/django/django/pull/10291 - Fixed #29663 -- Made admin change view redirect to changelist with view permission. https://github.com/django/django/pull/10309 - Refs #29015 -- Added database name to PostgreSQL database name too long exception. https://github.com/django/django/pull/10277 - Fixed #29612 -- Added GenericRelation prefetch_related() cache invalidation. https://github.com/django/django/pull/10257 - Fixed #29626, #29584 -- Added optimized versions of get_many() and delete_many() for the db cache backend. https://github.com/django/django/pull/10253 - Fixed #29686 -- Made UserAdmin.user_change_password() pass user to has_change_permission(). https://github.com/django/django/pull/10310 - Fixed #29685 -- Added QuerySet.explain() to the database optimization docs. https://github.com/django/django/pull/9972 - Fixed #29426 -- Made UUID inputs in the admin match the width of a UUID. https://github.com/django/django/pull/9162 - Fixed #28649 -- Added ExtractIsoYear database function and iso_year lookup. -- 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/4d27dee8-a1cb-4081-afc2-6b1167c3fc9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add a setting for customizing the CSRF token name?
On Sat, 18 Aug 2018 21:27:02 +0200 Adam Johnson wrote: > I'm not sure introducing this change because one analyzer tool > currently picks up on the signal is a great reason, only a little bit > of potential obscurity is gained. Especially since it's a problem for > big sites deploying it, as Aymeric points out we'd need to write a > shim. > +1. On Sat, 18 Aug 2018 at 18:31, Aymeric Augustin wrote: > Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the > hardcoded "csrfmiddlewaretoken"? That would meet the stated goal > without introducing a new setting. Also it feels sensible to me to > use the same name for the input and the cookie. This sort of reuse feels wrong to me -- if we do allow changing the name, I'd be -0.5 on reusing the setting and tying these two names to eachother. -- 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/20180818231621.2a75327b.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
Re: Add a setting for customizing the CSRF token name?
I've thought about this a bit, especially back in the context of tracking
how many sites use Django. Besides the CSRF token input name there are
probably tens to hundreds of little signals that a site runs Django, e.g.
the presence of /admin/, CSRF/session cookie presence/size, APPEND_SLASH,
default 400/403/404/500 handler responses, default form widget validation
errors, or even the presence of *any* hidden input in a form with a random
string that looks like a django CSRF token (i.e. if the name is changed
it's probably still detectable). Not to mention popular third party
packages, e.g. Sentry inserts a predictable HTML tag.
I'm not sure introducing this change because one analyzer tool currently
picks up on the signal is a great reason, only a little bit of potential
obscurity is gained. Especially since it's a problem for big sites
deploying it, as Aymeric points out we'd need to write a shim.
On Sat, 18 Aug 2018 at 18:31, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the
> hardcoded "csrfmiddlewaretoken"? That would meet the stated goal without
> introducing a new setting. Also it feels sensible to me to use the same
> name for the input and the cookie.
>
> There would be some hiccups — 403 errors on legitimate requests — when
> upgrading a website to a new version of Django that includes this change.
> To avoid that, we could implement a backwards-compatibility shim that we
> would keep for one major version.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 18 Aug 2018, at 16:40, Tim Graham wrote:
>
> Do you think it's worth a new setting to allow customizing the CSRF token
> name ('csrfmiddlewaretoken')?
>
> It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
> and closed as wontfix absent some justification.
>
> It was again proposed a few days ago in
> https://github.com/django/django/pull/10305 with the rationale:
>
> Wappalyzer identifies Django application with "csrfmiddlewaretoken" input
> name.
> https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471
>
> I guess the idea is trying to obscure the fact that a site runs Django for
> some "security by obscurity."
>
> --
> 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/01b25887-823e-4008-9ad4-51f80e7c2590%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/5796AA81-96EC-418E-A174-D11FAC28704A%40polytechnique.org
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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 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/CAMyDDM1uwf1WQx2gjNWuZ%2BjBcMGMVFFAtzsM6TN%3DBh6fVSp6SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Add a setting for customizing the CSRF token name?
Hello,
I'd be in favor of what's proposed.
Slightly related, this made me remember I had some note about proposing we
add either to the Security or the Deployment checklist documents
suggestions about (also) customizing the CSRF_COOKIE_NAME,
LANGUAGE_COOKIE_NAME and SESSION_COOKIE_NAME settings. to make identifying
Django is being used harder.
(This is related to what Aymeric mentions) It's easier this kind of
customization is performed before the initial deployment to avoid the
hassle caused by trying to change them once a site is in production, that's
why I think it's a good idea to make developers/deployers aware they have
these choices at that point.
Regards,
On Sat, Aug 18, 2018 at 11:40 AM Tim Graham wrote:
> Do you think it's worth a new setting to allow customizing the CSRF token
> name ('csrfmiddlewaretoken')?
>
> It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
> and closed as wontfix absent some justification.
>
> It was again proposed a few days ago in
> https://github.com/django/django/pull/10305 with the rationale:
>
> Wappalyzer identifies Django application with "csrfmiddlewaretoken" input
> name.
> https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471
>
> I guess the idea is trying to obscure the fact that a site runs Django for
> some "security by obscurity."
>
> --
> 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/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF8QoVd5CE5q91%3D%2BpnyGxO9-d8YLC5d3aiqSkHr%2BXCbUKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Add a setting for customizing the CSRF token name?
Hello,
Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the hardcoded
"csrfmiddlewaretoken"? That would meet the stated goal without introducing a
new setting. Also it feels sensible to me to use the same name for the input
and the cookie.
There would be some hiccups — 403 errors on legitimate requests — when
upgrading a website to a new version of Django that includes this change. To
avoid that, we could implement a backwards-compatibility shim that we would
keep for one major version.
Best regards,
--
Aymeric.
> On 18 Aug 2018, at 16:40, Tim Graham wrote:
>
> Do you think it's worth a new setting to allow customizing the CSRF token
> name ('csrfmiddlewaretoken')?
>
> It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
> and closed as wontfix absent some justification.
>
> It was again proposed a few days ago in
> https://github.com/django/django/pull/10305 with the rationale:
>
> Wappalyzer identifies Django application with "csrfmiddlewaretoken" input
> name.
> https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471
>
>
> I guess the idea is trying to obscure the fact that a site runs Django for
> some "security by obscurity."
>
> --
> 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/01b25887-823e-4008-9ad4-51f80e7c2590%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/5796AA81-96EC-418E-A174-D11FAC28704A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Add a setting for customizing the CSRF token name?
Do you think it's worth a new setting to allow customizing the CSRF token
name ('csrfmiddlewaretoken')?
It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
and closed as wontfix absent some justification.
It was again proposed a few days ago in
https://github.com/django/django/pull/10305 with the rationale:
Wappalyzer identifies Django application with "csrfmiddlewaretoken" input
name.
https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471
I guess the idea is trying to obscure the fact that a site runs Django for
some "security by obscurity."
--
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/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
