date:20200914

Re: ConditionalGetMiddleware MD5

2020-09-14 Thread Florian Apolloner

Hi,

one thing to consider might be that md5 is usually disabled for FIPS 
enabled system (ie https://code.djangoproject.com/ticket/28401 ). So if we 
are changing something here we might also consider this.

Cheers,
Florian

On Friday, September 11, 2020 at 9:41:51 AM UTC+2 gertb...@gmail.com wrote:

> I'm not so sure this is a problem (wrt to using md5 hash of response 
> content for ETags and likely also for cache keys). The probability of a 
> naturally occurring collision with MD5 is 1.47*10-29 [1] so the risk of 
> this scenario occurring by accident is extremely remote.
>
> If we assume that User 2 is a malicious actor and can reliably generate 
> collisions (which is not practically possible within typical cache 
> durations), then User 1 is likely still no worse off. Maybe some security 
> researchers can comment on the threat model in this case.
>
> Lastly, the practical use of content hash based ETags are limited due to 
> the processing overhead required for them (as implemented in 
> ConditionalGetMiddleware). It might be useful for a low traffic/value 
> deployments and then the risks are likely not a problem. Switching to a 
> more cryptographically secure hashing algorithm will increase the overhead 
> and provide little additional benefit to such installations. As mentioned 
> earlier, production deployments will often use Apache or Nginx, and neither 
> generate ETags using file content hashes.
>
> [1] https://www.avira.com/en/blog/md5-the-broken-algorithm
>
> On Fri, 11 Sep 2020 at 08:25, Francisco Couzo  wrote:
>
>> If changing ConditionalGetMiddleware to use SHA-256
>> It also might be a good to change it on FileBasedCache, 
>> _generate_cache_key, and generate_cache_header_key too
>> Also, _generate_cache_key is just blindly concatenating hashes, so 
>> ['foo', 'bar'] is equal to ['fo', 'obar'], I don't know it might be a 
>> problem, but it just doesn't looks right
>>
>>
>> On Thu, Sep 10, 2020 at 10:14 PM Taymon A. Beal  
>> wrote:
>>
>>> That attack doesn't work with the recommended production setup because
>>> Django doesn't serve uploaded files in that setup.
>>>
>>> That being said, some users might be doing that anyway since setting
>>> up production-worthy upload hosting is such a pain, and even if they
>>> don't, they might have other views that somehow allow users to control
>>> the response body. So I think this should be treated as a
>>> not-super-severe-but-still-worth-fixing security issue.
>>>
>>> What backwards-compatibility considerations exist? Do we consider it
>>> normal for upgrading to a different Django version to bust users'
>>> caches? I can't immediately think of any bad consequences of changing
>>> the hash function, apart from that one. Busting users' caches doesn't
>>> sound that terrible, given that, even if the hash function were
>>> changed on every release (which of course it wouldn't be; SHA-2 has
>>> been the most generally-recommended hash function for 15 years and
>>> there are no signs that this will change), it would still only happen
>>> once every eight months, and it's fairly rare for anything to be
>>> cached that long in the first place, I think.
>>>
>>> Taymon
>>>
>>>
>>> On Thu, Sep 10, 2020 at 1:16 PM Francisco Couzo  
>>> wrote:
>>> >
>>> > User 1 uploads a file
>>> > User 2 downloads it, and caches it
>>> > User 1 uploads a new file to the same URL, with the same MD5 hash
>>> > User 2 will keep using the old file indefinitely
>>> >
>>> > Sure, user 1 has to upload two files with the same hash on purpose
>>> >
>>> > On Thu, Sep 10, 2020 at 11:07 AM Adam Johnson  wrote:
>>> >>
>>> >> What would this protect against?
>>> >>
>>> >> On Thu, 10 Sep 2020 at 03:56, Francisco Couzo  
>>> wrote:
>>> >>>
>>> >>> I think it would be a good idea to make ConditionalGetMiddleware use 
>>> a hash function that's not as easy to find a collision as MD5, most 
>>> probably SHA-256 or BLAKE2.
>>> >>> I don't see a problem with just changing it, it will just invalidate 
>>> the old cache.
>>> >>> If there's an agreement on changing the hash function, I can make 
>>> the PR.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>>
>>> >>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> >>>
>>> >>>
>>> >>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to django-develop...@googlegroups.com.
>>> >>>
>>> >>>
>>> >>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%40googlegroups.com
>>> .
>>> >>>
>>> >>>
>>> >> --
>>> >> Adam
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to django-develop...@googleg

