As I said, over the years I've done both, and this is what I've
settled on as the most practical.
Then you should have learned by now that verifying your
data's integrity is a mandatory task when designing any
client-side session system. Otherwise, attackers can inject
any kind o
Hello Markus,
I've done both many times. There are many ways to do this type of
thing, but the way I described it is very clean because the data is
always in sync with the page (due to the fact that the data is on
the page).
If you save the data to a session, and then click back a coup
Jason Garber 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']))
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))
>
>
Hello Harry,
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']))
pa
Hi All,
Have a situation where I want to unserialize a string received from an
untrusted source over HTTP (a Javascript client in this case). For
basic types this is no concern but when it comes to objects, would be
nice to be able to restrict the class of object to a member of a known
list, to pr
