cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Continuations and the web
Date Mon, 24 Nov 2003 15:55:50 GMT

On 23 Nov 2003, at 21:16, Tony Collen wrote:

> There's a few interesting posts going on over at [1] regarding the use 
> of continuations on web.

Continuations break the back button? bah.

> I tried to set one of the people commenting straight on how it works 
> in Cocoon, but they seems to be convinced it's being done all wrong.  
> I think it's just due to their lack of understanding about exactly how 
> Cocoon works.
>
> In particular, post [2] is the most interesting (and ranty).

The guy has only one point there: a continuation ID is not fully RESTy. 
Agreed, it's not.

The only way to make this *really* REST-y is to pass the continuation 
(not the ID, the *ENTIRE* continuation) along with the response. This 
would allow complete replicability of the continuation.

But this is also a big security issue as the client has control on the 
state and could forge it.

I thought about this and I think it's possible to do a light form of 
encryption over the continuation so that the user can't forge it. The 
only required thing would be the same encryption key on the server 
side.

At the same time, requiring continuations to be serializable is a 
problem and moves the problem in another domain, doesn't really solve 
it.

> Then again, that post is the author's opinion.  The nice thing about 
> the web is that there's no one "right way" to do anything.

The rest of what he says shows just how blind he is: a sitemap is just 
a decoupling layer. if you want to implement URL -> object direct 
mapping you can. nothing stops you from doing it.

> I would be interested in investigating the whole "URL as accessing an 
> object or an object's methods" idea though... much how Zope works.

big security danger: object injection and you are fucked. this is why I 
think you always need a decoupling layer, either from URL -> file or 
URL -> object.

--
Stefano.

Mime
View raw message