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 "" 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 > 
> 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" > 
>> 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 "Some Content", 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 > > 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 

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, 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-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/c4da4fc8-6565-42d8-bb4a-d9a8601ae355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Behavior of ModelAdmin.fieldsets with 'classes': ('collapse',) when fieldset name is None.

[Douglas Miranda]

Hello, I don't know if this was debated before, but I think the behavior of 
Collapsed fieldsets 

 
on Django Admin could confuse some devs. Here is the example:

Consider the django.contrib.auth.admin.UserAdmin.fieldsets 

.

If I add 'classes': ('collapse',) to field option

fieldsets = (
# ...
(_('Personal info'), {'classes': ('collapse',), 'fields': ('first_name', 
'last_name', 'email')}),
# ...
)




As you can see the fieldset name is _('Personal info'), so everything is as 
expected *Personal Info (Show)*. 

But I can create fieldsets without fieldset name, like this:

fieldsets
 
= (
(None, {'classes': ('collapse',), 'fields': ('first_name', 'last_name', 
'email')}),
)

And the result would be:




Almost the same, but if you look here 

 
you'll see Django won't render the *h2 block* if there's no *fieldset.name*, 
and if you look here 
,
 
this javascript code looks for the *h2* tag to add the "Show" link to 
collapsed fieldsets.


So that's it, If someone creates a collapsible fieldset without fieldset 
name, Django just doesn't show the fieldset at all.

It's not something difficult to fix, but I would like to hear from you guys.

* If you agree that it needs to be fixed, just showing the *(Show)* link, 
would suffice?

* Or warn the user about using collapse class without a fieldset name?

-- 
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/c014e145-edf3-4639-8112-801c365e7ce3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.