Do we need an escaped version of unordered_list?

[Malcolm Tredinnick]

I'm doing a run through the admin interface, looking for non-escaping
problems.

One problem surfaced more or less immediately, though: the
"unordered_list" filter. Wrapping that in an escaped block or passing
the results through the "escape" filter obviously doesn't work. We
*want* the <li> elements to have meaning. However, {{ obj_bag|
unordered_list }} is error-prone if any of the model __str__ methods
returns strings containing characters that should be escaped.

Is there any alternative to creating an escaped_unordered_list tag? (Any
better name for this tag? It's too long)

[Note: useful responses to this question do not include "auto-escaping
would be nice". That is not the issue here and it gets tiring reading
it.]

Thanks,
Malcolm

[Gary Wilson]

Malcolm Tredinnick wrote:

> Is there any alternative to creating an escaped_unordered_list tag? (Any
> better name for this tag? It's too long)

How about {{ obj_bag|unordered_list:"escape" }} ?

[Simon Willison]

On 14 Jul 2006, at 03:05, Malcolm Tredinnick wrote:

> Is there any alternative to creating an escaped_unordered_list tag?
> (Any
> better name for this tag? It's too long)

Yes. Implementing the auto escape proposal.

> [Note: useful responses to this question do not include "auto-escaping
> would be nice". That is not the issue here and it gets tiring reading
> it.]

I would argue that it is the issue here - more specifically, the
current auto_escape proposal is designed to tackle this exact
problem, among others.

http://code.djangoproject.com/wiki/AutoEscaping

The solution lies with the way the proposal flags strings as escaped
or unescaped. The unordered_list tag would escape items passed in to
it based on the current state of the auto_escape flag combined with
whether or not the item was flagged as already having been escaped.

Output an unordered list with each item escaped:
{{ list_of_unsafe_strings|unordered_list }} - assumes default for
the current template is autoescape on

Output an ordered list where each item can contain HTML:
{% autoescape off %}
{{ list_of_unsafe_strings|unordered_list }}
{% endautoescape %}

Alternatively, if the fact that the items contain safe HTML is known
by the view:

c = Context({
'items': map(escapedstr, items)
})

And in the template:

{{ items|unordered_list }}

Because the items have all been flagged as escaped, the auto escaping
mechanism will skip them and the safe HTML will be rendered as required.

unordered_list was one of the use cases I was thinking about when I
drew up the proposal. I should probably update the wiki page to
reflect that.

[Malcolm Tredinnick]

On Fri, 2006-07-14 at 16:45 +0100, Simon Willison wrote:
> On 14 Jul 2006, at 03:05, Malcolm Tredinnick wrote:
>
> > Is there any alternative to creating an escaped_unordered_list tag?
> > (Any
> > better name for this tag? It's too long)
>
> Yes. Implementing the auto escape proposal.
>
> > [Note: useful responses to this question do not include "auto-escaping
> > would be nice". That is not the issue here and it gets tiring reading
> > it.]
>
> I would argue that it is the issue here - more specifically, the
> current auto_escape proposal is designed to tackle this exact
> problem, among others.

Simon,

Take it as given that I agree with your proposal. I've read it a number
of times, thought about it, think it's great. No arguments from me.

I considered this a separate issue from auto-escaping because we need
something *now* (admin has inadvertent security holes by default at the
moment) and I thought there wasn't a real consensus around your
proposal, so another response along these lines was not moving us any
further from "problem" to "solution".

However, in the process of checking the older threads before responding
this morning, I realised there was a fair consensus and the only real
sticking point was "on by default" or "off by default", which is not a
showstopper at the moment.

So, I've spent the afternoon implementing your proposal. I've ported
about two thirds of the filters and a few of the tags so far, adding
tests as I go. I'll stick the patch in a ticket when it's mostly done,
which should be later this evening (Sydney time).

Just posting this now in case you decided to get keen and start working
on this yourself this weekend. I'm not meaning to tread on any toes, but
I want to get some of these problems fixed and leaving it for "somebody
else" wasn't working.

Your response was basically saying stuff I already understood, but
thanks for the boot in the butt anyway; it annoyed me enough to get me
to work on the bigger problem.

Regards,
Malcolm