cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] FOM
Date Tue, 27 May 2003 16:33:34 GMT
on 5/27/03 2:33 AM Bertrand Delacretaz wrote:

> <snips cause="agree or dont't understand implications enough to talk"/>
> Le Mardi, 27 mai 2003, à 08:44 Europe/Zurich, Stefano Mazzocchi a écrit  
> :
>>... 2) design for safety: the flow will be a center of abuse because  
>>will find it easier to write longer flows than to restructure their
>>business logic into components. We must make all possible efforts to
>>reduce this from happening....
> +1.
> This is very important so that Flow does not become the next JSP or ASP  
> ;-)
>>... Object getComponent(id) -> obtains the component indicated by the  
>>given ID...
> Does this mean *any* Component, or do you foresee a way for Components  
> to say if they're made available in the FOM or not? Making everything  
> accessible might also lead to easy abuse IMHO.

This is another concern entirely. We are currently focusing on the FOM,
that is, on the contracts between the two layers.

Obviously, the flow will not have access to *all* components, but only
to components that will be "flow-available".

How this is implemented is to be discussed later.

>>...NOTE: both Ricardo and I believe that the flow should always be
>>associated with a Session. Thus the use of the semantics "getSession"
>>instead of "createSession"...
> I like that, but isn't there a possible attack where a client makes a  
> lot of requests without cookies/session IDs, and overflows the poor  
> server who's creating millions of Sessions without asking anything  
> first?

the same could be said for continuations or for any other
client-initiated server-side memory occupation.

> Is that taken care of somewhere else already?

No. if you use a while(true) {} loop with sendPageAndWait() in the
middle, you are creating a continuation for every failed login action.
This is a potential DoS attack but it could be super-easy to avoid
looping from more than n times from the same IP address.

But you do have a point: if sessions are created transparently, you
can't act before the session is created.

Hmmm, other comments on this?

> Why no isDebugEnabled etc?

Ah, another good point. Yeah, we need those. Consider them added.

> Without this it is not possible to add lots of logging without worrying  
> about runtime costs.
> Good logging improves quality, I think these properties are needed


View raw message