Re: XML_Feed_Parser and HTML security
| From: | David Coallier | Date: | Thu, 17 Aug 2006 00:52:47 +0000 |
| Subject: | Re: XML_Feed_Parser and HTML security | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-43723@lists.php.net to get a copy of this message | ||
On 8/16/06, Justin Patrin <papercrane@gmail.com> wrote:
On 8/16/06, Helgi Þormar Þorbjörnsson <dufuz@php.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
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 forThis sounds like the best compromise to me.it clear that it is the unfiltered content being accessed without the need to see if a parameter is set to true or false.
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 astelling 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: root@serependity:/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 :-)