On Tue, 2007-10-09 at 16:18 -0400, Robert Cummings wrote: > 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. In retrospect that doesn't really help if someone has access to both :) 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