Slobodan Blazeski <slobodan.blazeski@gmail.com> wrote:
+---------------
| "Alex Mizrahi" <udode...@users.sourceforge.net> wrote:
| > in one form or another.. people say it's cool to use continuations,
| > but they consume valuable server memory.
|
| Depends of the type of the continuations, in weblocks continuations
| are just a tool to mimic linear flow and are lighweight, seaside and
| UCW (is this true about ucw?) have a long lived continuations, that
| persists and could be serialized.
+---------------
But that still has the GC/timeout problem. How long do you store
such continuations before you decide that the user is never going
to invoke them? Conversely, if you time one out and abandon it,
what happens when the user comes back from running the kid to
the hospital to get said kid's knee sewn up and finally gets
around to clicking on the "Buy" button, and discovers there's
nothing in their shopping basket any more?
+---------------
| > what if we'll serialize continuation and
| > pass it to client, so client can give it us back?
|
| You mean to the web browser, pass the continuations as what ?
+---------------
As <input type="hidden" name="state" value="whatever"> in HTML forms.
That's what I do.
+---------------
| > it seems uber-cool, but it's a security breach -- it would be pretty
| > hard to check that user have not tampered serialized continuation
| > (or closure) to execute arbitrary code at server.
|
| Actually with current state of lisp, we have security through
| obscurity...
+---------------
What part of the adage "Security by obscurity is no security at all!"
is not clear?!?
You actually don't need any obscurity at all to get security with
client-side ["hidden" form data] serialized continuations. Just
include an HMAC (or other secure keyed hash) over the continuation
as part of the continuation's serialized value. That is quite
sufficient to prevent the user from altering the continuation
and attempting a replay attack that way.
For single-use continuations you will also need a global [to your
server] timestamp/ticket#/serial# to prevent multiple replays as well.
That must also be inside the secure keyed hash.
Finally, if you're afraid your users will try to "decompile" your
continuations and learn something about the server they shouldn't,
you can always encrypt the entire continuation. Just *don't* use
ECB mode!! AES/CTR-mode works well, if the counter includes a
timestamp/ticket#/serial# to make it globally unique. [And even
when encrypting, don't forget the secure keyed hash around the
whole thing...]
-Rob
p.s. And remember, always "encrypt THEN auth", not the other way
around [which is insecure, see any modern crypto text].
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607