Anonymous access to the forum

[Claude Paroz]

Hello,

Am I the only one or did Google closed anonymous access to Google groups?
Could it be a setting in the group config?

In my opinion, it is not acceptable for the project if accessing the
Django group posts require authentication.

If someone has more information about that change, that would be great.

Claude
-- 
www.2xlibre.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/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks for bringing this up, Claude. I'll look into it.

Cheers,

Markus

On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote:
> Hello,
> 
> Am I the only one or did Google closed anonymous access to Google groups?
> Could it be a setting in the group config?
> 
> In my opinion, it is not acceptable for the project if accessing the
> Django group posts require authentication.
> 
> If someone has more information about that change, that would be great.
> 
> Claude
> -- 
> www.2xlibre.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/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.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/40cc7a4a-954f-4b46-8725-0f74aba6c701%40www.fastmail.com.

Re: Anonymous access to the forum

[Adam Johnson]

You're not the only one, I also get redirected to login when visiting the
group URL in a "private mode" window:
https://groups.google.com/group/django-developers

I did some research and found there's a "New Google Groups" update. I think
this has done it. Links:

   - Beta announcement post:
   https://gsuiteupdates.googleblog.com/2020/03/new-google-groups-beta.html
   - General release post:
   
https://gsuiteupdates.googleblog.com/2020/05/new-google-groups-generally-available.html
   - List of changes: https://support.google.com/a/answer/9687393 (I
   couldn't spot anything related to removing anonymous access)

I checked on another group I'm an admin for and in settings I found "Who
can see group" with options "Group members" and "Anyone on the web".
Perhaps Google didn't migrate this setting and we need to reset it to
"Anyone on the web"? Can one of the admins for django-users and
django-developers check?

On Tue, 18 Aug 2020 at 08:14, Claude Paroz  wrote:

> Hello,
>
> Am I the only one or did Google closed anonymous access to Google groups?
> Could it be a setting in the group config?
>
> In my opinion, it is not acceptable for the project if accessing the
> Django group posts require authentication.
>
> If someone has more information about that change, that would be great.
>
> Claude
> --
> www.2xlibre.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/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net
> .
>


-- 
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/CAMyDDM1GgzzLnLx4GSiDfvuEWkdO9TS6Uw0%3DXzkfxso%2BBaaAWg%40mail.gmail.com.

Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Currently, when you order a security audit on a Django project from any of the 
firms I've seen so far (including my own), all inputs fall short on stuff like:

"First name input: allows special caracters such as <>/"' which may cause a 
security issue with further developments done on the same database but outside 
Django".

As far as I can imagine, special caracters would be acceptable on inputs that 
should accept code or some kind of math, which is not the case for most inputs.

Django should harden default input validation to make it easier for Django 
projects to get a good grade on security audits, without having to go over all 
fields to setup basic input validators.

-- 
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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.com.

Re: Django default input validation accepts special caracters

[Kacper Szmigiel]

Hello!

Maybe some `special_characters` bool field on models.CharField with default
to `False` would do the job?


wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers
(Contributions to Django itself) 
napisał(a):

> Currently, when you order a security audit on a Django project from any of
> the firms I've seen so far (including my own), all inputs fall short on
> stuff like:
>
> "First name input: allows special caracters such as <>/"' which may cause
> a security issue with further developments done on the same database but
> outside Django".
>
> As far as I can imagine, special caracters would be acceptable on inputs
> that should accept code or some kind of math, which is not the case for
> most inputs.
>
> Django should harden default input validation to make it easier for Django
> projects to get a good grade on security audits, without having to go over
> all fields to setup basic input validators.
>
> --
> 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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.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/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.com.

Re: Django default input validation accepts special caracters

[Adam Johnson]

I am against adding validation here. See the classic *Falsehoods
Programmers Believe About Names*:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
.

Here are some characters that have caused security issues in the past (e.g.
URL bar display), but I'd reckon are legitimate in some human names:

   - non-breaking space
   - zero-width space
   - RTL or LTR markers
   - Quote marks

If you do want to block this, we don't need a new argument to Charfield.
You can implement a custom validator, and even pair it with a database
constraint. But you might block legitimate users.

