#23831: mark_safe and mark_for_escaping should account for __html__
---------------------------+---------------------------------------------
     Reporter:  aaugustin  |                    Owner:  aaugustin
         Type:  Bug        |                   Status:  closed
    Component:  Utilities  |                  Version:  1.7
     Severity:  Normal     |               Resolution:  fixed
     Keywords:             |             Triage Stage:  Ready for checkin
    Has patch:  1          |      Needs documentation:  0
  Needs tests:  0          |  Patch needs improvement:  0
Easy pickings:  0          |                    UI/UX:  0
---------------------------+---------------------------------------------

Comment (by Aymeric Augustin <aymeric.augustin@…>):

 In [changeset:"3483682749577b4b5a8141a766489d5b460e30e9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3483682749577b4b5a8141a766489d5b460e30e9"
 [1.7.x] 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.

 Backport of 6d52f6f from master.
 }}}

--
Ticket URL: <https://code.djangoproject.com/ticket/23831#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.1bbe68fe6004aeebbabace4fe64ba70e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to