On Sun, 5 Sep 2004 15:33:28 -0400, Jason Garber <[EMAIL PROTECTED]> wrote: > This is an interesting point you bring up. When we have large > registration processes or similar multi-page forms, we write our > data array to a hidden field using. > > base64_encode(serialize($aData)) > > and read it in with > > unserialize(base64_decode($_POST['aData'])) > > passing it from page to page with POST.
That's another scenario, and perhaps quite a common one, I hadn't thought of. I guess in this case, as the serialized string was originally generated by your code, you could attach a checksum with it to spot alteration but validating classes against a list would be easier. Checksums only really works though when your PHP script is doing all the serializing; not an option when a remote, untrusted, system will be doing the serializing. > If I understand you correctly, someone could alter the content of > the serialized array so that it would load a class upon > unserialization? Exactly. > If you are auto-loading classes, this might be > even worse. Good point - hadn't considered that. > > That being the case, I would be much in favor of an optional second > array parameter to unserialize that would be a list of accepted > classes, or an empty array to that would (obviously) allow no > classes (if you were working with simple data types). > > mixed unserialize ( string str[, array classes]) There may be an issue with returned value, come to think of it. Right now unserialize returns FALSE (plus triggers and error) if it was unable to parse the serialized string. Might be a requirement to be able to identify invalid syntax from attempts to load an invalid class (another callback or an exception?). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
