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 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/e0005e9f-765f-42a9-9c78-323e702b6784%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Add slicing notation to F expressions

[askpriyansh]

Hello !

There is a new feature-request in ticket #29049, and some related work has been 
done in PR #9583 (https://github.com/django/django/pull/9583).

Does this require the implementation of the slicing operator using backend 
functions Left, Right and Substring ?

Regards
Priyansh

-- 
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/ce15691c-2baf-42a6-9acc-40da8e331042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add slicing notation to F expressions

[Adam Johnson]

Actually there was some further discussion in
https://groups.google.com/forum/#!msg/django-developers/PsHDk1doTDg/CewZdVMJAQAJ
where we settled that the slicing operator need not be implemented in the
scope of that ticket.

On 28 January 2018 at 17:09,  wrote:

> Hello !
>
> There is a new feature-request in ticket #29049, and some related work has
> been done in PR #9583 (https://github.com/django/django/pull/9583).
>
> Does this require the implementation of the slicing operator using backend
> functions Left, Right and Substring ?
>
> Regards
> Priyansh
>
> --
> 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/ce15691c-2baf-42a6-9acc-
> 40da8e331042%40googlegroups.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 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/CAMyDDM0YgNn%2BXdXY3FK4dOc9FnVBixA9XgcYY%3DBaLJ5DDYdzRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #29066

[Adam Johnson]

It's generally best to leave questions like this on the PR than in a
separate mailing list thread. I'll answer there (
https://github.com/django/django/pull/9627 ).

On 27 January 2018 at 07:02,  wrote:

> Hello everyone !
>
> I have two queries with respect to the ticket #29066
> .
>
> 1. Do we need to provide an __neg__ operator for the Sum class, or its
> superclass Aggregate class ? Going by the description in the ticket, the
> operator should probably support all aggregates.
> 2. Should there be tests for this ? The flag is not set, but I think there
> should be.
>
> Regards
> Priyansh
>
> --
> 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/d6cdd454-d0c7-42b9-81a2-
> fdaccdf2490d%40googlegroups.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 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/CAMyDDM0VZGaJRa-0Pkk-b2pOxAvJR90Q1qPDV5_Wsfo5M-ZNSw%40mail.gmail.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.