On Tue, 2007-10-09 at 14:11 -0400, Andrew Ballard wrote: > On 10/9/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > > Certainly you'll notice I've extended the original class, > > overriden the __wakeup() call and basically used inheritance > > and polymorphism to my advantage. > > Noticed. :-) I said a *little* more difficult. Of course, I could > declare the class final, but then that ends any chance at inheritance. > > > I would argue that this kind of tampering isn't worth checking for on > > every unserialize. > > I haven't done much with PHP objects (other than built-in objects), > and can't recall a case where I've used serialize/unserialize for > anything other than to inspect variables before functions like > var_dump during development. In that case, your example concerns me > more with what other developers might try to do to circumvent > protections built into an object. It's a good argument for not storing > objects in anything persistent, like session variables, though, since > those are serialized/unserialized on every page and often stored in > the physical file system. > > Honestly, it all seems a bit extreme. At some point, you have to trust > the people you work with not to go to such lengths to violate an > objects contract -- which I guess goes back to Tony's point whether > the language "enforces" private members/functions or whether they are > simply regarded that way by the developers using them. I would prefer > both, honestly. :) If you're really worried about tampering of serialized data, store the SHA1 code for the serialized data and validate before unserializing. Cheers, Rob. -- ........................................................... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ........................................................... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