The only change we should be making is moving from separate first_name +
last_name fields to solely a name field, since *many* people don't fit into
that. I think there's a ticket, but there are massive backwards
compatibility concerns.

P.S. never forget the case of Mr Null: https://www.wired.com/2015/11/null/

On Tue, 18 Aug 2020 at 09:39, Kacper Szmigiel 
wrote:

> Hello!
>
> Maybe some `special_characters` bool field on models.CharField with
> default to `False` would do the job?
>
>
> wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers
> (Contributions to Django itself) 
> napisał(a):
>
>> Currently, when you order a security audit on a Django project from any
>> of the firms I've seen so far (including my own), all inputs fall short on
>> stuff like:
>>
>> "First name input: allows special caracters such as <>/"' which may cause
>> a security issue with further developments done on the same database but
>> outside Django".
>>
>> As far as I can imagine, special caracters would be acceptable on inputs
>> that should accept code or some kind of math, which is not the case for
>> most inputs.
>>
>> Django should harden default input validation to make it easier for
>> Django projects to get a good grade on security audits, without having to
>> go over all fields to setup basic input validators.
>>
>> --
>> 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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.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/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.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/CAMyDDM2CsjYg-8DJ2AyOpbbnn-vR-CUK9DSSf-1_wywJejg4aQ%40mail.gmail.com.

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Well, at least in my country there's a law that tells what characters are 
allowed in names, anyway, a single name field would be cool but off topic here: 
"first name" was used here as an example to illustrate that Django projects are 
audited as insecure because there is no input validation at all by default.

For example, django.core.validators does supply a number of useful validators, 
but perhaps it could provide more ie. to restrict special caracters, raise 
warnings for fields which haven't any validators at all and force the user to 
set validators=[] like ForeignKey currently does for on_delete.

Not sure if anything can/should be done though, ideas welcome :)

-- 
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/axIVyVbjd0bFateqELjclTklc1vX8cAP7X3nYhjF7OgqXyraSnlBcVZQyIZ74qaTxVWfct410z2Dt8GNU50WE2gPt0f8EYUvKr4fVW_Wlzw%3D%40protonmail.com.

Re: Anonymous access to the forum

[Claude Paroz]

Looks like it works again like before, now.
It may have been a temporary "accident"…

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2bb2c81b-8ec3-4ec2-8f3d-e184ca7fd7aeo%40googlegroups.com.

Re: Anonymous access to the forum

[Claude Paroz]

Maybe I spoke too quickly.
Now I'm asked for login again :-(

Claude

Le mardi 18 août 2020 13:27:35 UTC+2, Claude Paroz a écrit :
>
> Looks like it works again like before, now.
> It may have been a temporary "accident"…
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/87b5460e-9979-498e-b74e-a20e06d0f2aeo%40googlegroups.com.

Re: Cache framework

[Carlton Gibson]

I think we SHOULD bring a redis cache backend into core. 

The recent survey showed 70% of our users using redis for caching, with 20%+ 
using memcached. 

Nick is working on 
https://github.com/django/django/pull/13310 now. 

This’ll give us three memcached backends and zero for redis. 
That doesn’t seem right. 

The cache backend API is small and redis is stable. I think we can offer that, 
freeing third party packages some work, to do the more interesting things. 

C.

-- 
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/26abf3f8-c911-4a87-b980-fa489e06ef03o%40googlegroups.com.

Re: Cache framework

[Tobias McNulty]

On Tue, Aug 18, 2020 at 9:34 AM Carlton Gibson 
wrote:

> I think we SHOULD bring a redis cache backend into core.
>
> The recent survey showed 70% of our users using redis for caching, with
> 20%+ using memcached.
>
> Nick is working on
> https://github.com/django/django/pull/13310 now.
>
> This’ll give us three memcached backends and zero for redis.
> That doesn’t seem right.
>
> The cache backend API is small and redis is stable. I think we can offer
> that, freeing third party packages some work, to do the more interesting
> things.
>

+1, even as someone who does not self-identify as a Redis enthusiast.


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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/CAMGFDKT%2B_x%3D2Yb-d1SuzcTpzuzhDmT%2Bh1FqpuV_5i2%2BY%3D%2B32OA%40mail.gmail.com.

RE: Django default input validation accepts special caracters

[Matthew Pava]

