Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103767
MIME-Version: 1.0
References: <CANA3Det3Cn2LAzcFPmVpP+ApgdtwDYrcnwuys8Gdo6CzRxLqBg@mail.gmail.com>
 <CADyq6sKt8XxXOoqFYTjphBQ7Fgg7SFmZdexaDFq2-AfxX-zURg@mail.gmail.com>
 <CANA3DevZK4F2_Vk3PD8aDdMzS1t=L6x4C7xL88Y1AY8p8A2P2w@mail.gmail.com>
 <CADyq6sL2LyguyXawskdCE9XyQmtTq7vRqN+sZ6eDrrh6Rvdb1g@mail.gmail.com>
 <CANA3DeuYoxbnjm4BsgvmTQnDx2isqbbfHOFTe7R8-DqHmiFU=A@mail.gmail.com>
 <CADyq6s+RoQSGh5=NUDPMwATbqcJcZT9uPkNsrCTUgyMQOu2qeQ@mail.gmail.com>
 <CANA3DetvqF9HPkp-iK=z0LJ7a0yh7O9aM0R7XxARe=XTBUgrWQ@mail.gmail.com> <CADyq6s+i1F_nKquVq6AiSmjPzikdVkrWunroPZW=kigXmmZuBw@mail.gmail.com>
In-Reply-To: <CADyq6s+i1F_nKquVq6AiSmjPzikdVkrWunroPZW=kigXmmZuBw@mail.gmail.com>
Date: Fri, 18 Jan 2019 14:30:53 +0000
Message-ID: <CALKiJKoyk+GuzEC6aosi1VN2dxh9Nna3HFUS5Z2m+5dSgEN2dA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Marcos Passos <marcospassos.com@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000068db09057fbc5c8f"
Subject: Re: [PHP-DEV] Unserializes, inheritance and allows_classes
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000068db09057fbc5c8f
Content-Type: text/plain; charset="UTF-8"

On Fri, 18 Jan 2019 at 01:15, Marco Pivetta <ocramius@gmail.com> wrote:

> On Fri, Jan 18, 2019 at 2:13 AM Marcos Passos <marcospassos.com@gmail.com>
> wrote:
> > But it closes for extension preventing the serialization of instances not
> > whitelisted. It may work for @internal or package private classes, but
> not
> > for public classes.
> >
>
> That is precisely what this is designed for.
>
> A subclass is a different type, with a world of possible broken things in
> it: do not consider the subclass to be the same as a parent class: it's a
> logical mistake.
>


I think it depends on the scenario, and what risks you're trying to protect
against. If you are using the whitelist in the core of a CMS, to stop
plugins accidentally introducing problematic behaviour, sub-classes should
absolutely be blocked; but if you're using it in a closed application to
stop users manipulating the *serialized data*, there is no way for a
sub-class to be created unless you create it yourself, so limiting to any
class in a given hierarchy would be reasonable.

However, you can always implement more complex logic by using custom
serialization and deserializing with a factory which creates whichever
sub-class is appropriate. Although fairly powerful, serialize() /
deserialize() are always going to be a bit of a "lowest common
denominator", rather than the right tool for every job.

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000068db09057fbc5c8f--