[Seaside] Memory leak?

[Stephen Pair]

Avi Bryant wrote:

> Is it WAResponse or WARequest that you have a lot of? 

WAResponse

> Nah, people use tabbed browsers or cloned browser windows all 
> the time. There's no good way to predict when a user still 
> has access to a url and when they don't.

Some people do that all the time, most people do not.  And, it may be
the desirable thing to do for certain applications.  If a user clones a
browser, backtracks, uses a link, then goes to the clone and tries to
use a link there, a reasonable response in that situation is to inform
them that the link they used is no longer valid and to redirect them to
a current view of their session.  What Seaside currently does is also
valid. 

> > P.S.  Implementing security on top of Seaside has been a dream!  
> > Seaside basically has a built in capability framework.  
> Consider that 
> > when you hit a seaside component, the only thing a user can 
> do is use 
> > the links that have been exposed to him/her on that page.  
> These are 
> > the "keys" to the capabilities you've granted your user.  
> All you need 
> > to add to the equation is a framework (like ACLs) to guard 
> Seaside's 
> > keys.
> 
> Guard the keys in which way?

Well, that depends on your application.  But, I've been experimenting
with this a little bit.  I've been trying to overlay the old Swiki.net
security model onto Seaside and here's my current line of thinking:

Components in my application are created on a Model (they have a model
inst var).  I call my WAComponent subclass a "ChPresenter" (terminology
that I had used in the old Swiki.net implementation).  The old
presenters map fairly well to Seasides components.  When you attempt to
create a component on a model, an authorization check is performed.
Abstractly, the component just asks the model whether it is allowed to
be opened on it.  It is up to the model to decide whether authorization
is granted and how to check for authorization.

In my case, if for example a user clicked a link to edit a Swiki page,
we would call (in the Seaside sense) a ChPageEditor (which is a subclass
of ChPresenter) on the page.  The page would then validate that the
current user has authorization to edit the page.  If the authorization
succeeds, then the user is presented with the edit component (which
exposes all of the capabilities that the edit component embodies).  One
way to look at Seaside's WAComponent is as a capability specification.

There are more details that I'm leaving out (such as having abstract
notions of authorization requirements and a relative ording of different
authorization levels), but that's the gist of it. 

- Stephen