RE: [Flow] getComponent(id) implementation
Reinhard Pötz wrote: The Cocoon object of the FOM has the method Component getComponent(id) It should return any component but no sitemap components. This means we only return components defined in the roles file(s). How can we check if it is an allowed component? Any ideas? I think the simplest solution is to use the correct component manager that holds only the components configured in roles/cocoon.xconf. This is the component manager of the o.a.c.Cocoon object. Each sitemap as its own component manager for the sitemap component, they are linked in a hierarchy to the above mentioned one. Carsten
Re: [Flow] getComponent(id) implementation
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
The Cocoon object of the FOM has the method
Component getComponent(id)
It should return any component but no sitemap components. This means we
only return components defined in the roles file(s). How can we check if
it is an allowed component?
Any ideas?
I think the simplest solution is to use the correct component manager that holds only the components configured in roles/cocoon.xconf. This is the component manager of the o.a.c.Cocoon object.
Each sitemap as its own component manager for the sitemap component, they are linked in a hierarchy to the above mentioned one.
Sorry if I missed something (was offline for several days -- lots of
emails to read), but why is it necessary to make a distinction between
sitemap components and other components ?
What could be the possible use of e.g. a transformer in a flowscript ? I
can't see one... So why build complicated fences to prevent something
that is IMO doesn't even make sense ?
Furthermore, and this is what triggered this answer, restricting
getComponent() to the top-level CM goes strongly against the upcoming
blocks and the fact that map:components is nothing but a regular
.xconf declaration.
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
RE: [Flow] getComponent(id) implementation
At 05:27 AM 6/27/2003, Carsten wrote: Reinhard Pötz wrote: The Cocoon object of the FOM has the method Component getComponent(id) It should return any component but no sitemap components. This means we only return components defined in the roles file(s). How can we check if it is an allowed component? Any ideas? I think the simplest solution is to use the correct component manager that holds only the components configured in roles/cocoon.xconf. This is the component manager of the o.a.c.Cocoon object. Each sitemap as its own component manager for the sitemap component, they are linked in a hierarchy to the above mentioned one. 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. Geoff
RE: [Flow] getComponent(id) implementation
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. Carsten
Re: [Flow] getComponent(id) implementation
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).
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
Re: [Flow] getComponent(id) implementation
on 6/27/03 4:47 AM Sylvain Wallez wrote: Carsten Ziegeler wrote: Reinhard Pötz wrote: The Cocoon object of the FOM has the method Component getComponent(id) It should return any component but no sitemap components. This means we only return components defined in the roles file(s). How can we check if it is an allowed component? Any ideas? I think the simplest solution is to use the correct component manager that holds only the components configured in roles/cocoon.xconf. This is the component manager of the o.a.c.Cocoon object. Each sitemap as its own component manager for the sitemap component, they are linked in a hierarchy to the above mentioned one. Sorry if I missed something (was offline for several days -- lots of emails to read), but why is it necessary to make a distinction between sitemap components and other components ? What could be the possible use of e.g. a transformer in a flowscript? None. That's exactly why we don't want you to try to figure out one ;-) I can't see one... So why build complicated fences to prevent something that is IMO doesn't even make sense ? Because our users are creative abusers. Furthermore, and this is what triggered this answer, restricting getComponent() to the top-level CM goes strongly against the upcoming blocks and the fact that map:components is nothing but a regular ..xconf declaration. Careful. FOM describes a contract basically: you ask for component with the given ID and you get it. How? this is another concern and the flow writer doesn't care. When real blocks will be there, the implementation of the FOM getComponent() method will have to change. Back-compatibly, that is. But I wouldn't worry for this right now. I also have another suggestion: use the higher component manager but just check if the returned component implements SitemapModelComponent and if so return null or raise an exception. Slower to reject calls for invalid components, but takes map:components into consideration. What do you think? -- Stefano.
Re: [Flow] getComponent(id) implementation
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? 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. Geoff
Re: [Flow] getComponent(id) implementation
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