Re: ConditionalGetMiddleware MD5

2020-09-14 Thread Adam Johnson

Yes there's a risk of causing collisions if a user can control the
responses. But that doesn't mean there's really a security concern - since
the user creating the collision *can already upload arbitrary content to
the django site.* The collision wouldn't really do anything but cause a
stale asset to appear - which is a known risk with conditional GET's to
begin with.

Additionally, e-tag calculation needs to be *fast* since it is run on every
response. So moving to a slower hashing algorithm like SHA would be a
performance degradation. There are some other deliberately fast hashing
algorithms out there, though I don't know if they carry any advantages in
this situation over MD5.

For those concerned, we could make etag collisions slightly less easy to
forge by including a salt. Perhaps this could be derived from SECRET_KEY or
some other setting. I'm not sure SECRET_KEY is appropriate though... if we
used that SECRET_KEY because then we'd be sending a payload of content,
with etag=MD5(content + SECRET_KEY), which could be cracked to retrieve
SECRET_KEY.

ConditionalGetMiddleware only sets the ETag header if it's not already set.
So if you're interested, you can experiment with different ETag algorithms
by adding a custom middleware below it in your MIDDLEWARE setting.

Before we change anything it would also be useful to see a summary of how
other major servers and frameworks have settled on creating ETags for
dynamic content - such as Ruby, Nginx, Apache, Nginx, CloudFlare. If
there's any problem with collisions they'll likely have already solved it.

one thing to consider might be that md5 is usually disabled for FIPS
> enabled system
>

This is true, but if no one has complained, why "fix" it? As covered above
one can always implement custom ETag header generation.

On Mon, 14 Sep 2020 at 08:41, Florian Apolloner 
wrote:

> Hi,
>
> one thing to consider might be that md5 is usually disabled for FIPS
> enabled system (ie https://code.djangoproject.com/ticket/28401 ). So if
> we are changing something here we might also consider this.
>
> Cheers,
> Florian
>
> On Friday, September 11, 2020 at 9:41:51 AM UTC+2 gertb...@gmail.com
> wrote:
>
>> I'm not so sure this is a problem (wrt to using md5 hash of response
>> content for ETags and likely also for cache keys). The probability of a
>> naturally occurring collision with MD5 is 1.47*10-29 [1] so the risk of
>> this scenario occurring by accident is extremely remote.
>>
>> If we assume that User 2 is a malicious actor and can reliably generate
>> collisions (which is not practically possible within typical cache
>> durations), then User 1 is likely still no worse off. Maybe some security
>> researchers can comment on the threat model in this case.
>>
>> Lastly, the practical use of content hash based ETags are limited due to
>> the processing overhead required for them (as implemented in
>> ConditionalGetMiddleware). It might be useful for a low traffic/value
>> deployments and then the risks are likely not a problem. Switching to a
>> more cryptographically secure hashing algorithm will increase the overhead
>> and provide little additional benefit to such installations. As mentioned
>> earlier, production deployments will often use Apache or Nginx, and neither
>> generate ETags using file content hashes.
>>
>> [1] https://www.avira.com/en/blog/md5-the-broken-algorithm
>>
>> On Fri, 11 Sep 2020 at 08:25, Francisco Couzo 
>> wrote:
>>
>>> If changing ConditionalGetMiddleware to use SHA-256
>>> It also might be a good to change it on FileBasedCache,
>>> _generate_cache_key, and generate_cache_header_key too
>>> Also, _generate_cache_key is just blindly concatenating hashes, so
>>> ['foo', 'bar'] is equal to ['fo', 'obar'], I don't know it might be a
>>> problem, but it just doesn't looks right
>>>
>>>
>>> On Thu, Sep 10, 2020 at 10:14 PM Taymon A. Beal 
>>> wrote:
>>>
 That attack doesn't work with the recommended production setup because
 Django doesn't serve uploaded files in that setup.

 That being said, some users might be doing that anyway since setting
 up production-worthy upload hosting is such a pain, and even if they
 don't, they might have other views that somehow allow users to control
 the response body. So I think this should be treated as a
 not-super-severe-but-still-worth-fixing security issue.

 What backwards-compatibility considerations exist? Do we consider it
 normal for upgrading to a different Django version to bust users'
 caches? I can't immediately think of any bad consequences of changing
 the hash function, apart from that one. Busting users' caches doesn't
 sound that terrible, given that, even if the hash function were
 changed on every release (which of course it wouldn't be; SHA-2 has
 been the most generally-recommended hash function for 15 years and
 there are no signs that this will change), it would still only happen
 once every eight months, and it'

