Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63139
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocGs=5-JfpSSewDRaNC0KaoNF1okBD8-E27fx5U=9f6sgw@mail.gmail.com>
References: <CAO1hux8mmUsy4badiNjxTGMubaduD1gkgbw4ZK1Me_MwGwLybA@mail.gmail.com>
	<CALtuQzC4e2Sn_BHinFAPdVrz8Oc_d6wCqTr=AscMChH29NSENw@mail.gmail.com>
	<CAO1hux9+4QK2sVX9+4110ksa9qDpUpfDhFJvyzkXcBHrFoFWvg@mail.gmail.com>
	<0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com>
	<CAO1hux9t9refYHYnKhY0725MvRm88ab85Ng23LCvnjDJxqQA7g@mail.gmail.com>
	<CALwr1GnjjjMbK8-VkVO57meDAgDn8PSPoWdj2DjYMB7F01dP4Q@mail.gmail.com>
	<CAPwsocGs=5-JfpSSewDRaNC0KaoNF1okBD8-E27fx5U=9f6sgw@mail.gmail.com>
Date: Wed, 19 Sep 2012 16:20:01 +0100
Message-ID: <CALwr1G=wVFRnkjaQXLxDthbvJfkV77oUgN6CY4hNinEkoexL=g@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
From: padraic.brady@gmail.com (=?ISO-8859-1?Q?P=E1draic_Brady?=)

Hi Leigh,

On Wed, Sep 19, 2012 at 3:10 PM, Leigh <leight@gmail.com> wrote:
>>> I missed the encoding parameter. While it's still possible to add that
>>> to a static-only class, that would be more cumbersome and less correct
>>> than instantiation (since the encoding is state, technically). My
>>> apologies. Carry on ;-)
>
> It's probably already been covered, but I don't like the fact that
> it's a class at all.
>
> There's nothing wrong with an ini value to start with (defaulting to X
> if it is unrecofnised), then ini_set() to change the value at runtime
> if required, and finally implementing everything as normal functions
> that accept an override encoding as an optional parameter for those
> one-off cases.

First off, bear in mind that the class is a preferred implementation
that does not preclude the implementation of similar functions. As a
class it just eases usage for those who are OOP obsessed ;). I work on
Zend Framework and we already pass around a similar object.

Secondly, the problem with a php.ini option or a default function
parameter value is that it ignores the prevailing best practice of
always specifying a character encoding explicitly. htmlspecialchars()
is a perfect example here. Many uses will not specify an explicit
encoding so we find applications with UTF-8 or other encodings for
their output performing escaping to ISO-8859 in PHP 5.3. Please,
search Github for htmlspecialchars - I'm not exaggerating. Now search
for the same thing in any large framework and you'll never see this
because those either followed best practice or already attracted a
security report about it.

Explicitly requiring the parameter just follows recommended practice.

Now, let's consider adding it to php.ini. This follows the exact same
reasoning as programmers will develop to their platform in ignorance
of any others. It's just another assumed default that needs to be
tweaked anyway - and probably will be only rarely.

The point here is to eliminate opportunities to do this wrong and
simplify doing it correctly. Flexibility for flexibility's sake
doesn't actually solve an existing poor practice - it simply gives it
a new life extension. Programmers need to know that character encoding
selection is intrinsic to escaping. How many programmers will be
stranded by PHP's switch to UTF-8 because they actually did use
ISO-8859 output encoding? How many are stranded with UTF-8 escaping
from PHP 5.4 while not using that encoding? Being explicit may be
perceived as a PITA per function call but its necessary to eliminate
unpredictability in the backend.

> It feels like this is just using classes for the sake of using
> classes, adding an unnecessary layer of complexity (and discussion)
> for no real reason except that is the RFC authors preference.

Anything any class can do, could be done procedurally. That doesn't
mean it is. Many programmers use objects, dependency injection and all
that other stuff. Adding the class simplifies usage in an OOP setting
and ideally helps remove the barrier of having to rewrap functions
into a class for those who do practice OOP regularly. So, yes,
obviously it's a preference but not an unnecessary layer of complexity
since it actually simplifies overall usage in the OO setting.

Paddy

--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team