Quiet voice from the peanut gallery: If (IF) there were to be some generic filter behaviour, wouldn't it make sense to give the existing filtering-type functions some intelligence about whether that generic filter was enabled or not, and ensure that those functions were always fed raw superglobals data? Making the generic filter a backup that jumps in where no protection exists, rather than an 'ipso facto, will break stuff' kinda deal?
It doesn't make a lot of sense from where I'm standing to have a generic security setup that _isn't_ default, but it really shouldn't break BC in any way. Just my 2 sheks, - Steph ----- Original Message ----- From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Derick Rethans" <[EMAIL PROTECTED]> Cc: "Ilia Alshanetsky" <[EMAIL PROTECTED]>; <internals@lists.php.net> Sent: Thursday, February 03, 2005 2:51 AM Subject: Re: [PHP-DEV] PHP 5.1 > At 01:44 PM 2/2/2005 -0800, Rasmus Lerdorf wrote: > >You guys can write your own implementation and put it in PECL alongside > >the one I am putting in there and we can decide if any of them should be > >bundled by default. Perhaps none of them should, but like it or not, > >people want to filter at this level and the extension to satisfy this need > >will be available to them in PECL. > > It'd be great if we can all sync on one implementation. > I know it gets a bit hard with everyone pulling their way and having yet > another suggestion but I'm sure we can reach something everyone is happy with. > In any case, the main part of this project are the filters themselves ,and > that work shouldn't be replicated. > I must say that personally I probably would prefer a programmatic way of > filtering (as I mentioned it could be done at runtime), but I don't think > it would be terrible to have a paranoid mode that filters earlier. > So just to lay out my $0.02 it'd be nice to have something like: > filter_all(POST, FILTER_FOOBAR); > and > $foo = filter_input(POST, "foo", FILTER_NUM); > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
