Safe settings context processor
SmileyChris
declared that a settings context processor was not going to happen. The
reason being that it could give template authors direct access to the
db password / secret key.
Recently I coded up
http://code.djangoproject.com/wiki/SafeSettingsContextProcessor, which
uses the same get_safe_settings which the debug error page shows.
Is this still too dangerous? As long as it's off by default, isn't it
safe enough?
On a side note, most people just want access to media_url, so I
actually would be happy with just
http://code.djangoproject.com/ticket/2532. Every web site wanting to
use static CSS will need to access this variable somehow, won't they?
Otherwise it has to be hard coded and that's not very Djangoish...
Ivan Sagalaev
> On a side note, most people just want access to media_url, so I
> actually would be happy with just
> http://code.djangoproject.com/ticket/2532. Every web site wanting to
> use static CSS will need to access this variable somehow, won't they?
No, I asked my two sites and they don't want this :-). Because I use
MEDIA_URL to store user files but my js and css have absolutely nothing
to do there. They live under their subversioned dirs and have thier own
STYLE_URL and JS_URL settings.
I tend to agree with Adrian that putting some settings into some default
context processor won't really help in many custom cases but will
introduce a problem of polluting template's namespace. This will lead to
people trying to have all the data in their templates and trying to do
logic there omitting views. And then we'll get another PHP written in
Django's template language (not to hit PHP but Django just have
different style).
SmileyChris
to a bit too much pollution.
But Ivan, you need to access the STYLE_URL setting. Having access to
settings via SafeSettings could be useful still, right?
Bryan Chow
to access settings in virtually all of my templates. Specifically, I
use this code [1] to access SITE_URL and MEDIA_URL so that my
templates can build absolute links within my sites.
However, I don't believe that this functionality needs to be Django
proper. It would be nice, but you don't *need* this to make a Django
project work. But if you do want to access settings. Seriously. Make
your own library. Stick your custom template context processor in it.
And import your library in all your projects. Simple.
Bryan :)
[1] http://www.verdjn.com/browser/verdjnlib/context_processors
Ivan Sagalaev
> But Ivan, you need to access the STYLE_URL setting. Having access to
> settings via SafeSettings could be useful still, right?
Not much. Adding couple of needed settings in my own project's context
processor (which I already have anyway) is not a big deal. SafeSettings
then has some questionable gains bu also some questionable danger: it
filters out only settings with 'SECRET' and 'PASSWORD' in its name but
there can be settings that should be kept hidden that don't contain
these words (and vice versa). To my personal taste this is not enough
ground to recommend it as default behavior.