> Regarding doing a "security audit", assuming you had some method of
> defining the default escaping (if any) it would seem easier and safer
> to audit if you were looking for cases where you didn't need to escape
> (the more rare case). But this is getting back to the main auto-escape
> discussion.
It is definitly a good idea to have an application that is secure by
default. But when a template author comes and puts a variable
replacement code in the middle of his HTML code, it is assumed that he
knows exactly what he is doing. This is not insecure by default, it is
insecure because the template author made it insecure.
It don't think that template authors should come and put variable
replacements all over the place then security auditing will come after
them and add all the escapes. When security auditing comes, tempalte
authors should have already put escape filters all over the template
and a variable replacement without an escape is what should stand out.
> So if DRY *is* a major priority then say I am writing an project that I
> know will be outputting to HTML 99% of the time. Having to turn on
> escaping on every template (or worse, every tag!) seems quite a
> "repetitious" task.
> I guess then it becomes an argument between DRY vs Explicitness. So is
> explicit > DRY?
This might well be subject to personal taste. In general, Python is all
for explicitness, and so is Django.
Also note that DRY does tell you that it is wrong to repeat the same
code ten times in your application and that you should wrap it all up
in a common function. But it doesn't tell you that it is wrong to
*call* that function ten times. This is not un-DRY.
But then again, having to remember to escape each and every variable
does seem like a problem that is can be solved with DRY, so... I don't
know.
> [...] I would be happy if you could just specify your {% escape
> html %} block (in whatever format it ends up in) in your base template
> as opposed to doing it in every single template.
The problem here is that the base and extending templates are not
always managed by the same person.
Consider the case of the admin templates for example. Sometimes you
just want to create your own base template to change the general theme,
but you want to leave the remaining admin templates unchanged. Now if
you apply autoescaping to your base template, all the extending admin
templates will become broken and need to be changed to work properly.
This also applies to larger scopes, like when you download several
applications from the Internet, each with their own default set of
templates, you put them in a single project and you make them all
extend a common template that provides the basic functionality for your
site. Now if some of them are designed to work with autoescaping "on"
and others are designed for autoescaping turned "off", there won't be a
correct elegant solution to the problem.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
