i like the idea of having a __html__ __str__-like function a lot, especially
for string/html representation of database objects. is this something that
would be compatible with django's design principles?
for implementation, here's a suggestion of which i'm not sure if it works:
one could defin
On 4/18/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> I can also see a solution which would maintain backwards compatibility
> for old sites:
> TEMPLATE_AUTOESCAPE=False in conf.global_settings
> TEMPLATE_AUTOESCAPE=True in conf.project_template.settings
I'd be against this; any solution which has
Hi Malcolm,
Malcolm Tredinnick wrote:
> On Wed, 2007-04-18 at 08:58 +, SmileyChris wrote:
> [...]
>> I actually like Malcom's proposal. Can't say I'd be thrilled if it was
>> on by default though.
>
> Since this is actually a good idea, we should give credit where it's
> due: the whole theor
On Apr 19, 1:36 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Since this is actually a good idea, we should give credit where it's
> due: the whole theory behind this (and most of the details) is Simon
> Willison's creation. I just wrote the code and polished off some of the
> less smooth co
On Wed, 2007-04-18 at 08:58 +, SmileyChris wrote:
[...]
> I actually like Malcom's proposal. Can't say I'd be thrilled if it was
> on by default though.
Since this is actually a good idea, we should give credit where it's
due: the whole theory behind this (and most of the details) is Simon
Wi
Thinking about it more, I wouldn't actually be against Malcom's
autoescaping solution being on by default - I do see the importance of
solid XSS protection!
I can also see a solution which would maintain backwards compatibility
for old sites:
TEMPLATE_AUTOESCAPE=False in conf.global_settings
TEMP
Hoi,
Another small notice. Pylons and other frameworks thought about
implementing "__html__" for objects that return an html representation
of the object. If there is none it's converted to unicode and escaped.
Adding something like "__html__ = lambda s: s" to the escaped string
base classes coul
Hi Chris,
On Wed, Apr 18, SmileyChris wrote:
>
> On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > In the past threads, we basically had consensus anyway, I'm not sure
> > that revisiting everything again is worth the hassle.
>
> Without trying to rock the boat... reading
On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> In the past threads, we basically had consensus anyway, I'm not sure
> that revisiting everything again is worth the hassle.
Without trying to rock the boat... reading back, I'm not sure there
was a resounding consensus.
I actua
On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Unfortunately, the AutoEscapingAlternative page uses strawmen to try and
> make its arguments.
Ok, it's less "controversial" now.
--~--~-~--~~~---~--~~
You received this message because you are su
On Tue, 2007-04-17 at 20:35 -0700, Simon G. wrote:
> Sorry - I just skim read the discussions on it in "AutoEscape" and
> "AutoEscaping Alternative" where that was mentioned. Wasn't making any
> value judgements :-)
Unfortunately, the AutoEscapingAlternative page uses strawmen to try and
make its
Sorry - I just skim read the discussions on it in "AutoEscape" and
"AutoEscaping Alternative" where that was mentioned. Wasn't making any
value judgements :-)
--Simon
On Apr 18, 2:49 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2007-04-17 at 05:00 -0700, Simon G. wrote:
>
> If you
On Tue, 2007-04-17 at 09:08 -0400, Ned Batchelder wrote:
> I've been following this discussion with interest. XSS fragility is a
> real weak point for text-based templating engines, and we need to find a
> solution.
>
> On the topic of HTML-escaping vs. general escaping: Absolutely the
> reas
On Tue, 2007-04-17 at 05:00 -0700, Simon G. wrote:
> This is one of those issues which is never going to please everyone.
>
> So - I've started a list of the various proposals (1), and could you
> all add any other proposals to this page, along with any pros/cons,
> and vote on the one(s) you pre
On Tue, Apr 17, Tom Tobin wrote:
> I think you misunderstood me; I'm not saying there should be a
> general-output escaping framework. I'm saying that if there *is* an
> HTML escaping framework, the object/variable naming should make it
> clear that we're dealing with HTML-specific escaping wher
On 4/17/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> >
> > I'm still -1 on autoescaping as implemented in the latest patch in
> > #2359; the terminology used is strongly HTML-centric (e.g.,
> > ``convert_to_words.is_safe`` -- safe from what?). We should be using
> > naming that makes it expli
I've been following this discussion with interest. XSS fragility is a
real weak point for text-based templating engines, and we need to find a
solution.
On the topic of HTML-escaping vs. general escaping: Absolutely the
reason to do auto-escaping is to make it dead easy to avoid XSS
problems
This is one of those issues which is never going to please everyone.
So - I've started a list of the various proposals (1), and could you
all add any other proposals to this page, along with any pros/cons,
and vote on the one(s) you prefer.
This way we can get some idea of what a consensus view
Hi Tom,
On Mon, Apr 16, Tom Tobin wrote:
> I haven't been participating much on Django-dev over the last few
> months, but this made me go "eep?".
>
> I'm still -1 on autoescaping as implemented in the latest patch in
> #2359; the terminology used is strongly HTML-centric (e.g.,
> ``convert_to_
On 4/16/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> Short and sweet: since we're already planning some
> backwards-incompatible changes for the next release, how about we
> hammer out auto-escaping of template output while we're at it? Even
> those of us who don't like it (myself included) ar
Hi,
On Apr 16, 1:08 pm, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Armin, you're coming a bit late to this discussion. We had a few quite
> extensive threads months ago. If you seriously want to engage in this
> discussion, please read what's been written before. I understand that you
> cannot
On Mon, Apr 16, Armin Ronacher wrote:
>
> Hoi,
>
> -sys.maxint for autoescaping. I added support for that into jinja
> quite a while ago and it was pain in the ass. It makes things more
> complicated (speaking for return values and arguments of filters) and
> it blows up the implementation. Not
On Mon, 2007-04-16 at 03:08 -0700, Armin Ronacher wrote:
> Hoi,
>
> -sys.maxint for autoescaping. I added support for that into jinja
> quite a while ago and it was pain in the ass. It makes things more
> complicated (speaking for return values and arguments of filters) and
> it blows up the impl
Hoi,
-sys.maxint for autoescaping. I added support for that into jinja
quite a while ago and it was pain in the ass. It makes things more
complicated (speaking for return values and arguments of filters) and
it blows up the implementation. Not worth the work.
Regards,
Armin
--~--~-~--~
On Mon, 2007-04-16 at 09:04 +0200, Michael Radziej wrote:
> Hi,
>
> Malcolm Tredinnick wrote:
> > What do you see as the currently undecided issues? We seemed to have
> > quite a good consensus after the innumerable earlier threads and the
> > implementation I wrote has been kept up to date by Mi
Hi,
Malcolm Tredinnick wrote:
> What do you see as the currently undecided issues? We seemed to have
> quite a good consensus after the innumerable earlier threads and the
> implementation I wrote has been kept up to date by Michael Radziej
> (except for the admin portion, which I can update to n
On 4/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On or off by default seemed to be the only debate (and it's not really a
> debate -- Adrian didn't like it).
I don't *like* it, but I've come around to accepting that it's better
for us not to point the gun at a developer's foot and say
On Mon, 2007-04-16 at 00:54 -0500, James Bennett wrote:
> Short and sweet: since we're already planning some
> backwards-incompatible changes for the next release, how about we
> hammer out auto-escaping of template output while we're at it? Even
> those of us who don't like it (myself included) a
Short and sweet: since we're already planning some
backwards-incompatible changes for the next release, how about we
hammer out auto-escaping of template output while we're at it? Even
those of us who don't like it (myself included) are probably at the
point of accepting that we have to do it even
29 matches
Mail list logo
