> Maybe we could just alias and warn when using the old name, leaving a
decision on deprecation until some time in the future.

I'm a fan of delaying deprecation/removal if we do change it. :)

On Wed, Feb 21, 2018 at 4:41 PM, Josh Smeaton <josh.smea...@gmail.com>
wrote:

> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have
>> just got too used to mark_safe() being *the way* to insert HTML in a
>> template. And it’s easy for something that was safe when it was authored
>> (e.g. calling mark_safe() on a hard-coded string) to be copied /
>> repurposed / adapted into a case which is no longer be safe (e.g. that
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic
>> <https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ> 
>> suggested
>> making it more explicit that mark_safe() refers to being safe for use in
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>>     # Safe because we sanitize before trusting
>>     return dangerously_trust_html(bleach.clean(value))
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/05de4602-5c44-41bf-b675-
> ab15d69fb46d%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/05de4602-5c44-41bf-b675-ab15d69fb46d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7x0y07eY4uYO2cKCe4%2B8jo9x%3DrO0QA3EAbJvU1pmbJ5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to