Alexander Klimetschek wrote: > On Thu, Jul 30, 2009 at 3:05 PM, Ian Boston<i...@tfd.co.uk> wrote: >> I might be missing the point, but, >> I think this is a generic problem not just limited to this area, if I can >> create a node and set sling:resourceType=something/nasty, *and* upload an >> arbitrary script to somewhere that is resoled to by "something/nasty" , then >> I can do the same in 2 steps ? >> >> IIRC, there is some work in progress to limit how scripts are loaded, but it >> may not extend as far as protecting the location. > > You are right, I forgot about that issue. So basically one has to make > sure anonymous or "public" users (ie. through self-registration) > cannot set resource types (which would require an ACL on the > sling:resourceType/sling:superResourceType properties, which isn't > possible with JCR 1.0 or 2.0) or simply has only write-access to > locations that are not part of the script resolution search path. Current trunk uses a configurable script admin user to read scripts from the configured search paths. So by making these trees only writeable (and maybe readable) for the script admin should prevent the average user from adding scripts to the system.
> >> also... how does a script resolve *outside* /apps ? > > You can use an absolute path... at least in Java servlets with the > sling.servlet.paths SCR property. Not sure if this applies to > sling:resourceType as well. Yes, you can mount a Java servlet (must be a proper OSGi service) to any resource path. Then you can invoke this servlet by accesing this path. For example if you mount the servlet to "/no/one/knows/this/path", you can call this servlet from the browser by exactly that path. Maybe this is something we should reconsider and forbid? But scripts for rendering are always only searched under the configured search paths. There is no way around it. Carsten > >>> :name and :nameHint are not enough? >> yes, for names like /content/new/a_file_that_was_hinted >> >> but not so good for >> >> /content/new/a/file/that/was/hinted >> where the name is a path, perhaps derived from the post. > > Yes, this use case must be handled on the client side (eg. Javascript > in browsers), to set the path before the post. > > Regards, > Alex > -- Carsten Ziegeler cziege...@apache.org
