direct execution of scripts

[Tobias Bocanegra <to...@day.com>]

hi,
i remember a discussion about allowing direct script execution (a
request to /foo/my.jsp executes the script instead of delivering the
content).

while this might by funny (and sometimes useful) it is especially a
problem when .js files are handled by rhino. so a request to my
"/docroot/my.js" executes it on the server instead of delivering it to
the client.

i strongly believe that executing directly addressed scripts should be
prohibited.

regards, toby

ps: if this is really needed, it could be done using a mixin node type
to mark the file/resource as executable.eg: sling:executable

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: direct execution of scripts

[Bertrand Delacretaz <bd...@apache.org>]

On Jan 28, 2008 9:18 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...Am Montag, den 28.01.2008, 09:12 +0100 schrieb Bertrand Delacretaz:

> >... Adding some kind of "executable bit" info to the Resource metadata
> > would solve this...

> ...Still, this is probably not enough because, there needs to be a way to
> detect whether to send the source or call the script on a per-request
> basis (mainly in the WebDAV use case)....

Agreed, we might need both mechanisms but I don't think we need the
executable bit thing now, just wanted to mention it.

-Bertrand

Re: direct execution of scripts

[Felix Meschberger <fm...@gmail.com>]

Hi Bertrand,

Am Montag, den 28.01.2008, 09:12 +0100 schrieb Bertrand Delacretaz:
> On Jan 28, 2008 12:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
> 
> > Am Sonntag, den 27.01.2008, 00:53 +0100 schrieb Tobias Bocanegra:
> 
> > >... ps: if this is really needed, it could be done using a mixin node type
> > > to mark the file/resource as executable.eg: sling:executable
> >
> > This of course would not work, as mixin node types are not reflected in
> > the Resource interface and servlet resolution acts in the realm of
> > Resources and does not care about the implementation of the Resource....
> 
> Adding some kind of "executable bit" info to the Resource metadata
> would solve this if we need that info at the Resource resolving level.

Yes, this could solve the issue I had with supporting the
"mix:executable" mixin proposed by Toby: The JcrNodeResource
implementation could set that flag in the metadata as could the
BundleResourceProvider and ServletProvider.

Still, this is probably not enough because, there needs to be a way to
detect whether to send the source or call the script on a per-request
basis (mainly in the WebDAV use case).

Regards
Felix

Re: direct execution of scripts

[Bertrand Delacretaz <bd...@apache.org>]

On Jan 28, 2008 12:00 AM, Felix Meschberger <fm...@gmail.com> wrote:

> Am Sonntag, den 27.01.2008, 00:53 +0100 schrieb Tobias Bocanegra:

> >... ps: if this is really needed, it could be done using a mixin node type
> > to mark the file/resource as executable.eg: sling:executable
>
> This of course would not work, as mixin node types are not reflected in
> the Resource interface and servlet resolution acts in the realm of
> Resources and does not care about the implementation of the Resource....

Adding some kind of "executable bit" info to the Resource metadata
would solve this if we need that info at the Resource resolving level.

-Bertrand

Re: direct execution of scripts

[Felix Meschberger <fm...@gmail.com>]

Am Sonntag, den 27.01.2008, 00:53 +0100 schrieb Tobias Bocanegra:
> hi,
> i remember a discussion about allowing direct script execution (a
> request to /foo/my.jsp executes the script instead of delivering the
> content).
> 
> while this might by funny (and sometimes useful) 

Well, it is not funny, it may be very usefull, for example for general
administration stuff.

> it is especially a
> problem when .js files are handled by rhino. so a request to my
> "/docroot/my.js" executes it on the server instead of delivering it to
> the client.

This is really a problem, which may not be easily solved. OTOH how is a
developer supposed to distinguish between client and server side
JavaScript files if both have the .js extension ?

> 
> i strongly believe that executing directly addressed scripts should be
> prohibited.

Definitely not ! It is a very usefull and in some cases very important
use case and we will neither prohibit nor switch it off. But we will
probably change the way, how it works.

The reason to do this is, that we also have a collision when trying to
support WebDAV in Sling. We might limit execution of directly addressed
scripts to requests which have an extension, such that requesting for
example http://host/some/script.jsp.html would execute the script
some/script.jsp while requesting http://host/some/script.jsp would
return the script source (and yes, there are equally valid use cases,
which would expect to prevent sending the script source and we will have
to cope with those cases.

I will suggest a more detailed proposal in a separate thread.

> ps: if this is really needed, it could be done using a mixin node type
> to mark the file/resource as executable.eg: sling:executable

This of course would not work, as mixin node types are not reflected in
the Resource interface and servlet resolution acts in the realm of
Resources and does not care about the implementation of the Resource.
This is important to support scripts from other sources, most
importantly Servlets reflected into the Resource tree and scripts
provided by bundles.

Regards
Felix