<nagler+blackhole@bivio.biz> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) wrote:
| > I take it you didn't bother to read the *rest* of my reponse?
| 
| I did, but don't see how it relates to versioning.  I understand
| your position that HMAC is secure in detecting changes on the
| client side.  Just don't see how that helps with server side changes.
| Specifically, how do you distinguish when an incoming request can
| no longer be satisfied by the resident lexical context?
+---------------

(*sigh*) I thought it was clear, but I'll try again. Quoting myself:

    Finally, an HMAC neatly handles the versioning problem: simply
    change the HMAC key when the version changes, and previous closure
    states will no longer validate!

*Only* the server ever has the HMAC key(s)! All you have to do
is pair HMAC keys with versions, and when you change versions on
the server change the key [on the server]. Changing the HMAC key
automatically invalidates any previous lexical contexts saved on
the client.

To be even more explicit: When constructing an HTTP response containing
the lexical context for a closure, perform an HMAC over the closure
context using the current server-side key, which is associated with
the current version of both the closure's function code and the code
*around* the closure in which the continuation will run. Send the
result of that HMAC as part of the HTTP response along with the
closure context [and the rest of the response page, forms, menus,
text boxes, etc.]. If/When the client uses a form on that response
page to make a further request, *both* the lexical context and the
HMAC will be submitted back to the server [along with the rest of
the request, including any variable data supplied by the user].
When the server gets the new request, once again compute an HMAC
over the lexical context in the request, using the key *NOW CURRENT*
on the server. Compare the result to the HMAC sent from the client.
If they match, then (1) the client hasn't tampered with the closure
context and (2) the closure context is still of the proper version.
Create an enviroment containing the closure context and call the
closure function to handle the request. [If no match, return a
"session expired" error page (or equiv.).]

Capsiche?


-Rob

p.s. If you want to get really fancy, you can save a sliding
window of acceptable previous closure code versions along with
their keys, and try matching previous keys with HMACs of submitted
client data. If there are too many acceptable previous versions,
this may become somewhat expensive in CPU time, since for each
request received by the server it will have to completely recompute
the HMAC once for each previous still-valid version, but it might
prove helpful to at least have the option in some situations.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607