Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EFCA25E.1040607@anyware-tech.com>
Date: Fri, 27 Jun 2003 22:00:30 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [Flow] getComponent(id) implementation
References: <LKENJPKDAIKAPKHEOCMMAEEAEBAA.cziegeler@s-und-n.de>
 <LKENJPKDAIKAPKHEOCMMAEEAEBAA.cziegeler@s-und-n.de>
 <5.2.0.9.0.20030627131856.0297bac0@leverageweb.com>
In-Reply-To: <5.2.0.9.0.20030627131856.0297bac0@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Geoff Howard wrote:

> At 12:27 PM 6/27/2003, Sylvain wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Geoff Howard wrote:
>>>
>>>> Do we want to force people to edit cocoon.xconf to call their own 
>>>> business
>>>> components from the flow?  I thought Stefano proposed checking for
>>>> SitemapModelComponent and disallowing it?  Would that prevent 
>>>> looking up
>>>> a transformer, but allow looking up a legitimate component defined in
>>>> map:components?
>>>>
>>>> I'm still wanting to enable people (me!) to reuse action _code_ 
>>>> (not the
>>>> contract) with little re-coding of the original class file where not
>>>> necessary.  If that can't be done in a clean way that doesn't 
>>>> invite abuse
>>>> then so be it, but I think it's worth trying for.
>>>
>>> I just listed the solution without saying if I prefer it or not; 
>>> basically
>>> I don't know which is the best, but I tend to agree with Sylvain that
>>> we should not build up a unnecessary wall. Ok, we could sheck for
>>> SitemapModelComponent but I'm not sure if this is required.
>>>
>> SitemapModelComponent cannot help here, since those components 
>> (generators and transformers, but not serializers) are managed by a 
>> ComponentSelector. And this is this selector that will be looked up 
>> through getComponent().
>>
>> So the only way to forbid access to pipeline components (but again, 
>> does it really make senses to use them in the flow ?) is to forbid 
>> access to their selectors, through their respective roles 
>> (GeneratorSelector, TransformerSelector, etc).
>
>
> Aha - I dug into this the other night in looking into how you'd get a 
> sitemap component from the flow and had forgotten.  So how about 
> denying access to the selectors for everything except actions?  Are 
> the components from map:components available as normal through their 
> roles if we do that?


Yes, this is the solution : allow lookup of components only if they're 
not in the "forbidden" list.

> I guess the same answer there would apply to the global "variables" 
> declared in the sitemap?
>
> BTW, the point as I understand it in restricting access to those 
> generators et al is to protect against abuse of people trying to 
> assemble pipelines from the flow. 


Wow ! I really don't understand why someone would like to do that, when 
calling a "cocoon:" pipeline defined by the sitemap is sooo easy. 
Furthermore, it is currently possible to do it with Java code in e.g. 
actions, and I never heard of someone crazy enough to do assemble 
manually his own pipeline.

Anyway...

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com