Re: ConditionalGetMiddleware MD5

2020-09-14 Thread Florian Apolloner

Hi Adam,

On Monday, September 14, 2020 at 2:00:06 PM UTC+2 Adam Johnson wrote:

> one thing to consider might be that md5 is usually disabled for FIPS 
>> enabled system
>>
>
> This is true, but if no one has complained, why "fix" it? As covered above 
> one can always implement custom ETag header generation.
>

Well there are open tickets, so in that sense someone has "complained". I 
also know that pulp tries/tried to work around md5 usage in Django etc…  
But with regard to fips the proper way is probably the new `useforsecurity` 
argument in python3.9. 

The arguments about performance are all good and I think that if we change 
away from md5 it should probably something which is on par performance-wise.

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/961696ec-0d0f-4030-acf7-deb80854f87fn%40googlegroups.com.

Re: Admin accessibility

2020-09-14 Thread Carlton Gibson

Hi All. 

Thanks for this. I'd be happy to play *Shepherd *if you need someone to put 
their hand up. 
I think that means I need to nag about getting it done. So... 🙂

Who's going to be on the team to do the first review, and then subsequent 
work? Answer that and you have the Implementation Team. 
I like that you've thought about how the team can refresh periodically — I 
don't suppose the burden will be too great but folks tend to cycle-out 
naturally, so good to plan for that. 
Thibaud: Asking for hands in your talk seems sensible. 

Kind Regards,

Carlton



On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:

> Hi all,
>
> Now that the DEP PR has been submitted I was wondering what the next steps 
> would be. According to the documented DEP process I found, it’s at the 
> "forming 
> the team" 
> 
>  
> stage? How do you go about creating an *Implementation Team* and finding 
> a *Shepherd*?
>
> The main reason I ask is that I’ll be giving a talk about accessibility at 
> DjangoCon EU in a couple of weeks, and I thought it would be a good 
> occasion to raise awareness of the issues with the Django admin, and 
> mention this DEP. But I want to make sure I provide accurate information.
>
> Thanks in advance,
>
> Thibaud
>
> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>
>> 🎉 it’s wonderful to see this happening! Re-reading through the whole 
>> thing, as Tobias mentioned I also find it very easy to read, and makes a 
>> good case.
>>
>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>
>>> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
>>> https://github.com/django/deps/pull/69
>>>
>>> Thibaud, I think whatever you have the time and motivation for sounds 
>>> good, all of those things are useful. If you're not sure about all the 
>>> admin features, I think that's pretty normal. One project I've had on my 
>>> mind for a while now is to build a simple django site that is essentially 
>>> just there to use every feature of the admin, so I might bump that up the 
>>> priority list, though it's somewhat daunting.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:
>>>
 Update for the proof of concept CI tests from my side – thank you Tom 
 for the feedback. Here are the latest additions to the test suite & 
 reports, still living at 
 https://thibaudcolas.github.io/django_admin_tests/,

 - Added as much as I know about in the admin, and now also outside of 
 it a bit (startproject welcome page, error pages)
 - Separated the issues between Axe and HTML_CS so the numbers are 
 easier to understand
 - Added anchor links everywhere for easier navigation
 - I’ve also started a draft list of "things to (potentially) audit", 
 over at 
 https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits

 I think the next two big steps are what you mention:

 - Having a way to track the number of issues over time. Currently the 
 report overwrites itself every week (well, every build). If you have a 
 suggestion on ways to demo this that would be useful please let me know. 
 Currently I’m thinking sparklines for each test case could be nice as a 
 proof of concept, and a sparkline for the total number of issues. Or see 
 whether I should get out of my comfort zone a bit and find a 
 dashboard/graphing tool to send the metrics to and graph there.
 - Testing more features of modeladmin. I don’t use it too frequently 
 myself so don’t really know what’s “easy” to enable – if you know of an 
 existing test suite I could repurpose, or of an example of using a lot of 
 functionality – I’d be keen to invest time to add it to my test site.

 Alternatively something else I could do is to file a ticket for 
 accessibility issues with the welcome page – I’ve tested it with screen 
 readers, there are a few issues, but nothing that should be too hard to 
 fix, and it might be a good demo of what reporting accessibility issues in 
 general could look like?

 Cheers,

 Thibaud


 On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:

