On Fri, 18 Jan 2019 at 01:15, Marco Pivetta <ocram...@gmail.com> wrote:
> On Fri, Jan 18, 2019 at 2:13 AM Marcos Passos <marcospassos....@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]
