#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
---------------------------+---------------------------------------------
Changes (by Aymeric Augustin <aymeric.augustin@…>):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"6d52f6f8e688b5c4e70be8352eb02c05fea60e85"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d52f6f8e688b5c4e70be8352eb02c05fea60e85"
 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.
 }}}

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

Reply via email to