Allow namespaced reusable app urls as ROOT_URLCONF

[Vlastimil Zíma]

Hi,

I've tried to understand how to write an urls module for reusable app and I 
think I have it correctly:

# myapp.urls
app_name = 'myapp'
urlpatterns = [
url(r'^index/$', MyIndexView.as_view(), name='index'),
url(r'^form/$', MyFormView.as_view(), name='form'),
...
]


In code I use the reverses in form 'myapp:index' and 'myapp:form'. The 
problem is, that these urls may be the only one used by the Django project, 
hence I expected ROOT_URLCONF = 'myapp.urls' should work as well. But such 
shortcut ends up in "'myapp' is not a registered namespace" error. To avoid 
that, one needs to add another urls module only to include the 
`myapp.urls`, which seems unnecessary.

Is there a reason not to use namespace from root urlconf? Can we change 
that, i.e. make root resolver to load the app_name of the root urls? Did I 
missed something else?

Regards,
Vlastimil

-- 
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/784f0a1d-2677-4246-b713-23482c61c02b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow namespaced reusable app urls as ROOT_URLCONF

[Florian Apolloner]

Hi,

On Thursday, February 15, 2018 at 2:40:07 PM UTC+1, Vlastimil Zíma wrote:

> Is there a reason not to use namespace from root urlconf? Can we change 
> that, i.e. make root resolver to load the app_name of the root urls? Did I 
> missed something else?
>

I don't think there is any reason to not allow it. That said the usefulness 
seems kinda questionable to me (ie if you enable the admin you already have 
another app for the root urlconf). In that sense I'd say: patches welcome 
and there is nothing obvious speaking against merging them as long as they 
don't introduce performance issues.

Cheers,
Florian

-- 
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/f018ba7b-7bb6-43ce-8ec0-3cc02010c7e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow namespaced reusable app urls as ROOT_URLCONF

[Tim Graham]

The issue was raised some months ago in 
https://code.djangoproject.com/ticket/28413 and came to a similar 
conclusion. The resolution was to document the restriction.

On Thursday, February 15, 2018 at 10:57:54 AM UTC-5, Florian Apolloner 
wrote:
>
> Hi,
>
> On Thursday, February 15, 2018 at 2:40:07 PM UTC+1, Vlastimil Zíma wrote:
>
>> Is there a reason not to use namespace from root urlconf? Can we change 
>> that, i.e. make root resolver to load the app_name of the root urls? Did I 
>> missed something else?
>>
>
> I don't think there is any reason to not allow it. That said the 
> usefulness seems kinda questionable to me (ie if you enable the admin you 
> already have another app for the root urlconf). In that sense I'd say: 
> patches welcome and there is nothing obvious speaking against merging them 
> as long as they don't introduce performance issues.
>
> Cheers,
> Florian
>

-- 
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/e7ece3c7-f46d-40c5-b619-df3c991b8e61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.