> Nice writeup! I found it easy to read (I did not catch myself skipping 
> paragraphs which is always a good sign). Contentwise, I would have no 
> issue if this was accepted as is. Maybe I am forgetting about some 
> important details though. 
>
> I had just some ideas that might be good additions: 
>
> - mention ATAG somewhere 
>
> - It would be nice to have a real commitment to accessibility. 
> Something 
> along the lines of "accessibility bugs must be treated with the same 
> priority as any other bugs". 
>
> - The step from "leaving accessibility in the hands

Re: What the purpose of having function that is not working correctly?

2020-09-14 Thread babloo chowhan

I have an issue in a django project please can you help me.?

On Sat, Sep 12, 2020 at 4:29 PM Tim Allen 
wrote:

> I've seen recommendations to use this during conference talks by people
> with a fairly deep knowledge of the ORM as recently as 2019, so I do
> believe it can be made more blatantly clear in its purpose. We took a stab
> at improving it during DjangoCon 2019. Consensus was that:
>
> (a) when the underlying DB driver provides a method of constructing the
> query, a la PostgreSQL's `mogrify`, we can use it;
> (b) when the underlying DB driver does NOT provide a method, we can make
> it obvious not to use it for more than debugging. IIRC, Tim Graham
> suggested we construct the string to be something like, """SQL: SELECT ...
> FROM ... WHERE x = ? AND y = ? PARAMS: ("this", "that")""" to provide the
> relevant information, but make it very obvious you can't copy pasta it into
> a SQL command line tool.
>
> Here's the PR we were working on, which also contains some good discussion
> and background in addition to Claude's PR:
> https://github.com/django/django/pull/10568
>
> ...but ultimately, we decided Claude's approach linked by Mariusz above
> was better. I'd love to see this cross the finish line one of these days;
> my burning use case was eventually solved when `queryset.explain()` was
> introduced in Django 2.1.
>
> On Friday, September 11, 2020 at 10:16:22 AM UTC-4 fran.h...@gmail.com
> wrote:
>
>> Just my $.02, literally yesterday I saw a str(queryset.query) used to
>> construct a raw SQL query. It of course suffers from the worst kind of SQL
>> injection as well.
>>
>> +1 to make it obvious, somehow, that kittens die every time it is used
>> for a real query.
>>
>>
>>
>> On 11 Sep 2020, at 15:58, Alexander Lyabah  wrote:
>>
>> I'm sorry. Now things sound even more confusing for me.
>>
>>
>> From one side you've said that "No, this function is never working in a
>> useful way." (but my example from the post shows, how it works in the
>> beginning and then stops working for datatime, which means it was pretty
>> much useful for some very common cases)
>>
>> From another side, you have accepted tickets, to make this function works
>> in a useful way.
>>
>> So it very looks like you've made a function, that returns something,
>> that very looks like SQL, but shouldn't be used as SQL, it is just for
>> debug, and you have a bunch of tickets to make SQL-like debug text to be
>> working as real SQL.
>>
>> So, my humble suggestion here is very simple. If you don't want something
>> to be used in an appropriate way, don't make it looks like it can be used
>> this way.
>>
>>
>>
>> On Thursday, September 10, 2020 at 1:40:33 PM UTC+3 f.apo...@gmail.com
>> wrote:
>>
>>> On Thursday, September 10, 2020 at 11:16:56 AM UTC+2 Alexander Lyabah
>>> wrote:
>>>
 The problem with the function is that it is actually working, but not
 always, and because of that, other people are suggesting it on
 StackOverflow, using it in prod, and may, eventually catch weird
 exceptions, which leads to a bad experience with Django in general.