Thank you so much for sharing that, Adam. I’ve always wondered what the best 
way was to deal with names. The systems I work with should be able to handle 
names from all countries of the world. I find you kalzumeus link only slightly 
helpful, though. It explains what we shouldn’t do. I’d rather just have an 
explanation of what we should do to handle names. Seriously, should we have 
just one field that a person can enter their full name? Or multiple fields?

And perhaps Django should lead on this. As bad as the backwards compatibility 
concerns are, we should probably just address it once and for all.

From: django-developers@googlegroups.com  
On Behalf Of Adam Johnson
Sent: Tuesday, August 18, 2020 4:26 AM
To: django-developers@googlegroups.com
Subject: Re: Django default input validation accepts special caracters

I am against adding validation here. See the classic Falsehoods Programmers 
Believe About Names: 
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
 .

Here are some characters that have caused security issues in the past (e.g. URL 
bar display), but I'd reckon are legitimate in some human names:

  *   non-breaking space
  *   zero-width space
  *   RTL or LTR markers
  *   Quote marks
If you do want to block this, we don't need a new argument to Charfield. You 
can implement a custom validator, and even pair it with a database constraint. 
But you might block legitimate users.

The only change we should be making is moving from separate first_name + 
last_name fields to solely a name field, since *many* people don't fit into 
that. I think there's a ticket, but there are massive backwards compatibility 
concerns.

P.S. never forget the case of Mr Null: 
https://www.wired.com/2015/11/null/

On Tue, 18 Aug 2020 at 09:39, Kacper Szmigiel 
mailto:szmigielkac...@gmail.com>> wrote:
Hello!

Maybe some `special_characters` bool field on models.CharField with default to 
`False` would do the job?

wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers 
(Contributions to Django itself) 
mailto:django-developers@googlegroups.com>> 
napisał(a):
Currently, when you order a security audit on a Django project from any of the 
firms I've seen so far (including my own), all inputs fall short on stuff like:

"First name input: allows special caracters such as <>/"' which may cause a 
security issue with further developments done on the same database but outside 
Django".

As far as I can imagine, special caracters would be acceptable on inputs that 
should accept code or some kind of math, which is not the case for most inputs.

Django should harden default input validation to make it easier for Django 
projects to get a good grade on security audits, without having to go over all 
fields to setup basic input validators.
--
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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.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/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.com

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks Adam. I did set the value to "Anyone on the web" again (it had that 
value already). And since that didn't change anything I went public: 
https://twitter.com/m_holtermann/status/1295635386820157440

What _does_ work, is viewing threads directly, only showing a list of threads 
doesn't work for me as an anonymous user.

Cheers,

Markus

On Tue, Aug 18, 2020, at 10:31 AM, Adam Johnson wrote:
> You're not the only one, I also get redirected to login when visiting 
> the group URL in a "private mode" window: 
> https://groups.google.com/group/django-developers
> 
> I did some research and found there's a "New Google Groups" update. I 
> think this has done it. Links:
>  * Beta announcement post: 
> https://gsuiteupdates.googleblog.com/2020/03/new-google-groups-beta.html
>  * General release post: 
> https://gsuiteupdates.googleblog.com/2020/05/new-google-groups-generally-available.html
>  * List of changes: https://support.google.com/a/answer/9687393 (I 
> couldn't spot anything related to removing anonymous access)
> I checked on another group I'm an admin for and in settings I found 
> "Who can see group" with options "Group members" and "Anyone on the 
> web". Perhaps Google didn't migrate this setting and we need to reset 
> it to "Anyone on the web"? Can one of the admins for django-users and 
> django-developers check?
> 
> On Tue, 18 Aug 2020 at 08:14, Claude Paroz  wrote:
> > Hello,
> > 
> > Am I the only one or did Google closed anonymous access to Google groups?
> > Could it be a setting in the group config?
> > 
> > In my opinion, it is not acceptable for the project if accessing the
> > Django group posts require authentication.
> > 
> > If someone has more information about that change, that would be great.
> > 
> > Claude
> > -- 
> > www.2xlibre.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/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.
> 
> 
> -- 
> 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/CAMyDDM1GgzzLnLx4GSiDfvuEWkdO9TS6Uw0%3DXzkfxso%2BBaaAWg%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 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/cd206b2e-d837-4cf0-8416-e0bdfe3d27cc%40www.fastmail.com.

