Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#6948 closed (fixed)

Join filter string literal escaped, docs say it shouldn't

Reported by: dougvanhorn@… Owned by: mtredinnick
Component: Template system Version: master
Severity: Keywords: join filter stringliteral
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Per the template documentation, string literal arguments are inserted into a template without being escaped, e.g.,:

{{ foo|default:"&" }}

renders:

&

and not:

&

But when I do:

{{ foo_list|join:" & " }}

I get the HTML:

1 & 2 & 3

instead of:

1 & 2 & 3

In other words, the string literal supplied to the join filter is escaped, where the docs imply otherwise, or at least aren't quite clear IMHO.

I've provided a patch that fixes the problem with the join filter that conditionally escapes the user data but leaves the string literal unescaped.

Attachments (1)

defaultfilters.patch (1.3 KB) - added by dougvanhorn@… 7 years ago.
Patch for join filter.

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by dougvanhorn@…

Patch for join filter.

comment:1 Changed 7 years ago by telenieko

  • Component changed from Uncategorized to Documentation
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Summary changed from Join filter arg being escaped. to Join filter string literal escaped, docs say it shouldn't
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 7 years ago by mtredinnick

  • Component changed from Documentation to Template system
  • Owner changed from nobody to mtredinnick
  • Status changed from new to assigned
  • Triage Stage changed from Accepted to Design decision needed

Argh. :-(

This is correct, but I wish it had of been filed under the right component so we might have noticed it in the lead up to 1.0. Fixing the join filter properly will be backwards incompatible in a unsafe way (if you haven't HTML-escaped the literal, it will appear as non-escaped if we change this). So we might just have to wear the inconsistency and document it.

I'll think about it.

comment:3 Changed 7 years ago by SmileyChris

Since the docs explicitly state that literals are safe data, I'd say this is a bug fix.

comment:4 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [9442]) Fixed #6948 -- The join filter was escaping the literal value that was
passed in for the connector. This was contrary to what the documentation
for autoescaping said and to what every other filter does with literal
strings as arguments.

This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.

comment:5 Changed 6 years ago by mtredinnick

(In [9443]) [1.0.X] Fixed #6948 -- The join filter was escaping the literal value
that was passed in for the connector. This was contrary to what the
documentation for autoescaping said and to what every other filter does
with literal strings as arguments.

This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.

Backport of r9442 from trunk.

Note: See TracTickets for help on using tickets.
Back to Top