#24046: Consider deprecating the "escape" half of django.utils.safestring
--------------------------------------+------------------------------------
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Utilities | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by timgraham):
Here's a problematic test case for my proof of concept:
{{{
@setup({'chaining111': '{% autoescape off %}{{ a|escape|add:"<script>"
}}{% endautoescape %}'})
def test_chaining111(self):
output = self.engine.render_to_string('chaining111', {'a': 'a < b'})
self.assertEqual(output, 'a < b<script>')
}}}
The documentation for the `escape` filter says,
The escaping is only applied when the string is output, so it does not
matter where in a chained sequence of filters you put `escape`: it will
always be applied as though it were the last filter. If you want escaping
to be applied immediately, use the `force_escape` filter.
My implementation changes this so that the `escape` filter no longer
executes after all other filters (it runs `conditional_escape()` right
away). This means that the above test fails and the output is: `'a <
b<script>'`.
The behavior of `escape` running last no matter its position doesn't seem
so intuitive, but it could be problematic to simply change it. A way
forward could be to deprecate the `escape` filter in favor of a new filter
called `conditional_escape` which would simply call the function of the
same name. With the new filter, template authors will get equivalent
behavior to `escape` as long as they put this filter last.
Alternatively, we could raise a deprecation warning if the `escape` filter
isn't last in the list of filters and then change the behavior to use
`conditional_escape()` at the end of the deprecation period. This has the
potential to be less safe for users, however, as a project might skip over
the Django versions with the warnings and not realize the behavior has
changed. On the other hand, I hope few users are running with autoscape
off and writing code like the test.
I'll probably take this to the mailing list in a few days. In the
meantime, feel free to comment with any thoughts.
--
Ticket URL: <https://code.djangoproject.com/ticket/24046#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.6f2bef6c266f9a6d6e9e3eb5d491c541%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
