On 6/20/02 1:21 AM, "Sylvain Wallez" <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote: > >> On 6/18/02 7:59 AM, "Sylvain Wallez" <[EMAIL PROTECTED]> >> wrote: >> >> Your assumption is that the flow scripts are visible to all the >> applications. I don't think this is reasonable. Just think of an ISP who >> deploys Cocoon, people running their Web app want to be isolated from >> everybody else. How can we achieve this if we describe flow scripts as >> components, inheritable in all the Cocoon blocks that implement user apps? >> > > You seem to have misunderstood what I meant about visibility : a flow > isn't globally visible, but could be visible - just as other components > - in the sitemap that declared it and all its subsitemaps. If an ISP > wants to hide a particular flow, then this flow should be declared in an > ISP-private subsitemap of the main sitemap. > > This "hide on a branch" strategy is the one used by Tomcat classloaders > to hide the servlet engine classes from the webapp classes, and it works > quite well. > > Note that the same visibility problems currently applies to components > we already have : if an ISP-private datasource or a sensitive action is > declared in cocoon.xconf or the main subsitemap, they are globally > visible. Declaring them in a subsitemap hides them from other sitemap > branches. I see, it makes sense. But I still don't see why flow scripts declared in a parent sitemap should be visible to children. I believe a flow script is essentially part of a self-contained application, and there is no reason to have that visible to children sitemaps. >> But it doesn't prevent other flow scripts deployed in the same Cocoon >> instance to reverse engineer scripts deployed by somebody else (think of the >> ISP scenario). > > Sorry, I don't understand what you mean here. Is this related to > filesystem access ? At least in JavaScript, if you have access to a Scriptable object, the object that contains the internal representation of a script, you can ask it to decompile itself. Thus you get access to the source code of the flow, which may be a security problem. Best regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