Re: Cache framework

[Adam Johnson]

>
> The recent survey showed 70% of our users using redis for caching, with
> 20%+ using memcached.


Oh I see you brought data to an opinion fight :)

Okay if those are even within 20% of the truth, it completely makes sense
to add Redis support! +1

On Tue, 18 Aug 2020 at 14:54, Tobias McNulty  wrote:

> On Tue, Aug 18, 2020 at 9:34 AM Carlton Gibson 
> wrote:
>
>> I think we SHOULD bring a redis cache backend into core.
>>
>> The recent survey showed 70% of our users using redis for caching, with
>> 20%+ using memcached.
>>
>> Nick is working on
>> https://github.com/django/django/pull/13310 now.
>>
>> This’ll give us three memcached backends and zero for redis.
>> That doesn’t seem right.
>>
>> The cache backend API is small and redis is stable. I think we can offer
>> that, freeing third party packages some work, to do the more interesting
>> things.
>>
>
> +1, even as someone who does not self-identify as a Redis enthusiast.
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.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/CAMGFDKT%2B_x%3D2Yb-d1SuzcTpzuzhDmT%2Bh1FqpuV_5i2%2BY%3D%2B32OA%40mail.gmail.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/CAMyDDM1A_eCMDTSEmE3uLi5TjM-e9NSazkRHWfWwtgD%3DTQEFFQ%40mail.gmail.com.

Re: Django default input validation accepts special caracters

[Adam Johnson]

Here's a reference from W3C on "what you should do":
https://www.w3.org/International/questions/qa-personal-names#singlefield -
with a great intro.

I'm not sure what a django.contrib.auth migration path could look like.
We'd probably want to preserve the first_name + last_name behaviour as an
option as combining without breaking systems will be very difficult.

On Tue, 18 Aug 2020 at 15:26, Matthew Pava  wrote:

> Thank you so much for sharing that, Adam. I’ve always wondered what the
> best way was to deal with names. The systems I work with should be able to
> handle names from all countries of the world. I find you kalzumeus link
> only slightly helpful, though. It explains what we shouldn’t do. I’d rather
> just have an explanation of what we should do to handle names. Seriously,
> should we have just one field that a person can enter their full name? Or
> multiple fields?
>
>
>
> And perhaps Django should lead on this. As bad as the backwards
> compatibility concerns are, we should probably just address it once and for
> all.
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *Adam Johnson
> *Sent:* Tuesday, August 18, 2020 4:26 AM
> *To:* django-developers@googlegroups.com
> *Subject:* Re: Django default input validation accepts special caracters
>
>
>
> I am against adding validation here. See the classic *Falsehoods
> Programmers Believe About Names*:
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> 
> .
>
>
>
> Here are some characters that have caused security issues in the past
> (e.g. URL bar display), but I'd reckon are legitimate in some human names:
>
>- non-breaking space
>- zero-width space
>- RTL or LTR markers
>- Quote marks
>
> If you do want to block this, we don't need a new argument to Charfield.
> You can implement a custom validator, and even pair it with a database
> constraint. But you might block legitimate users.
>
>
>
> The only change we should be making is moving from separate first_name +
> last_name fields to solely a name field, since *many* people don't fit into
> that. I think there's a ticket, but there are massive backwards
> compatibility concerns.
>
>
>
> P.S. never forget the case of Mr Null: https://www.wired.com/2015/11/null/
> 
>
>
>
> On Tue, 18 Aug 2020 at 09:39, Kacper Szmigiel 
> wrote:
>
> Hello!
>
> Maybe some `special_characters` bool field on models.CharField with
> default to `False` would do the job?
>
>
>
> wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers
> (Contributions to Django itself) 
> napisał(a):
>
> Currently, when you order a security audit on a Django project from any of
> the firms I've seen so far (including my own), all inputs fall short on
> stuff like:
>
>
>
> "First name input: allows special caracters such as <>/"' which may cause
> a security issue with further developments done on the same database but
> outside Django".
>
>
>
> As far as I can imagine, special caracters would be acceptable on inputs
> that should accept code or some kind of math, which is not the case for
> most inputs.
>
>
>
> Django should harden default input validation to make it easier for Django
> projects to get a good grade on security audits, without having to go over
> all fields to setup basic input validators.
>
> --
> 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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itsel