>>>
>>> No, this function is never working in a useful way. It does client side
>>> interpolation of query params which should be done by the drivers instead,
>>> even when it works it is potentially dangerous. The actual problem is that
>>> people on StackOverflow recommend to use it. FWIW Since it is solely a
>>> debugging aid I'd actually break any usage of it by adding "--" to the
>>> start of it (or similar)
>>>
>>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/487cadce-51db-418f-aca4-ebe14aa16bb9n%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/81ed71d5-f83e-4e36-8cb9-f718dd33515en%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 discussi

Re: Admin accessibility

2020-09-14 Thread Tom Carrick

Carlton, I think that would be useful, thanks.

Thibaud, shall I add you to the implementation team? It seems like you're
doing more work on this than I am lately. I think we could still use one or
perhaps two more people, but I think it's a good start.

On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone to
> put their hand up.
> I think that means I need to nag about getting it done. So... 🙂
>
> Who's going to be on the team to do the first review, and then subsequent
> work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically — I
> don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and finding
>> a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about accessibility
>> at DjangoCon EU in a couple of weeks, and I thought it would be a good
>> occasion to raise awareness of the issues with the Django admin, and
>> mention this DEP. But I want to make sure I provide accurate information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>> 🎉 it’s wonderful to see this happening! Re-reading through the whole
>>> thing, as Tobias mentioned I also find it very easy to read, and makes a
>>> good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for sounds
 good, all of those things are useful. If you're not sure about all the
 admin features, I think that's pretty normal. One project I've had on my
 mind for a while now is to build a simple django site that is essentially
 just there to use every feature of the admin, so I might bump that up the
 priority list, though it's somewhat daunting.

 Cheers,
 Tom

 On Mon, 13 Jul 2020 at 01:15, Thibaud Colas 
 wrote:

> Update for the proof of concept CI tests from my side – thank you Tom
> for the feedback. Here are the latest additions to the test suite &
> reports, still living at
> https://thibaudcolas.github.io/django_admin_tests/,
>
> - Added as much as I know about in the admin, and now also outside of
> it a bit (startproject welcome page, error pages)
> - Separated the issues between Axe and HTML_CS so the numbers are
> easier to understand
> - Added anchor links everywhere for easier navigation
> - I’ve also started a draft list of "things to (potentially) audit",
> over at
> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>
> I think the next two big steps are what you mention:
>
> - Having a way to track the number of issues over time. Currently the
> report overwrites itself every week (well, every build). If you have a
> suggestion on ways to demo this that would be useful please let me know.
> Currently I’m thinking sparklines for each test case could be nice as a
> proof of concept, and a sparkline for the total number of issues. Or see
> whether I should get out of my comfort zone a bit and find a
> dashboard/graphing tool to send the metrics to and graph there.
> - Testing more features of modeladmin. I don’t use it too frequently
> myself so don’t really know what’s “easy” to enable – if you know of an
> existing test suite I could repurpose, or of an example of using a lot of
> functionality – I’d be keen to invest time to add it to my test site.
>
> Alternatively something else I could do is to file a ticket for
> accessibility issues with the welcome page – I’ve tested it with screen
> readers, there are a few issues, but nothing that should be too hard to
> fix, and it might be a good demo of what reporting accessibility issues in
> general could look like?
>
> Cheers,
>
> Thibaud
>
>
> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>
>> Nice writeup! I found it easy to read (I did not catch myself
>> skipping
>> paragraphs which is always a good sign). Contentwise, I would have no
>> issue if this was accepted as is. Maybe I am forgetting about some
>> important de

Re: Fellow Reports - September 2020

2020-09-14 Thread Mariusz Felisiak

