I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good way to go (although I'd change the function name but that's no biggy, filter_input?). I very much see how filter_input(POST, "email", FILTER_EMAIL) is easier as opposed to finding the right regex for emails and it's great re-use.
Yeah, I really don't care what the name of the function is. Wanted to try to keep it somewhat short since it might need to be typed a lot.
As far as the INI is concerned, that's probably much more complicated because it would probably have to be on a per-script basis. Did you want to finalize that also for 5.1? What's your thinking on what it would look like? Or where you just thinking of a more general filter that will globally get rid of certain things like XSS, quotes, etc.?
I don't actually see it as a per-script thing. Obviously the ini would be per-dir Apache configurable, but I see this as being something set across the board on a dedicated server that defines the security policy of that server. Shared servers are most likely not going to be able to settle on a single security policy so they would either only enable it for certain vhosts or leave it off altogether. As someone suggested, if the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or something to that effect then an individual script could in one shot filter all GET data even if the default ini filter wasn't in place. The main reason for the default ini filter is to be able to deploy code other people have written and be somewhat safer without having to go through each line of the application trying to figure out where to filter stuff. If you just filter everything flowing into the application you have added a decent amount of safety to untrusted code. It may very well break the code, but this is a saner starting point. This way you track down stuff that doesn't work and think about which filter to apply in each situation as opposed to starting from a wide open position and reading through all the code looking for places to restrict things.
-Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
