p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
django/tests/utils_tests/test_safestring.py

101 lines
3.2 KiB
Python
Raw Normal View History

Sorted imports with isort; refs #23860.
2015-01-28 20:35:27 +08:00
from django.template import Context, Template
Refs #24046 -- Removed mark_for_escaping() per deprecation timeline.
2017-01-01 01:43:30 +08:00
from django.test import SimpleTestCase
Fixed #29412 -- Stopped marking slugify() result as HTML safe.
2018-07-14 16:38:18 +08:00
from django.utils import html
Reintroduced lazy import from commit 52138b1fd0
2017-01-30 22:17:39 +08:00
from django.utils.functional import lazy, lazystr
Refs #24046 -- Removed mark_for_escaping() per deprecation timeline.
2017-01-01 01:43:30 +08:00
from django.utils.safestring import SafeData, mark_safe
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
Refs #23919 -- Removed six.<various>_types usage Thanks Tim Graham and Simon Charette for the reviews.
2016-12-29 23:27:49 +08:00
class customescape(str):
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.
2014-12-24 05:29:01 +08:00
def __html__(self):
# implement specific and obviously wrong escaping
# in order to be able to tell for sure when it runs
return self.replace('<', '<<').replace('>', '>>')
Refs #24652 -- Used SimpleTestCase where appropriate.
2015-04-18 05:38:20 +08:00
class SafeStringTest(SimpleTestCase):
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
def assertRenderEqual(self, tpl, expected, **context):
context = Context(context)
tpl = Template(tpl)
self.assertEqual(tpl.render(context), expected)
def test_mark_safe(self):
s = mark_safe('a&b')
self.assertRenderEqual('{{ s }}', 'a&b', s=s)
self.assertRenderEqual('{{ s|force_escape }}', 'a&amp;b', s=s)
Refs #27795 -- Prevented SafeText from losing safe status on str() This will allow to replace force_text() by str() in several places (as one of the features of force_text is to keep the safe status).
2017-01-31 02:15:59 +08:00
def test_mark_safe_str(self):
"""
Calling str() on a SafeText instance doesn't lose the safe status.
"""
s = mark_safe('a&b')
self.assertIsInstance(str(s), type(s))
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.
2014-12-24 05:29:01 +08:00
def test_mark_safe_object_implementing_dunder_html(self):
e = customescape('<a&b>')
s = mark_safe(e)
self.assertIs(s, e)
self.assertRenderEqual('{{ s }}', '<<a&b>>', s=s)
self.assertRenderEqual('{{ s|force_escape }}', '&lt;a&amp;b&gt;', s=s)
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
def test_mark_safe_lazy(self):
s = lazystr('a&b')
Revert "Fixed #20296 -- Allowed SafeData and EscapeData to be lazy" This reverts commit 2ee447fb5f8974b432d3dd421af9a242215aea44. That commit introduced a regression (#21882) and didn't really do what it was supposed to: while it did delay the evaluation of lazy objects passed to mark_safe(), they weren't actually marked as such so they could end up being escaped twice. Refs #21882.
2014-02-05 12:16:39 +08:00
self.assertIsInstance(mark_safe(s), SafeData)
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
self.assertRenderEqual('{{ s }}', 'a&b', s=mark_safe(s))
Fixed an inconsistency introduced in 547b1810. mark_safe and mark_for_escaping should have been kept similar. On Python 2 this change has no effect. On Python 3 it fixes the use case shown in the regression test for mark_for_escaping, which used to raise a TypeError. The regression test for mark_safe is just for completeness.
2014-12-24 04:49:05 +08:00
def test_mark_safe_object_implementing_dunder_str(self):
Refs #23919 -- Stopped inheriting from object to define new style classes.
2017-01-19 15:39:46 +08:00
class Obj:
Fixed an inconsistency introduced in 547b1810. mark_safe and mark_for_escaping should have been kept similar. On Python 2 this change has no effect. On Python 3 it fixes the use case shown in the regression test for mark_for_escaping, which used to raise a TypeError. The regression test for mark_safe is just for completeness.
2014-12-24 04:49:05 +08:00
def __str__(self):
return '<obj>'
s = mark_safe(Obj())
self.assertRenderEqual('{{ s }}', '<obj>', s=s)
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.
2014-12-24 05:29:01 +08:00
def test_mark_safe_result_implements_dunder_html(self):
self.assertEqual(mark_safe('a&b').__html__(), 'a&b')
def test_mark_safe_lazy_result_implements_dunder_html(self):
self.assertEqual(mark_safe(lazystr('a&b')).__html__(), 'a&b')
Fixed #20221 -- Allowed some functions that use mark_safe() to result in SafeText. Thanks Baptiste Mispelon for the report.
2014-10-16 09:03:40 +08:00
def test_add_lazy_safe_text_and_safe_text(self):
s = html.escape(lazystr('a'))
s += mark_safe('&b')
self.assertRenderEqual('{{ s }}', 'a&b', s=s)
s = html.escapejs(lazystr('a'))
s += mark_safe('&b')
self.assertRenderEqual('{{ s }}', 'a&b', s=s)
Fixed #10107 -- Allowed using mark_safe() as a decorator. Thanks ArcTanSusan for the initial patch.
2016-06-03 05:11:43 +08:00
def test_mark_safe_as_decorator(self):
"""
mark_safe used as a decorator leaves the result of a function
unchanged.
"""
def clean_string_provider():
return '<html><body>dummy</body></html>'
self.assertEqual(mark_safe(clean_string_provider)(), clean_string_provider())
def test_mark_safe_decorator_does_not_affect_dunder_html(self):
"""
mark_safe doesn't affect a callable that has an __html__() method.
"""
class SafeStringContainer:
def __html__(self):
return '<html></html>'
self.assertIs(mark_safe(SafeStringContainer), SafeStringContainer)
def test_mark_safe_decorator_does_not_affect_promises(self):
"""
mark_safe doesn't affect lazy strings (Promise objects).
"""
def html_str():
return '<html></html>'
lazy_str = lazy(html_str, str)()
self.assertEqual(mark_safe(lazy_str), html_str())