Week ending September 13, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31985 - salted_hmac() docstring 
shouldn't mention hashlib.new(). (accepted)
https://code.djangoproject.com/ticket/31986 - Django Admin filter 
sidebar does not scroll. (accepted)
https://code.djangoproject.com/ticket/31987 - Cast() crashes with 
DurationField on MySQL and Oracle. (accepted)
https://code.djangoproject.com/ticket/31988 - Annotate Case(When()) 
duplicate objects. (duplicate)
https://code.djangoproject.com/ticket/31991 - QuerySet.raw() method 
returns string instead of dict for JSONField(). (wontfix)
https://code.djangoproject.com/ticket/31990 - QuerySet.ordered property 
is incorrect after annotate(). (accepted)
https://code.djangoproject.com/ticket/31989 - Bug in posix 
implementation of django/core/files/locks.py (accepted)
https://code.djangoproject.com/ticket/9433 - File locking broken on AFP 
mounts (fixed)
https://code.djangoproject.com/ticket/28428 - Add support for Pathlib 
objects in django.core.files.storage (fixed)
https://code.djangoproject.com/ticket/31994 - Error in Tutorial 2 
(invalid)
https://code.djangoproject.com/ticket/31995 - Unnecesarry quotes are 
created by TemporaryUploadedFile. (needsinfo)
https://code.djangoproject.com/ticket/31996 - Template Mixins (wontfix)
https://code.djangoproject.com/ticket/15249 - Provide access to a 
debugger within the development server (wontfix)
https://code.djangoproject.com/ticket/31998 - Doc'd that TEST['MIRROR'] 
requires TransactionTestCase. (duplicate)
https://code.djangoproject.com/ticket/31997 - Regression in Django 3 
related to ORM in async tasks (OperationalError: database is locked) 
(invalid)
https://code.djangoproject.com/ticket/31999 - Sqlite and datetime 
aggregates. (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/13189 - Fixed #31791 -- Made 
technical 404 debug page display the tried URL patterns for Http404.
https://github.com/django/django/pull/13391 - Fixed #31944 -- Used 
addCleanup() to register TestContextDecorator cleanups.
https://github.com/django/django/pull/13394 - Fixed #31985 -- Corrected 
salted_hmac()'s docstring about supported algorithms.
https://github.com/django/django/pull/13398 - Fixed #31987 -- Fixed 
Cast() with DurationField on MySQL.
https://github.com/django/django/pull/13395 - Fixed #31962 -- Made 
SessionMiddleware raise SessionInterrupted when session destroyed while 
request is processing.
https://github.com/django/djangoproject.com/pull/1021 - Sunset Django 
People.
https://github.com/django/django/pull/13124 - Fixed #31750 -- Made 
models.Field equality compare models for inherited fields.
https://github.com/django/django/pull/13400 - Fixed #31967 -- Doc'd 
consequences of resolving an output_field for Value().
https://github.com/django/django/pull/13402 - Fixed #31992 -- Made 
admin password reset templates use title/content_title blocks from the base 
template.
https://github.com/django/django/pull/13403 - Fixed #31993 -- Added 
subtitles to admin change/view pages.
https://github.com/django/django/pull/13406 - Fixed #31943 -- Fixed 
recreating QuerySet.values()/values_list() when using a pickled Query.
https://github.com/django/django/pull/13365 - Fixed #31766 -- Made 
GDALRaster.transform() return a clone for the same SRID and driver.
 
*Reviewed:*
https://github.com/django/django/pull/13399 - Refs #23130 -- Added test 
for BooleanField choices generation.

*Authored:*
https://github.com/django/django/pull/13404 - Refs #31956 -- Doc'd 
consequences of disabling psycopg2's JSONB typecaster.

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/df0744cd-3e1e-4792-ba80-3582cc304e91n%40googlegroups.com.

Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

2020-09-14 Thread Carles Pina i Estany



Hi,

Today I had a small surprise with templates and the linebreakbr filter.

The "problem" (or root of the confusion) is that if None (of NoneType) is given
to linebreakbr it returns a SafeString 'None' instead of None (type NoneType).

The documentation says 
(https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#std:templatefilter-linebreaks):
"""
Replaces line breaks in plain text with appropriate HTML; a single newline
becomes an HTML line break () and a new line followed by a blank line
becomes a paragraph break ().
"""

Passing a None to linebreaksbr I was expecting to receive None. I read it
literally that it would add line breaks in plain text and if there was no plain
text then nothing would be done. Or at least if None is passed it would 
return None.

For example:
{% with text=None %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

{% with text=None|linebreaksbr %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

The second block prints "None" instead of "-".

The None gets converted to the string in the decorator 'stringfilter'.
The same happens in addslashes, capfirst, etc.

Should this be noted in the documentation? Or the behaviour changed? (hard
without backward compatibility issues). Or have I missed anything? Any
thoughts?

(I've checked the Django bug tracker and I haven't seen any bug describing
this)

Cheers,

-- 
Carles Pina i Estany
https://carles.pina.cat

-- 
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/20200914194014.GA19007%40pina.cat.

RE: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

2020-09-14 Thread Matthew Pava

The filter states that it expects plain text. In Python, str(None) = "None". To 
get the behavior you are seeking use the default_if_none filter, and chain your 
other filters.
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#default-if-none
{{ text|default_if_none:""|linebreaksbr }}

-Original Message-
From: django-developers@googlegroups.com  
On Behalf Of Carles Pina i Estany
Sent: Monday, September 14, 2020 2:40 PM
To: django-developers@googlegroups.com
Subject: Incomplete documentation or bug? (linebreaksbr and stringfilter 
decorated filters)


Hi,

Today I had a small surprise with templates and the linebreakbr filter.

The "problem" (or root of the confusion) is that if None (of NoneType) is given
to linebreakbr it returns a SafeString 'None' instead of None (type NoneType).

The documentation says 
(https://us-east-2.protection.sophos.com?d=djangoproject.com&u=aHR0cHM6Ly9kb2NzLmRqYW5nb3Byb2plY3QuY29tL2VuLzMuMS9yZWYvdGVtcGxhdGVzL2J1aWx0aW5zLyNzdGQ6dGVtcGxhdGVmaWx0ZXItbGluZWJyZWFrcw==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=eTYyb1Foa2VZVFJhdVU5dVBQazhvVFMycUpCMnZHSTFkZW9IOThqYVowWT0=&h=805589589ba040129c546a8f291d13ac):
"""
Replaces line breaks in plain text with appropriate HTML; a single newline
becomes an HTML line break () and a new line followed by a blank line
becomes a paragraph break ().
"""

Passing a None to linebreaksbr I was expecting to receive None. I read it
literally that it would add line breaks in plain text and if there was no plain
text then nothing would be done. Or at least if None is passed it would 
return None.

For example:
{% with text=None %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

{% with text=None|linebreaksbr %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

The second block prints "None" instead of "-".

The None gets converted to the string in the decorator 'stringfilter'.
The same happens in addslashes, capfirst, etc.

Should this be noted in the documentation? Or the behaviour changed? (hard
without backward compatibility issues). Or have I missed anything? Any
thoughts?

(I've checked the Django bug tracker and I haven't seen any bug describing
this)

Cheers,

-- 
Carles Pina i Estany
https://us-east-2.protection.sophos.com?d=pina.cat&u=aHR0cHM6Ly9jYXJsZXMucGluYS5jYXQ=&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=QUNiOTdmclhvZW9UZm4reEtEaExwOE9hM05Vc1dQN3VIc1ZISUtjWm1UQT0=&h=805589589ba040129c546a8f291d13ac

-- 
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://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzIwMjAwOTE0MTk0MDE0LkdBMTkwMDclNDBwaW5hLmNhdA==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=MkRHTjRCUitxY0NPeUVSbmlRQi9ZMHRwclIrVFNhQ1lNTXlrQ1FSeGswRT0=&h=805589589ba040129c546a8f291d13ac.

-- 
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/b888ccf136b7465b9bf7863e7a423945%40iss2.ISS.LOCAL.

Re: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

2020-09-14 Thread Adam Johnson

Yeah imo most filters should be worried about one type. We shouldn’t
consider very variable “None-able” because it’s so pervasive.

This is somewhere that type hints will eventually help clarify.

On Mon, 14 Sep 2020 at 20:47, Matthew Pava  wrote:

> The filter states that it expects plain text. In Python, str(None) =
> "None". To get the behavior you are seeking use the default_if_none filter,
> and chain your other filters.
>
>
> https://docs.djangoproject.com/en/dev/ref/templates/builtins/#default-if-none
>
> {{ text|default_if_none:""|linebreaksbr }}
>
>
>
> -Original Message-
>
> From: django-developers@googlegroups.com <
> django-developers@googlegroups.com> On Behalf Of Carles Pina i Estany
>
> Sent: Monday, September 14, 2020 2:40 PM
>
> To: django-developers@googlegroups.com
>
> Subject: Incomplete documentation or bug? (linebreaksbr and stringfilter
> decorated filters)
>
>
>
>
>
> Hi,
>
>
>
> Today I had a small surprise with templates and the linebreakbr filter.
>
>
>
> The "problem" (or root of the confusion) is that if None (of NoneType) is
> given
>
> to linebreakbr it returns a SafeString 'None' instead of None (type
> NoneType).
>
>
>
> The documentation says (
> https://us-east-2.protection.sophos.com?d=djangoproject.com&u=aHR0cHM6Ly9kb2NzLmRqYW5nb3Byb2plY3QuY29tL2VuLzMuMS9yZWYvdGVtcGxhdGVzL2J1aWx0aW5zLyNzdGQ6dGVtcGxhdGVmaWx0ZXItbGluZWJyZWFrcw==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=eTYyb1Foa2VZVFJhdVU5dVBQazhvVFMycUpCMnZHSTFkZW9IOThqYVowWT0=&h=805589589ba040129c546a8f291d13ac
> ):
>
> """
>
> Replaces line breaks in plain text with appropriate HTML; a single newline
>
> becomes an HTML line break () and a new line followed by a blank line
>
> becomes a paragraph break ().
>
> """
>
>
>
> Passing a None to linebreaksbr I was expecting to receive None. I read it
>
> literally that it would add line breaks in plain text and if there was no
> plain
>
> text then nothing would be done. Or at least if None is passed it would
>
> return None.
>
>
>
> For example:
>
> {% with text=None %}
>
> {% if text %}{{ text }}{% else %}-{% endif %}
>
> {% endwith %}
>
> 
>
> {% with text=None|linebreaksbr %}
>
> {% if text %}{{ text }}{% else %}-{% endif %}
>
> {% endwith %}
>
>
>
> The second block prints "None" instead of "-".
>
>
>
> The None gets converted to the string in the decorator 'stringfilter'.
>
> The same happens in addslashes, capfirst, etc.
>
>
>
> Should this be noted in the documentation? Or the behaviour changed? (hard
>
> without backward compatibility issues). Or have I missed anything? Any
>
> thoughts?
>
>
>
> (I've checked the Django bug tracker and I haven't seen any bug describing
>
> this)
>
>
>
> Cheers,
>
>
>
> --
>
> Carles Pina i Estany
>
>
> https://us-east-2.protection.sophos.com?d=pina.cat&u=aHR0cHM6Ly9jYXJsZXMucGluYS5jYXQ=&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=QUNiOTdmclhvZW9UZm4reEtEaExwOE9hM05Vc1dQN3VIc1ZISUtjWm1UQT0=&h=805589589ba040129c546a8f291d13ac
>
>
>
> --
>
> 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://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzIwMjAwOTE0MTk0MDE0LkdBMTkwMDclNDBwaW5hLmNhdA==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=MkRHTjRCUitxY0NPeUVSbmlRQi9ZMHRwclIrVFNhQ1lNTXlrQ1FSeGswRT0=&h=805589589ba040129c546a8f291d13ac
> .
>
>
>
> --
>
> 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/b888ccf136b7465b9bf7863e7a423945%40iss2.ISS.LOCAL
> .
>
> --
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/CAMyDDM3Hzg%3DmUNzmsOPjLkO-%2BiNfUAeToY%3D7Kk3aUUAE5QobrA%40mail.gmail.com.

Re: ConditionalGetMiddleware MD5

Re: ConditionalGetMiddleware MD5

Re: ConditionalGetMiddleware MD5

Re: Admin accessibility

Re: What the purpose of having function that is not working correctly?

Re: Admin accessibility

Re: Fellow Reports - September 2020

Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

RE: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

Re: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

10 matches

Site Navigation

Mail list logo

Footer information