Re: include_block template tag

[Sam Willis]

Hi Jure,

I think this would be a great addition to Django!

I also proposed something a few years ago which was almost identical 
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ) 
and had a basic implementation (it probably won't work anymore without some 
tweaks). However from my experience then it will be difficult to get this 
into core without the championing from a core developer.

If there was enough interest I would certainly be happy to contribute to 
the feature!

Sam

On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote:
>
> While rendering templates we often come into situations where data remains 
> the same, but sometimes we want to render it one way, other times - another.
>
> Examples:
>
> a library supporting various CSS frameworks. You would always render panel 
>  title and 
> panel body, but bootstrap does it using one HTML, material uses another.
>
> you may decide to render a piece of data in a panel, input, table cell, 
> etc.
>
> analysis:
>
> There's a huge note with include tag 
>  
> clarifying how include tag is NOT used for purposes listed above. This 
> leads me to believe (but I have not researched it thoroughly) that the 
> question has been asked many times before.
>
> proposal:
>
> implement support for passing HTML renders into an included template.
>
> I see two possible approaches for this:
>
> Approach 1 template example:
>
> {% includeblock template with ... %}
> {% subblock block1 %}
>  HTML code
> {% endsubblock %}
> {% subblock block2 %}
>  HTML code
> {% endsubblock %}
> {% endincludeblock %}
>
> block1 and block2 would be blocks defined in template using existing block 
> syntax. I'm not sure if recycling existing block tag would be possible in 
> this context, but I would certainly prefer to avoid new template tag 
> syntax. Basically what this tag would do is first evaluate the subblocks, 
> then override the blocks defined in the template, then render the template.
>
> Approach 2 template example:
>
> {% block block1 as block1_var %}
>HTML code
> {% endblock %}
> {% subblock block2 %}
>HTML code
> {% endsubblock %}
> {% include template with block1=block1_var block2=block2_var %}
>
> This approach is a bit less structured than the first one, but it requires 
> a lot less modification. Basically it would only add the with parameter to 
> store block render in a variable instead of actually rendering it to 
> output. Possible problem with block inheritance within the template.
>
>
> Would either of the above be interesting to include in Django templating 
> code?
>
> Thanks for your consideration,
> Jure
>

-- 
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/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com.

Re: Cache framework

[René Fleschenberg]

Hi,

On 8/18/20 3:33 PM, Carlton Gibson wrote:
> I think we SHOULD bring a redis cache backend into core. 
Would this also mean supporting Redis-specific APIs? I'm thinking of
listing keys in particular. Would Django then throw an exception on
backends that don't support this? Or would the built-in cache backend
just not expose those APIs?

-- 
René Fleschenberg

-- 
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/4d2520cd-a693-f1a6-b493-a4d8fd8692d3%40fleschenberg.net.

Re: Django default input validation accepts special caracters

[Curtis Maloney]

Just my 0.02 $CURRENCY...

Interesting they're limiting the input for a security issue [at least from the 
example] that manifest from not escaping _output_.

Seems related to something I learned early in my web career... about not 
storing values escaped, because you don't know which medium it needs escaping 
for -- e.g. HTML needs different escaping than URLs.

--
Curtis


On Tue, 18 Aug 2020, at 18:35, '1337 Shadow Hacker' via Django developers  
(Contributions to Django itself) wrote:
> Currently, when you order a security audit on a Django project from any of 
> the firms I've seen so far (including my own), all inputs fall short on stuff 
> like:
> 
> "First name input: allows special caracters such as <>/"' which may cause a 
> security issue with further developments done on the same database but 
> outside Django".
> 
> As far as I can imagine, special caracters would be acceptable on inputs that 
> should accept code or some kind of math, which is not the case for most 
> inputs.
> 
> Django should harden default input validation to make it easier for Django 
> projects to get a good grade on security audits, without having to go over 
> all fields to setup basic input validators.
> 

> --
> 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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.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/b49fc6b2-1a54-4b93-8263-46ad65604407%40www.fastmail.com.

Re: Django default input validation accepts special caracters

