intended security model for templates

[Tim Graham]

I was hoping to get clarification on what security model we intend to support for template authors. In ticket #12772 it's proposed to allow loading template tags using a dotted Python path. This would allow template authors to trigger imports of anything on the Python path. I am not sure the requirement to add a template tag library to INSTALLED_APPS is a big burden these days (e.g. there is no more need to create an empty models.py file), but perhaps I don't fully understand the ticket's rationale for proposing these changes.

[Curtis Maloney]

Personally I feel it's exposing too much implementation to the template authors.

Whilst I can understand the appeal of allowing namespacing of template libs, I think exposing full python paths is the wrong approach.  Perhaps allowing a "app_label:libname" approach to being more specific?

--

Curtis

On 25 December 2014 at 05:35, Tim Graham <timog...@gmail.com> wrote:

I was hoping to get clarification on what security model we intend to support for template authors. In ticket #12772 it's proposed to allow loading template tags using a dotted Python path. This would allow template authors to trigger imports of anything on the Python path. I am not sure the requirement to add a template tag library to INSTALLED_APPS is a big burden these days (e.g. there is no more need to create an empty models.py file), but perhaps I don't fully understand the ticket's rationale for proposing these changes.

--
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 django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/643fdee1-dbc2-4113-b564-aa2fd741a0ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

On Thursday, December 25, 2014 5:24:05 AM UTC+1, Curtis Maloney wrote:

Whilst I can understand the appeal of allowing namespacing of template libs, I think exposing full python paths is the wrong approach.  Perhaps allowing a "app_label:libname" approach to being more specific?

+1, and even without namespacing one can do app_libname currently, so I don't really see a problem there.

[Shai Berger]

On Wednesday 24 December 2014 20:35:09 Tim Graham wrote:
> I was hoping to get clarification on what security model we intend to
> support for template authors. In ticket #12772

> <https://code.djangoproject.com/ticket/12772> it's proposed to allow

> loading template tags using a dotted Python path. This would allow template
> authors to trigger imports of anything on the Python path. I am not sure
> the requirement to add a template tag library to INSTALLED_APPS is a big
> burden these days (e.g. there is no more need to create an empty models.py
> file), but perhaps I don't fully understand the ticket's rationale for
> proposing these changes.

In addition to what Curtis and Florian said, the ticket was made before the
default-project-layout change that made project-apps common; since Django 1.4
(or was it 1.3?) those have been a natural place for "common tags [to] be kept
together".

Reading also the ticket, I agree with Carl's argument that the libraries
available for loading should be explicitly controlled from Python code. In
fact, this point makes me wonder if it wouldn't be better (ignoring backwards
compatibility, of course) to require custom tags to be passed in through the
context ("project-global" custom tags could then be added in a context-
processor).

Shai.

[Curtis Maloney]

I certainly like the idea of making public the API to load your tag lib by default for your project.  It's there, it's clean, and it's been stable for a looong time.  Of course, the multi-template-engine work may change this.

Also, I agree that "explicit is better than implicit", and thus reducing the number of places Django "discovers" things, instead of being instructed where to look, is probably a good idea.

--

Curtis

[Carl Meyer]

Hi Tim,

On 12/24/2014 01:35 PM, Tim Graham wrote:
> I was hoping to get clarification on what security model we intend to
> support for template authors. In ticket #12772

> <https://code.djangoproject.com/ticket/12772> it's proposed to allow

> loading template tags using a dotted Python path. This would allow template
> authors to trigger imports of anything on the Python path. I am not sure
> the requirement to add a template tag library to INSTALLED_APPS is a big
> burden these days (e.g. there is no more need to create an empty models.py
> file), but perhaps I don't fully understand the ticket's rationale for
> proposing these changes.

I don't believe that we should claim that the DTL is secure against
untrusted template authors (I don't think it is, though I haven't taken
time to really investigate), but I also don't believe we should merge
the proposed patch from #12772, for the other reasons I mentioned in a
comment on the ticket.

Carl

[Collin Anderson]

I also think the "load your tag lib by default for your project" is a good idea. It's a tad magical, but very nice.

[Aymeric Augustin]

2014-12-29 0:26 GMT+01:00 Curtis Maloney <cur...@acommoncreative.com>:

I certainly like the idea of making public the API to load your tag lib by default for your project.  It's there, it's clean, and it's been stable for a looong time.  Of course, the multi-template-engine work may change this.

It doesn't.

Template tags / filters libraries are still global per-project. In this regard they behave just like Python modules. They're registered / imported once and then available for everyone.

--

Aymeric.