On Wed, Sep 19, 2012 at 9:25 PM, David Muir <davidkm...@gmail.com> wrote: > On 20/09/12 07:48, Michael Shadle wrote: >> >> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady <padraic.br...@gmail.com> >> wrote: >>> >>> Hi Michael, >>> >>> See the link near the bottom of the RFC - even htmlspecialchars() has >>> unusual behaviour that's potentially insecure. I have no objections to >>> there being functions, of course, and the RFC makes that clear. >>> However, many programmers like me are obsessed are objects so having >>> an SPL class will obviously be near and dear to my design patterned >>> heart ;). >> >> After looking over the RFC finally, would it be that crazy to consider >> this an extension of the standard string functions? >> >> str_escape($string, $encoding, $flags) or probably better >> str_escape($string, $flags, $encoding) - since encoding could be >> defaulted to UTF-8, but flags are really what differentiate the >> behavior... >> >> Then there is not a handful of functions but rather one that can be >> used as the abstraction point and the flags passed to it will change >> it's behavior, much like the filter functions. >> >> (I just see this falling under one solid defacto escape function >> standard, and it could live by itself as "escape" or something, or as >> it operates on strings, prefix it as such) >> > I'm on the fence with a default encoding. I tend to always use UTF-8, so > would probably just use the default. But that means I become less aware of > encoding being central to the issue, and therefore much easier to > accidentally leave it as UTF-8 when it should be something else. > > -1 on the flag based api, though. Would much rather have dedicated > functions. It's easier to read, and less verbose. > > <!-- str_escape with flags --> > <?php $enc = getMyEncoding();?> > <table title="<?=str_escape($foo, ESCAPE_HTML_ATTRIBUTE, $enc)?>"> > <tr> > <td><?=str_escape($foo, ESCAPE_HTML, $enc)?></td> > <td><?=str_escape($bar, ESCAPE_HTML, $enc)?></td> > </tr> > </table> > > > <!-- dedicated escaping functions --> > <?php $enc = getMyEncoding();?> > <table title="<?=escape_html_attribute($foo, $enc)?>"> > <tr> > <td><?=escape_html($foo, $enc)?></td> > <td><?=escape_html($bar, $enc)?></td> > </tr> > </table> > > > <!-- OOP style --> > <?php $e = new Escaper(getMyEncoding())?> > <table title="<?=$e->escapeHtmlAttr($someTitle)?>"> > <tr> > <td><?=$e->escapeHtml($foo)?></td> > <td><?=$e->escapeHtml($bar)?></td> > </tr> > </table> > > I prefer the OO API since it's succinct, but if we are to have a procedural > API as well, lets make it concise and clear. The last thing we want for > solving the no 1 security threat to web-apps is a confusing and hard-to-use > API like the filter extension. > > Cheers, > David > +1 to most of what you said.
I will disagree on the filter extension. Its main problems are lack of publicity and functions with similar names that don't do what you would expect (Consider `is_int`). I use FILTER_VALIDATE_BOOLEAN and FILTER_VALIDATE_INT on a regular basis, and have used other filters. I will agree it's API could have been better, but it is not confusing in my opinion. I do want to make it clear that I support a simple, clean API if we do implement more escaping functions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