[אורי]

On Tue, Aug 18, 2020 at 12:26 PM Adam Johnson  wrote:

>
> The only change we should be making is moving from separate first_name +
> last_name fields to solely a name field, since *many* people don't fit into
> that. I think there's a ticket, but there are massive backwards
> compatibility concerns.
>

This may be true - not all people have first_name & last_name or want to
use them online. But it's also convenient to be able to call a person by
their first name, and also allow them to use their full name on the
website. I checked popular websites - Facebook and Google require first
name and last name, Twitter, GitHub and Stack Overflow require only a
"name", and I heard that in some IP addresses and languages Facebook
doesn't require a last name, but I tried and I couldn't delete my last name
from Facebook. I have a formal last name, but I want to be registered only
with my first name on Facebook, which I can't. And by the way, Facebook,
Twitter and Github let me change my username, Google didn't. So I have to
use a username which doesn't reflect my real name on Google (I changed my
last name and the username reflects my former last name). The only way to
use a different username on Google is to create a new account. But also if
I change my username, my email address would change, and messages sent to
my previous email address might not reach me.

אורי.

-- 
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/CABD5YeE6wmedgQk5c15ND8TU4xN4iOMyS2Cn6cEL2NJ4DBi12A%40mail.gmail.com.

Re: Cache framework

[Carlton Gibson]

> On 19 Aug 2020, at 00:11, René Fleschenberg  wrote:
> 
> Or would the built-in cache backend
> just not expose those APIs?

That one. 

All I’m proposing is a backend with the current API. 

Over time that API has grown slightly, so maybe there’d be a case for 
additional methods, but that would be a separate issue. 

C.

-- 
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/4CF5F8CA-207F-4D91-98D0-323E179990A5%40gmail.com.

Re: Cache framework

[Jure Erznožnik]

May I ask where that survey was conducted? I totally missed it.

LP,
Jure

On 18/08/2020 15:33, Carlton Gibson wrote:

I think we SHOULD bring a redis cache backend into core.

The recent survey showed 70% of our users using redis for caching, with 20%+ 
using memcached.

Nick is working on
https://github.com/django/django/pull/13310 now.

This’ll give us three memcached backends and zero for redis.
That doesn’t seem right.

The cache backend API is small and redis is stable. I think we can offer that, 
freeing third party packages some work, to do the more interesting things.

C.



--
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/c5902e09-c9b5-4a99-5d83-c53dd72ba38f%40gmail.com.

Re: Cache framework

[Carlton Gibson]

Here’s the blog post: 

https://www.djangoproject.com/weblog/2020/jul/28/community-survey-2020/ 


It includes links to charts and raw results. 

> On 19 Aug 2020, at 08:24, Jure Erznožnik  wrote:
> 
> May I ask where that survey was conducted? I totally missed it.
> 
> LP,
> Jure
> 
> On 18/08/2020 15:33, Carlton Gibson wrote:
>> I think we SHOULD bring a redis cache backend into core.
>> 
>> The recent survey showed 70% of our users using redis for caching, with 20%+ 
>> using memcached.
>> 
>> Nick is working on
>> https://github.com/django/django/pull/13310 now.
>> 
>> This’ll give us three memcached backends and zero for redis.
>> That doesn’t seem right.
>> 
>> The cache backend API is small and redis is stable. I think we can offer 
>> that, freeing third party packages some work, to do the more interesting 
>> things.
>> 
>> C.
>> 
> 
> -- 
> 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/c5902e09-c9b5-4a99-5d83-c53dd72ba38f%40gmail.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/CCA1F32D-9AF2-4EE4-A429-3F2274849896%40gmail.com.

Re: Django default input validation accepts special caracters

[Florian Apolloner]

On Wednesday, August 19, 2020 at 2:01:51 AM UTC+2 cur...@tinbrain.net wrote:

> Seems related to something I learned early in my web career... about not 
> storing values escaped, because you don't know which medium it needs 
> escaping for -- e.g. HTML needs different escaping than URLs.
>

Exactly, this is the way to go. I'd switch any security firm that complains 
about "allowing special characters" in security audits in a heartbeat.

-- 
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/5bfa7411-67e5-414d-bd52-f5162b26db73n%40googlegroups.com.