Carsten Ziegeler wrote:
Geoff Howard wrote: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().
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.
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
