I second what Luke and Russ have already said. If what you're interested in is a way to securely allow users to enter template code into the database, you can just write a custom field that validates its input for security problems.
Here's a third-party implementation of a validator for such a field: https://github.com/ithinksw/philo/blob/master/philo/validators.py#L106 This particular implementation: - lets you explicitly allow particular tags (in which case all other tags are disallowed for the field) - lets you explicitly disallow particular tags (in which case all other tags are allowed for the field) - disallows the load, extends, include, and debug template tags by default, but lets the backend developer specify the field as "insecure" if they want to. My point being - if what you want is to let people specify template code in database fields, there are ways to make it secure without rewriting the template engine. On Nov 16, 4:04 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Nov 16, 2011 at 5:12 PM, Roald <downa...@gmail.com> wrote: > > Hi all, > > > Can anybody explain why template tag libraries are loaded from > > *inside* a template? The more I work with them, the more I get the > > feeling that specifying which template tags are available in a > > template should be specified in the view-code (or more general: the > > thing that loads/renders the template). Why would I, as a back-end > > developer, make *all* of my template tags available to the front-end > > developer in *all* templates? > > I'm afraid I don't follow how it would make sense for template tags to > be loaded anywhere *except* inside a template. > > * The view constructs the context data that is to be available for rendering. > > * The template determines how that context data will be rendered. > > * A template tag is a block of functionality that can be used to > manipulate the display of data. > > The decision to use a particular template tag is entirely a front-end > decision. True, it might require some coordination with backend > developers to provide specific functionality (e.g., writing a specific > data transformation, or writing a tag to extract specific data), but I > fail to see how that division of labor suggests that the decision to > make a template tag available at all should be controlled by the > backend developer. > > > A great benefit of moving the template tag library loading to code, > > would be that the template language could also be safely used in > > CharFields/TextFields, without the risk of users using unwanted > > template tags. > > If I'm understanding this correctly, your use case here is putting > template content into a CharField or TextField, but you don't want to > be subjected to injection-style attacks from on user content. This > strikes me as a pretty obscure edge case to drive the design of the > template language. > > > Of course, for backward compatibility, this can't be changed. The > > thing I'm most interested in, though, is restricting the template tag > > libraries that can be used in a template from my view-code. This can > > be done in a backward compatible way. > > As with Luke, count me as a -1 on this. Luke's final paragraph sums up > the situation nicely, IMHO: > > if your use case is "allow end users to use the template > system safely", this feature wouldn't come close to doing that. > If your use case is "stop front-end developers deliberately doing > naughty things", I'd say the solution can't be a technical one. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
