XML_Feed_Parser and HTML security

On Wed, 16 Aug 2006 20:27:18 +0200, Martin Jansen wrote:

> On Wed Aug 16, 2006 at 11:3937AM -0400, Arnaud Limbourg
wrote:
>> What about filtering html and give methods to
access the raw input ?
>> 
>> It makes the package relatively safe to use and
different methods make 
>> it clear that it is the unfiltered content being
accessed without the 
>> need to see if a parameter is set to true or false.
> 
> This sounds like the best compromise to me.

I wonder why we should pollute the package, as in we should
keep the API
clean, I mean why not just document that the user has to do
the escaping
them self and provide example with HTML_Safe or so (users
are suckers for
doing a copy/paste from the examples ;))

Tho I suppose adding the security part to the project isn't
all that bad.

One idea would be to have 2 packages, feed_parser and
feed_parser_security, the latter is on top of the first one
and thus we
kinda have the raw/safe API and the user just instances the
package
depending on what they want but that of course isn't
optimal approach at
all 
Just brainfarting a bit =)

- Helgi

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 8/16/06, Helgi Þormar Þorbjörnsson <dufuzphp.net> wrote:
> On Wed, 16 Aug 2006 20:27:18 +0200, Martin Jansen
wrote:
>
> > On Wed Aug 16, 2006 at 11:3937AM -0400, Arnaud
Limbourg wrote:
> >> What about filtering html and give methods to
access the raw input ?
> >>
> >> It makes the package relatively safe to use
and different methods make
> >> it clear that it is the unfiltered content
being accessed without the
> >> need to see if a parameter is set to true or
false.
> >
> > This sounds like the best compromise to me.
>
> I wonder why we should pollute the package, as in we
should keep the API
> clean, I mean why not just document that the user has
to do the escaping
> them self and provide example with HTML_Safe or so
(users are suckers for
> doing a copy/paste from the examples ;))
>

I actually agree with this. For those who want feed parsing
without
HTML_Safe they have it. For those who do want it it's a
simple
addition. XML_Feed_Parser should parse feeds. Keeping things
simple
makes them that much easier to maintain and more reusable.

> Tho I suppose adding the security part to the project
isn't all that bad.
>
> One idea would be to have 2 packages, feed_parser and
> feed_parser_security, the latter is on top of the first
one and thus we
> kinda have the raw/safe API and the user just instances
the package
> depending on what they want but that of course isn't
optimal approach at
> all  Just
brainfarting a bit =)
>

Actually, I like this idea. Either include 2 classes, one
which
returns raw data dn one which filters (the filterer being
extended
from the raw one) or just include a sample
"safe" class in the docs
and/or examples.

-- 
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 8/16/06, Justin Patrin <papercranegmail.com> wrote:
> On 8/16/06, Helgi Þormar Þorbjörnsson <dufuzphp.net> wrote:
> > On Wed, 16 Aug 2006 20:27:18 +0200, Martin Jansen
wrote:
> >
> > > On Wed Aug 16, 2006 at 11:3937AM -0400,
Arnaud Limbourg wrote:
> > >> What about filtering html and give
methods to access the raw input ?
> > >>
> > >> It makes the package relatively safe to
use and different methods
make
> > >> it clear that it is the unfiltered
content being accessed without the
> > >> need to see if a parameter is set to true
or false.
> > >
> > > This sounds like the best compromise to me.
> >
> > I wonder why we should pollute the package, as in
we should keep the API
> > clean, I mean why not just document that the user
has to do the escaping
> > them self and provide example with HTML_Safe or so
(users are suckers
for
> > doing a copy/paste from the examples ;))
> >
>
> I actually agree with this. For those who want feed
parsing without
> HTML_Safe they have it. For those who do want it it's
a simple
> addition. XML_Feed_Parser should parse feeds. Keeping
things simple
> makes them that much easier to maintain and more
reusable.
>
> > Tho I suppose adding the security part to the
project isn't all that
bad.
> >
> > One idea would be to have 2 packages, feed_parser
and
> > feed_parser_security, the latter is on top of the
first one and thus we
> > kinda have the raw/safe API and the user just
instances the package
> > depending on what they want but that of course
isn't optimal approach at
> > all  Just
brainfarting a bit =)
> >
>
> Actually, I like this idea. Either include 2 classes,
one which
> returns raw data dn one which filters (the filterer
being extended
> from the raw one) or just include a sample
"safe" class in the docs
> and/or examples.
>
Actually have a sample Safe class in the docs would be the
same thing as
telling the user to use HTML_Safe, most wouldn't and would
complain anyhow.

I do not agree on putting a small class aside that would
extend, although
what we could do is a flag in the package.xml that states
that this
package's output should be escaped:
<installMSG>Output Should be escaped using
HTML_Safe</installMSG>

Then when installing:
rootserependity:/home/david# pear install
PEAR_Package-alpha
downloading PEAR_Package-0.0.1.tgz ...
Starting to download PEAR_Package-0.0.1.tgz (8,358 bytes)
......done: 8,358 bytes
Info: Output should be escaped using HTML_Safe
install ok: channel://pear.php.net/PEAR_Package-0.0.1


But yes, that would involve adding some stuff to the pear
installer, and
more xml parsing, maybe it's a little too overhead but for
long term I
believe that this could be a cool way of doing stuff. Even a
tag <safeHTML/>
that would output the message automatically.

So the Info message and the docs should give the users an
idea that this is
important .. I guess they would understand but again.. i am
not everyone