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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

124 lines
4.0 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 #20296 -- Prevented mark_safe() from evaluating lazy objects.
2022-02-19 03:27:05 +08:00
from django.utils import html, translation
from django.utils.functional import Promise, lazy, lazystr
Fixed #33465 -- Added empty __slots__ to SafeString and SafeData. Despite inheriting from the str type, every SafeString instance gains an empty __dict__ due to the normal, expected behaviour of type subclassing in Python. Adding __slots__ to SafeData is necessary, because otherwise inheriting from that (as SafeString does) will give it a __dict__ and negate the benefit added by modifying SafeString.
2022-01-25 17:53:03 +08:00
from django.utils.safestring import SafeData, SafeString, mark_safe
Fixed #20296 -- Prevented mark_safe() from evaluating lazy objects.
2022-02-19 03:27:05 +08:00
from django.utils.translation import gettext_lazy
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):
Refs #30573 -- Rephrased "Of Course" and "Obvious(ly)" in documentation and comments.
2020-05-01 20:37:21 +08:00
# Implement specific and wrong escaping in order to be able to detect
# when it runs.
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
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):
"""
Refs #27753 -- Favored SafeString over SafeText.
2019-02-05 22:38:29 +08:00
Calling str() on a SafeString instance doesn't lose the safe status.
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
"""
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):
Fixed #20296 -- Prevented mark_safe() from evaluating lazy objects.
2022-02-19 03:27:05 +08:00
safe_s = mark_safe(lazystr("a&b"))
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
Fixed #20296 -- Prevented mark_safe() from evaluating lazy objects.
2022-02-19 03:27:05 +08:00
self.assertIsInstance(safe_s, Promise)
self.assertRenderEqual("{{ s }}", "a&b", s=safe_s)
self.assertIsInstance(str(safe_s), SafeData)
def test_mark_safe_lazy_i18n(self):
s = mark_safe(gettext_lazy("name"))
tpl = Template("{{ s }}")
with translation.override("fr"):
self.assertEqual(tpl.render(Context({"s": s})), "nom")
Fixed #20296 -- Allowed SafeData and EscapeData to be lazy
2013-04-20 19:38:14 +08:00
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.
"""
Refs #33476 -- Reformatted code with Black.
2022-02-04 03:24:19 +08:00
Fixed #10107 -- Allowed using mark_safe() as a decorator. Thanks ArcTanSusan for the initial patch.
2016-06-03 05:11:43 +08:00
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.
"""
Refs #33476 -- Reformatted code with Black.
2022-02-04 03:24:19 +08:00
Fixed #10107 -- Allowed using mark_safe() as a decorator. Thanks ArcTanSusan for the initial patch.
2016-06-03 05:11:43 +08:00
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).
"""
Refs #33476 -- Reformatted code with Black.
2022-02-04 03:24:19 +08:00
Fixed #10107 -- Allowed using mark_safe() as a decorator. Thanks ArcTanSusan for the initial patch.
2016-06-03 05:11:43 +08:00
def html_str():
return "<html></html>"
lazy_str = lazy(html_str, str)()
self.assertEqual(mark_safe(lazy_str), html_str())
Fixed #33465 -- Added empty __slots__ to SafeString and SafeData. Despite inheriting from the str type, every SafeString instance gains an empty __dict__ due to the normal, expected behaviour of type subclassing in Python. Adding __slots__ to SafeData is necessary, because otherwise inheriting from that (as SafeString does) will give it a __dict__ and negate the benefit added by modifying SafeString.
2022-01-25 17:53:03 +08:00
def test_default_additional_attrs(self):
s = SafeString("a&b")
msg = "object has no attribute 'dynamic_attr'"
with self.assertRaisesMessage(AttributeError, msg):
s.dynamic_attr = True
def test_default_safe_data_additional_attrs(self):
s = SafeData()
msg = "object has no attribute 'dynamic_attr'"
with self.assertRaisesMessage(AttributeError, msg):
s.dynamic_attr = True