#31203: Using Markup in ValidationError
---------------------------------+--------------------------------------
Reporter: Felipe | Owner: (none)
Type: Bug | Status: new
Component: Error reporting | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Description changed by Felipe:
Old description:
> Not 100% positive this is a bug, but definitely a breaking change in
> Django.
>
> In 1.11 ValidationError used force_text to stringify its messages, but in
> 2.2 and 3.0, it's using str.
>
> force_text used to check for subtypes of six.text_type and let those
> through unchanged, whereas str forces the __str__ conversion.
>
> This interacts poorly with Markup, which 'unwraps' itself in the __str__
> method. Here's a sample problem:
>
> {{{
> type(next(iter(ValidationError(
> message=Markup('%(x)s had a problem'),
> params={'x': Markup('<span>X</span>')}
> )))) is str
> }}}
>
>
> That error should render on a form as a span followed by some text;
> however, the use of str causes the 'safeness' of the markup to be lost
> and thus it's re-escaped and the HTML leaks into the page.
>
> Maybe Markup should be returning self in __str__, since it's a __str__
> subclass. This bug can be worked around from client code using something
> like this:
>
> {{{
> class StubbornMarkup(Markup):
> def __str__(self):
> return self
>
> type(next(iter(ValidationError(
> message=StubbornMarkup('%(x)s had a problem'),
> params={'x': Markup('<span>X</span>')}
> )))) is StubbornMarkup
> }}}
>
>
> This is vaguely related to #13723, which seems to suggest the use of
> Markup should be supported.
New description:
Not 100% positive this is a bug, but definitely a breaking change in
Django.
In 1.11 `ValidationError` used `force_text` to stringify its messages, but
in 2.2 and 3.0, it's using `str`.
`force_text` used to check for subtypes of `six.text_type` and let those
through unchanged, whereas str forces the `__str__` conversion.
This interacts poorly with Markup, which 'unwraps' itself in the `__str__`
method. Here's a sample problem:
{{{
type(next(iter(ValidationError(
message=Markup('%(x)s had a problem'),
params={'x': Markup('<span>X</span>')}
)))) is str
}}}
That error should render on a form as a span followed by some text;
however, the use of str causes the 'safeness' of the markup to be lost and
thus it's re-escaped and the HTML leaks into the page.
Maybe Markup should be returning self in `__str__`, since it's a `__str__`
subclass. This bug can be worked around from client code using something
like this:
{{{
class StubbornMarkup(Markup):
def __str__(self):
return self
type(next(iter(ValidationError(
message=StubbornMarkup('%(x)s had a problem'),
params={'x': Markup('<span>X</span>')}
)))) is StubbornMarkup
}}}
This is vaguely related to #13723, which seems to suggest the use of
Markup should be supported.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31203#comment:1>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.892901fd5a9e7f7d54308c5adb2b8cc5%40djangoproject.com.
