Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Stuart Cox
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 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 [hidden email].
To post to this group, send email to [hidden email].
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/e0005e9f-765f-42a9-9c78-323e702b6784%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Douglas Miranda
I think this can mislead the developers to think mark_safe solves it all.

The forums are full of answers with Use mark_safe; Use htmlfield|safe; 
 
Maybe Django should start warning about mark_safe on the logs, then change the behavior. (Or even deprecate and remove)

Things like this we tend to blame the users, but it's there for using and it says "SAFE".


On Sunday, January 28, 2018 at 1:14:27 PM UTC-3, 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 [hidden email].
To post to this group, send email to [hidden email].
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/c4da4fc8-6565-42d8-bb4a-d9a8601ae355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Josh Smeaton
In reply to this post by Stuart Cox
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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Collin Anderson-2
> 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 <[hidden email]> 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 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 [hidden email].
To post to this group, send email to [hidden email].
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.

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 [hidden email].
To post to this group, send email to [hidden email].
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 | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Florian Apolloner
In reply to this post by Josh Smeaton
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 [hidden email].
To post to this group, send email to [hidden email].
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/3d683e14-a2dd-4f17-8774-9ddd88558254%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Josh Smeaton
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 [hidden email].
To post to this group, send email to [hidden email].
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/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Tim Graham-2
I don't know that "dangerously_trust_html" is a better name. The argument is supposed to be a string that you know is trusted so there shouldn't be any danger involved. Naming something based on how it could be misused seems odd.

For me, mark_safe() is a fine name, but maybe that preference is from a knowledge of django.utils.safestring internals that most users don't have.

On Thursday, February 22, 2018 at 7:16:29 AM UTC-5, Josh Smeaton wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 [hidden email].
To post to this group, send email to [hidden email].
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/370611c1-2031-4c0b-9f56-4b2c482e1113%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Anthony King
In reply to this post by Josh Smeaton
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <[hidden email]> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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 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 [hidden email].
To post to this group, send email to [hidden email].
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/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Tom Forbes
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.

On 22 Feb 2018 13:10, "Anthony King" <[hidden email]> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <[hidden email]> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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 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 [hidden email].
To post to this group, send email to [hidden email].
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/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Adam Johnson-2
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <[hidden email]> wrote:
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <[hidden email]> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <[hidden email]> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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 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 [hidden email].
To post to this group, send email to [hidden email].
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/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Adam

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAMyDDM0uaiZ0%3DHfq%2BagUgGeCqM4nbu%2BRTkRbSM0cg1PursU_2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Douglas Miranda
Yes, people read mark_safe as MAKE_safe, I'm not sure yet, but I'm liking the idea of trust_html, I feel like more developers will understand what they're doing.

Maybe the docs could have more detailed notes about HTML inputs that you want to mark them safe, one thing is trust "<span>" another is trust "{{ post.content }}". Rich text editors play a big part of beginner devs, a lot of people start with Django and don't quite understand Python or Web Security yet, that's just reality.

Django it is not to blame, but I think that's a small change with big impact.


On Thursday, February 22, 2018 at 10:07:12 AM UTC-4, Adam Johnson wrote:
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">t...@...> wrote:
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">anthon...@...> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">josh.s...@...> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
Adam

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/ce94677d-b400-4429-882d-4495d58b6f61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Josh Smeaton
In reply to this post by Adam Johnson-2
Yes I'm not a fan of the dangerously... names either. I'm still somewhat wary of trust_html which is a verb and could still confuse users in a similar way (does the api make it trustworthy?). I think I'd prefer something more descriptive like trusted_html.

<div>{{ content|trusted_html }}</div>
vs
<div>{{ content|trust_html }}</div>

On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">t...@...> wrote:
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">anthon...@...> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">josh.s...@...> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="KDYmofQFAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
Adam

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/67822239-8e38-4723-9475-bd64cf81db50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Tom Forbes
You're right, trusted_html is a better name than trust_html. I think either is superior to mark_safe however.

Regarding deprecations, deprecating mark_safe will cause a lot of churn even if the migration path is as simple as a rename. We should keep the old alias around for a long time, but promote the new name wherever possible.

On 22 Feb 2018 20:46, "Josh Smeaton" <[hidden email]> wrote:
Yes I'm not a fan of the dangerously... names either. I'm still somewhat wary of trust_html which is a verb and could still confuse users in a similar way (does the api make it trustworthy?). I think I'd prefer something more descriptive like trusted_html.

<div>{{ content|trusted_html }}</div>
vs
<div>{{ content|trust_html }}</div>


On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <[hidden email]> wrote:
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <[hidden email]> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <[hidden email]> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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 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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].

--
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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].

--
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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].



--
Adam

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/67822239-8e38-4723-9475-bd64cf81db50%40googlegroups.com.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJM2o8oQjFDxp-wx5KuARxdO_6sW9aPZimKnUEyz5y4-Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Josh Smeaton
In reply to this post by Josh Smeaton
Or, since this isn't a template tag (facepalm) 

trusted_html(m.content)
trust_html(m.content) 

On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote:
Yes I'm not a fan of the dangerously... names either. I'm still somewhat wary of trust_html which is a verb and could still confuse users in a similar way (does the api make it trustworthy?). I think I'd prefer something more descriptive like trusted_html.

<div>{{ content|trusted_html }}</div>
vs
<div>{{ content|trust_html }}</div>

On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <[hidden email]> wrote:
What about just 'trust_html'? The dangerous part is quite context dependent (and a bit of mouth-full), but at the core you are trusting the HTML. Hopefully it follows that you should not trust html with user input that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <[hidden email]> wrote:
I entirely agree with renaming `mark_safe`. Though it's name is correct, it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be dangerous to trust the literal "<small>Some Content</small>", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <[hidden email]> wrote:
The concern isn't overusing an API. It's not understanding the proper use case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" meaning of the API. I'm just wary of enforcing users to change code when they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
Yeah, I am also worried about the churn for no gain in my eyes. If users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 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, <a href="https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ&#39;;return true;">this topic 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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFNZOJPfw9ybsHOcs%3D9nfORtEJJz9pzKvEM7bRA6BaYwHXW3pQ%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
Adam

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/f40dc93c-f3e3-43b7-96f0-c2f82685c88a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Florian Apolloner


On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
Or, since this isn't a template tag (facepalm) 

Which raises a perfectly valid point: If we were to change this, we will also need to come up with a new name for the "|safe"-filter.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/1aa8a64d-1bea-44d0-bfc0-3139e08ed039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Josh Smeaton
We could use the same name or just |trusted.

I'm not so concerned with the `safe` tag as it's already an adjective, but I would be ok with an alias for trusted also.

On Friday, 23 February 2018 08:24:50 UTC+11, Florian Apolloner wrote:


On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
Or, since this isn't a template tag (facepalm) 

Which raises a perfectly valid point: If we were to change this, we will also need to come up with a new name for the "|safe"-filter.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/f2a90aa8-87b8-476f-b72e-1b1c2e6fe4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Kamil
In reply to this post by Stuart Cox
The name "mark_safe" unnecessarily exposes an implementation detail. People who misunderstand this API probably have no idea how this "marking" happens, it would make sense to name this after the *effect* it achieves: "don't process / escape me, I've been sanitized somewhere else".
Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere", etc.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.