Re: request data filter

It looks like a mess indeed, and there seems a thought that encoding conversion and variable registration should be separated into two phases. However doing so doesn't make sense because some of multibyte characters contains "[", "]", or "=" and they cannot be handled properly in the ordinary query parser. Therefore Rasmus's sugestion sounds quite logical to me. Moriyoshi On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote: > In trying to implement a security policy I need to pass all user-supplied > data (GET/POST/Cookie) through a filter function which implements this > security. This isn't all that hard to implement as an extension through > new 4.3 treat_data and post_handler hooks, however it gets messy when you > throw mbstring into the mix as that extension also uses those hooks. > > The cleanest way I can think of doing this is to add a function pointer to > SAPI for the filtering function that will be run right before the > php_register_variable_safe() call. Currently we are always calling > php_url_decode() on the data before registering the variable, so I propose > that we make php_url_decode() the default that an extension can then > override. > > Anybody see any reason not to make this simple change? Without that I > will need to somehow detect whether mbstring is present and then filter > the data after it has already been registered by mbstring's > treat_data/post_handler hooks. That's a big mess! > > -Rasmus > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > >