diff options
| author | Aymeric Augustin <aymeric.augustin@m4x.org> | 2014-12-23 22:29:01 +0100 |
|---|---|---|
| committer | Aymeric Augustin <aymeric.augustin@m4x.org> | 2014-12-27 18:02:34 +0100 |
| commit | 6d52f6f8e688b5c4e70be8352eb02c05fea60e85 (patch) | |
| tree | 253c8fe96adf7780790e85e8f4f0c1e8daeb5a37 /docs | |
| parent | 5c5eb5fea4d7dcd2b0eed982021cfa8aeee2efd8 (diff) | |
Fixed #23831 -- Supported strings escaped by third-party libs in Django.
Refs #7261 -- Made strings escaped by Django usable in third-party libs.
The changes in mark_safe and mark_for_escaping are straightforward. The
more tricky part is to handle correctly objects that implement __html__.
Historically escape() has escaped SafeData. Even if that doesn't seem a
good behavior, changing it would create security concerns. Therefore
support for __html__() was only added to conditional_escape() where this
concern doesn't exist.
Then using conditional_escape() instead of escape() in the Django
template engine makes it understand data escaped by other libraries.
Template filter |escape accounts for __html__() when it's available.
|force_escape forces the use of Django's HTML escaping implementation.
Here's why the change in render_value_in_context() is safe. Before Django
1.7 conditional_escape() was implemented as follows:
if isinstance(text, SafeData):
return text
else:
return escape(text)
render_value_in_context() never called escape() on SafeData. Therefore
replacing escape() with conditional_escape() doesn't change the
autoescaping logic as it was originally intended.
This change should be backported to Django 1.7 because it corrects a
feature added in Django 1.7.
Thanks mitsuhiko for the report.
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions
