You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Lars Trieloff <la...@trieloff.net> on 2007/12/21 11:51:28 UTC
Re: Filter Scripting (was: POSTs and microjax)
Hi Michael, Felix,
I think what Michael needs when he refers to Microsling is a
scriptable Sling. This means that all the core aspects of Sling:
- request handling
- error handling
- request filtering
- response filtering
- repository events
- timed events (cron jobs)
are scriptable. I think this is a reasonable request and would allow
users to build powerful web applications in the script language (or
even servlets) they prefer.
regards,
Lars
>
> Back to your problem: What you might want to do, as you said, is SPAM
> "filtering". So you would implement a Filter, register it with the
> system and get the raw requests in your hands and can react before the
> servlet (or script) is even called (well this is not new
> information, of
> course ;-) ).
>
> Regards
> Felix
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Event Scripting (was: Filter Scripting (was: POSTs and
microjax))
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 16:29 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I've been thinking about this, but do not see a solution right now.
> The problem with the approach of executing the script with permissions
> of the script owner (whoever this might be) is that in order to be
> able to observe the whole repository, we have to give read access to
> the whole repository to the script owner, which is another way of
> creating a second superuser. So, instead of letting the script author
> sneak in, we have to open the gates widely.
Hmm, observe events and handling the events in case of scripting these
handlers are different things: There is a bundle observing the events
and in case of events will trigger the respective events. So we have an
issue of who will access the repository.
We could of course turn around and say, the scripts indicate what is
observed and hence the credentials of the user posting the script is
used to observe and run the scripts. So whatever rights the user posting
the script has defines, whether observation is at all possible and what
can be done.
This second solution would probably even make some sense. WDYT ?
Regards
Felix
>
> Lars
>
>
> On 21.12.2007, at 14:15, Felix Meschberger wrote:
>
> > Hi Lars,
> >
> > Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
> >> Hi Felix,
> >>
> >> I think, we should protect the ability to install scripts or event
> >> listeners, not limit the power of scripts or event listeners. You
> >> could rephrase this example: Suppose somebody installs a GET.js
> >> script
> >> with bad-side effects and tricks the administrator or power-user into
> >> requesting a corresponding resource: boom, the script is executed
> >> with
> >> power-user permissions.
> >
> > Sure, this is somewhat comparable - given that the power user is using
> > the site :-) On the other hand, a power user may certainly maintain
> > content, without even thinking about using possibly unsafe scripts:
> > Compared to GET.js scripts, where he has some chance of not calling it
> > by just not use the site, managing the content causes the scripts to
> > be
> > called.
> >
> > This _is_ different.
> >
> >> We should trust the event listener author as much as we trust the
> >> servlet or script authors.
> >
> > No, because the initiation of the script execution is different: for
> > servlets and other request handling script it is a willfull action of
> > potentially causing some actions. When maintaining the content,
> > there is
> > no way of preventing such action - this is the power of observation.
> >
> > Regards
> > Felix
> >
> >>
> >> Lars
> >>
> >> On 21.12.2007, at 13:43, Felix Meschberger wrote:
> >>
> >>> Hi Lars,
> >>>
> >>> Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
> >>>>>> The event is executed with the credentials of Event.getUserId().
> >>>>>
> >>>>> First it might not work. Of course, given the admin session, you
> >>>>> might
> >>>>> create a session of the desired user. Second, and more important:
> >>>>> the
> >>>>> Event.getUserId is the user name of the session which performed
> >>>>> the
> >>>>> changes causing the event.
> >>>>
> >>>> This is how it should behave. You change something in the
> >>>> repository
> >>>> and then you trigger the registered (high-level) event handlers.
> >>>>
> >>>>> Running the event handler as that user would
> >>>>> open a backdoor wide open. So this is definitely a no-go. Sorry.
> >>>>
> >>>> I do not see the backdoor. Default permissions do still apply, and
> >>>> you
> >>>> as an authenticated user cannot inject a script that would be
> >>>> executed
> >>>> and the script cannot acquire a higher permission level.
> >>>>
> >>>> Can you describe a scenario where this backdoor is used?
> >>>
> >>> Consider a group EventListener is allowed to register event
> >>> handlers.
> >>> Members of this group have limited access rights to the repository.
> >>> Now,
> >>> the administrator (or some other power user) modifies data. The
> >>> scripts
> >>> posted by the EventListener users are now running as administrator
> >>> (or
> >>> as the other power user). And, boom, those EventListeners have more
> >>> power than they are supposed to have ...
> >>>
> >>> Its just like a hidden and unintended sudo :-) One solution might be
> >>> that script(s) run as the user owning the script - whatever "owner"
> >>> means in JCR, as AFAIK there is no such thing specified and this
> >>> would
> >>> be implementation specific and therefore not securely leverageable.
> >>>
> >>> Another solution would be, to run the scripts as the "anonymous"
> >>> user,
> >>> provided that user has really limited rights.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> lars@trieloff.net
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: Event Scripting (was: Filter Scripting (was: POSTs and microjax))
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
I've been thinking about this, but do not see a solution right now.
The problem with the approach of executing the script with permissions
of the script owner (whoever this might be) is that in order to be
able to observe the whole repository, we have to give read access to
the whole repository to the script owner, which is another way of
creating a second superuser. So, instead of letting the script author
sneak in, we have to open the gates widely.
Lars
On 21.12.2007, at 14:15, Felix Meschberger wrote:
> Hi Lars,
>
> Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
>> Hi Felix,
>>
>> I think, we should protect the ability to install scripts or event
>> listeners, not limit the power of scripts or event listeners. You
>> could rephrase this example: Suppose somebody installs a GET.js
>> script
>> with bad-side effects and tricks the administrator or power-user into
>> requesting a corresponding resource: boom, the script is executed
>> with
>> power-user permissions.
>
> Sure, this is somewhat comparable - given that the power user is using
> the site :-) On the other hand, a power user may certainly maintain
> content, without even thinking about using possibly unsafe scripts:
> Compared to GET.js scripts, where he has some chance of not calling it
> by just not use the site, managing the content causes the scripts to
> be
> called.
>
> This _is_ different.
>
>> We should trust the event listener author as much as we trust the
>> servlet or script authors.
>
> No, because the initiation of the script execution is different: for
> servlets and other request handling script it is a willfull action of
> potentially causing some actions. When maintaining the content,
> there is
> no way of preventing such action - this is the power of observation.
>
> Regards
> Felix
>
>>
>> Lars
>>
>> On 21.12.2007, at 13:43, Felix Meschberger wrote:
>>
>>> Hi Lars,
>>>
>>> Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
>>>>>> The event is executed with the credentials of Event.getUserId().
>>>>>
>>>>> First it might not work. Of course, given the admin session, you
>>>>> might
>>>>> create a session of the desired user. Second, and more important:
>>>>> the
>>>>> Event.getUserId is the user name of the session which performed
>>>>> the
>>>>> changes causing the event.
>>>>
>>>> This is how it should behave. You change something in the
>>>> repository
>>>> and then you trigger the registered (high-level) event handlers.
>>>>
>>>>> Running the event handler as that user would
>>>>> open a backdoor wide open. So this is definitely a no-go. Sorry.
>>>>
>>>> I do not see the backdoor. Default permissions do still apply, and
>>>> you
>>>> as an authenticated user cannot inject a script that would be
>>>> executed
>>>> and the script cannot acquire a higher permission level.
>>>>
>>>> Can you describe a scenario where this backdoor is used?
>>>
>>> Consider a group EventListener is allowed to register event
>>> handlers.
>>> Members of this group have limited access rights to the repository.
>>> Now,
>>> the administrator (or some other power user) modifies data. The
>>> scripts
>>> posted by the EventListener users are now running as administrator
>>> (or
>>> as the other power user). And, boom, those EventListeners have more
>>> power than they are supposed to have ...
>>>
>>> Its just like a hidden and unintended sudo :-) One solution might be
>>> that script(s) run as the user owning the script - whatever "owner"
>>> means in JCR, as AFAIK there is no such thing specified and this
>>> would
>>> be implementation specific and therefore not securely leverageable.
>>>
>>> Another solution would be, to run the scripts as the "anonymous"
>>> user,
>>> provided that user has really limited rights.
>>>
>>> Regards
>>> Felix
>>>
>>
>> --
>> Lars Trieloff
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Filter Scripting (was: POSTs and microjax)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I think, we should protect the ability to install scripts or event
> listeners, not limit the power of scripts or event listeners. You
> could rephrase this example: Suppose somebody installs a GET.js script
> with bad-side effects and tricks the administrator or power-user into
> requesting a corresponding resource: boom, the script is executed with
> power-user permissions.
Sure, this is somewhat comparable - given that the power user is using
the site :-) On the other hand, a power user may certainly maintain
content, without even thinking about using possibly unsafe scripts:
Compared to GET.js scripts, where he has some chance of not calling it
by just not use the site, managing the content causes the scripts to be
called.
This _is_ different.
> We should trust the event listener author as much as we trust the
> servlet or script authors.
No, because the initiation of the script execution is different: for
servlets and other request handling script it is a willfull action of
potentially causing some actions. When maintaining the content, there is
no way of preventing such action - this is the power of observation.
Regards
Felix
>
> Lars
>
> On 21.12.2007, at 13:43, Felix Meschberger wrote:
>
> > Hi Lars,
> >
> > Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
> >>>> The event is executed with the credentials of Event.getUserId().
> >>>
> >>> First it might not work. Of course, given the admin session, you
> >>> might
> >>> create a session of the desired user. Second, and more important:
> >>> the
> >>> Event.getUserId is the user name of the session which performed the
> >>> changes causing the event.
> >>
> >> This is how it should behave. You change something in the repository
> >> and then you trigger the registered (high-level) event handlers.
> >>
> >>> Running the event handler as that user would
> >>> open a backdoor wide open. So this is definitely a no-go. Sorry.
> >>
> >> I do not see the backdoor. Default permissions do still apply, and
> >> you
> >> as an authenticated user cannot inject a script that would be
> >> executed
> >> and the script cannot acquire a higher permission level.
> >>
> >> Can you describe a scenario where this backdoor is used?
> >
> > Consider a group EventListener is allowed to register event handlers.
> > Members of this group have limited access rights to the repository.
> > Now,
> > the administrator (or some other power user) modifies data. The
> > scripts
> > posted by the EventListener users are now running as administrator (or
> > as the other power user). And, boom, those EventListeners have more
> > power than they are supposed to have ...
> >
> > Its just like a hidden and unintended sudo :-) One solution might be
> > that script(s) run as the user owning the script - whatever "owner"
> > means in JCR, as AFAIK there is no such thing specified and this would
> > be implementation specific and therefore not securely leverageable.
> >
> > Another solution would be, to run the scripts as the "anonymous" user,
> > provided that user has really limited rights.
> >
> > Regards
> > Felix
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: Filter Scripting (was: POSTs and microjax)
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
I think, we should protect the ability to install scripts or event
listeners, not limit the power of scripts or event listeners. You
could rephrase this example: Suppose somebody installs a GET.js script
with bad-side effects and tricks the administrator or power-user into
requesting a corresponding resource: boom, the script is executed with
power-user permissions.
We should trust the event listener author as much as we trust the
servlet or script authors.
Lars
On 21.12.2007, at 13:43, Felix Meschberger wrote:
> Hi Lars,
>
> Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
>>>> The event is executed with the credentials of Event.getUserId().
>>>
>>> First it might not work. Of course, given the admin session, you
>>> might
>>> create a session of the desired user. Second, and more important:
>>> the
>>> Event.getUserId is the user name of the session which performed the
>>> changes causing the event.
>>
>> This is how it should behave. You change something in the repository
>> and then you trigger the registered (high-level) event handlers.
>>
>>> Running the event handler as that user would
>>> open a backdoor wide open. So this is definitely a no-go. Sorry.
>>
>> I do not see the backdoor. Default permissions do still apply, and
>> you
>> as an authenticated user cannot inject a script that would be
>> executed
>> and the script cannot acquire a higher permission level.
>>
>> Can you describe a scenario where this backdoor is used?
>
> Consider a group EventListener is allowed to register event handlers.
> Members of this group have limited access rights to the repository.
> Now,
> the administrator (or some other power user) modifies data. The
> scripts
> posted by the EventListener users are now running as administrator (or
> as the other power user). And, boom, those EventListeners have more
> power than they are supposed to have ...
>
> Its just like a hidden and unintended sudo :-) One solution might be
> that script(s) run as the user owning the script - whatever "owner"
> means in JCR, as AFAIK there is no such thing specified and this would
> be implementation specific and therefore not securely leverageable.
>
> Another solution would be, to run the scripts as the "anonymous" user,
> provided that user has really limited rights.
>
> Regards
> Felix
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Filter Scripting (was: POSTs and microjax)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
> >> The event is executed with the credentials of Event.getUserId().
> >
> > First it might not work. Of course, given the admin session, you might
> > create a session of the desired user. Second, and more important: the
> > Event.getUserId is the user name of the session which performed the
> > changes causing the event.
>
> This is how it should behave. You change something in the repository
> and then you trigger the registered (high-level) event handlers.
>
> > Running the event handler as that user would
> > open a backdoor wide open. So this is definitely a no-go. Sorry.
>
> I do not see the backdoor. Default permissions do still apply, and you
> as an authenticated user cannot inject a script that would be executed
> and the script cannot acquire a higher permission level.
>
> Can you describe a scenario where this backdoor is used?
Consider a group EventListener is allowed to register event handlers.
Members of this group have limited access rights to the repository. Now,
the administrator (or some other power user) modifies data. The scripts
posted by the EventListener users are now running as administrator (or
as the other power user). And, boom, those EventListeners have more
power than they are supposed to have ...
Its just like a hidden and unintended sudo :-) One solution might be
that script(s) run as the user owning the script - whatever "owner"
means in JCR, as AFAIK there is no such thing specified and this would
be implementation specific and therefore not securely leverageable.
Another solution would be, to run the scripts as the "anonymous" user,
provided that user has really limited rights.
Regards
Felix
Re: Filter Scripting (was: POSTs and microjax)
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
>
>> The event is executed with the credentials of Event.getUserId().
>
> First it might not work. Of course, given the admin session, you might
> create a session of the desired user. Second, and more important: the
> Event.getUserId is the user name of the session which performed the
> changes causing the event.
This is how it should behave. You change something in the repository
and then you trigger the registered (high-level) event handlers.
> Running the event handler as that user would
> open a backdoor wide open. So this is definitely a no-go. Sorry.
I do not see the backdoor. Default permissions do still apply, and you
as an authenticated user cannot inject a script that would be executed
and the script cannot acquire a higher permission level.
Can you describe a scenario where this backdoor is used?
regards,
Lars
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Filter Scripting (was: POSTs and microjax)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 12:46 +0100 schrieb Lars Trieloff:
> > request-level or resource-level filters.
> >
> > The problem with filtering is, that it imposes certain performance
> > degradation. So if you (or Michael) would be able to present a
> > conceptor
> > even a patch, we may certainly further discuss.
>
> Let's start with a concept, then a patch and then care for
> performance. No premature optimization.
Sure, but a concept, which obvisouly suffers from bad performance should
be carefully reviewed :-)
> >> - repository events
> >
> > This sounds, easy to implement, though there are certain ACL related
> > open issues: What credentials are active for the scripted events ? Who
> > is allowed to post scripted JCR event handlers ? In fact this has
> > already been discussed [1] to a certain degree but without reaching a
> > final target...
>
> Everybody who can create scripts or servlets is allowed to post
> scripted event handlers, a simple ACL on the events-tree is enough.
Sounds reasonable, and I would have proposed that way, too.
> The event is executed with the credentials of Event.getUserId().
First it might not work. Of course, given the admin session, you might
create a session of the desired user. Second, and more important: the
Event.getUserId is the user name of the session which performed the
changes causing the event. Running the event handler as that user would
open a backdoor wide open. So this is definitely a no-go. Sorry.
Regards
Felix
Re: Filter Scripting (was: POSTs and microjax)
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Alex,
> It will be a great overall feature of Sling to support both
> "programming" styles. The only thing missing in the current state is
> support for an easy transition from your prototypical script-based
> application to a mainly servlet-based and bundled app. There is the
> idea to automatically create bundles from scripts inside the
> repository, which would remove the burden of learning bundle
> configuration from the user and give him a good kick start with his
> existing code. This roundtrip feature would IMHO solve the script
> vs. bundle discussion perfectly.
this round-tripping would finally eliminate the biggest separation
between the two programming models, but I doubt that we could stop
this "scripts vs. servlets" discussion, once it has started ;-)
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Filter Scripting (was: POSTs and microjax)
Posted by Michael Marth <mm...@day.com>.
Alex,
I can understand both sides of the discussion because both are needed.
> It just depends on the user's or customer's requirements.
>
>
I agree. Maybe it'd be good if we treated scripting and Java development as
equal citizens, i.e. if we tried to make available all features to both
approaches if that is possible (I am not sure if it is, though).
Cheers
Michael
--
Michael Marth, http://dev.day.com
Re: Filter Scripting (was: POSTs and microjax)
Posted by Alexander Klimetschek <ak...@day.com>.
Hi Michael,
Am 21.12.2007 um 14:58 schrieb Michael Marth:
> <rant>
> Regarding the sentiment that scripted web apps are "for beginners",
> do not
> support a structured deployment or development process and do not
> perform
> well: yes, it is true that compiled code runs 1000x faster than
> interpreted
> code (I just made up that number) and that scripting languages are
> often not
> type safe. But still, the web is full of extremely successful web
> technologies made with interpreted/scripted languages and extremely
> scaled
> web sites built upon them (e.g. Perl, ColdFusion, PHP, Rails,
> yScript and
> Yahoo, Facebook, Myspace respectively). So, in all seriousness, I
> do not at
> all agree with equating scripting and
> beginner/non-professional/unstructured. Moreover, I do not see
> scripting as
> an upgrade path to "the real thing". If we want to attract script
> developers
> to use sling to build web apps we should not think this way. To me,
> scripting is fine.
> </rant>
It was not my intention to state that scripting is "unprofessional".
Actually I like scripting very much as well! I wanted to describe the
full broadness between "dirty" scripts on one side and fully-
statically-checked java code on the other side. My fault that I didn't
make myself clear here.
I can understand both sides of the discussion because both are needed.
It just depends on the user's or customer's requirements.
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Filter Scripting (was: POSTs and microjax)
Posted by Michael Marth <mm...@day.com>.
Guys,
just like Lars I find that having "everything" scriptable is very desirable.
"Everything" meaning in descending order of importance: render scripts,
filters, event listeners. Building a web app where I start with some render
scripts in Javascript but have to revert to Java for writing a filter is not
a desirable scenario to me. Hence, I would really like to add this as a
requirement/wish for sling/microsling/TWFKAU 2.0.
Cheers
Michael
PS: sorry, but:
<rant>
Regarding the sentiment that scripted web apps are "for beginners", do not
support a structured deployment or development process and do not perform
well: yes, it is true that compiled code runs 1000x faster than interpreted
code (I just made up that number) and that scripting languages are often not
type safe. But still, the web is full of extremely successful web
technologies made with interpreted/scripted languages and extremely scaled
web sites built upon them (e.g. Perl, ColdFusion, PHP, Rails, yScript and
Yahoo, Facebook, Myspace respectively). So, in all seriousness, I do not at
all agree with equating scripting and
beginner/non-professional/unstructured. Moreover, I do not see scripting as
an upgrade path to "the real thing". If we want to attract script developers
to use sling to build web apps we should not think this way. To me,
scripting is fine.
</rant>
On 12/21/07, Alexander Klimetschek <ak...@day.com> wrote:
>
> Hi,
>
> Am 21.12.2007 um 12:46 schrieb Lars Trieloff:
>
> > Right. But this realization should come from the user, not from the
> > framework that says for this certain feature, you have to forget
> > everything you learned about scripting and start using an IDE, Maven
> > and OSGi, even if you just want to implement a small filter that
> > validates your request parameter or overrides the content-type-
> > header in the response.
>
> [...]
>
> > Right. But moving to Sling, should mean chosing the Servlet
> > implementation voluntarily over the script implementation. This
> > separation between Sling and Microsling will not prove helpful if we
> > do not understand that Servlet and scripts are two different, but
> > equally valid expression of one of the concepts listed above.
>
>
>
> I agree that from the user point of view it makes sense to have
> everything scriptable. Scripts directly in the repository are good for
> the beginner, for quickly creating prototypes, for playing around with
> certain features, for having a rapid application development platform
> and even for being able to simply edit scripts in a browser-based IDE
> like it is getting popular now (for the iPhone [1] or for web 2.0 apps
> [2]). But once your application gets bigger, runs on multiple
> machines, is developed by many developers at the same time and crossed
> its first release, you need SCM, a structured deployment and software
> lifecycle management. This is much better handled with OSGi bundles.
>
> It will be a great overall feature of Sling to support both
> "programming" styles. The only thing missing in the current state is
> support for an easy transition from your prototypical script-based
> application to a mainly servlet-based and bundled app. There is the
> idea to automatically create bundles from scripts inside the
> repository, which would remove the burden of learning bundle
> configuration from the user and give him a good kick start with his
> existing code. This roundtrip feature would IMHO solve the script vs.
> bundle discussion perfectly.
>
> Alex
>
> [1] http://www.jiggyapp.com/
>
> [2] http://appjet.com/
>
>
> ----------------------------< alexander.klimetschek@day.com >---
> Alexander Klimetschek, Day Management AG, Barfuesserplatz 6,
> CH - 4001 Basel, T +41 61 226 55 31, M +49 151 15 77 20 56
> ---------------------------------------< http://www.day.com >---
>
> Xing: http://www.xing.com/go/invite/3268380.32d2d4
> LinkedIn: http://www.linkedin.com/in/klimetschek
> Blog: http://weblogs.goshaky.com/weblogs/alexkli/
>
>
>
>
>
>
>
>
>
>
--
Michael Marth, http://dev.day.com
Re: Filter Scripting (was: POSTs and microjax)
Posted by Alexander Klimetschek <ak...@day.com>.
Hi,
Am 21.12.2007 um 12:46 schrieb Lars Trieloff:
> Right. But this realization should come from the user, not from the
> framework that says for this certain feature, you have to forget
> everything you learned about scripting and start using an IDE, Maven
> and OSGi, even if you just want to implement a small filter that
> validates your request parameter or overrides the content-type-
> header in the response.
[...]
> Right. But moving to Sling, should mean chosing the Servlet
> implementation voluntarily over the script implementation. This
> separation between Sling and Microsling will not prove helpful if we
> do not understand that Servlet and scripts are two different, but
> equally valid expression of one of the concepts listed above.
I agree that from the user point of view it makes sense to have
everything scriptable. Scripts directly in the repository are good for
the beginner, for quickly creating prototypes, for playing around with
certain features, for having a rapid application development platform
and even for being able to simply edit scripts in a browser-based IDE
like it is getting popular now (for the iPhone [1] or for web 2.0 apps
[2]). But once your application gets bigger, runs on multiple
machines, is developed by many developers at the same time and crossed
its first release, you need SCM, a structured deployment and software
lifecycle management. This is much better handled with OSGi bundles.
It will be a great overall feature of Sling to support both
"programming" styles. The only thing missing in the current state is
support for an easy transition from your prototypical script-based
application to a mainly servlet-based and bundled app. There is the
idea to automatically create bundles from scripts inside the
repository, which would remove the burden of learning bundle
configuration from the user and give him a good kick start with his
existing code. This roundtrip feature would IMHO solve the script vs.
bundle discussion perfectly.
Alex
[1] http://www.jiggyapp.com/
[2] http://appjet.com/
----------------------------< alexander.klimetschek@day.com >---
Alexander Klimetschek, Day Management AG, Barfuesserplatz 6,
CH - 4001 Basel, T +41 61 226 55 31, M +49 151 15 77 20 56
---------------------------------------< http://www.day.com >---
Xing: http://www.xing.com/go/invite/3268380.32d2d4
LinkedIn: http://www.linkedin.com/in/klimetschek
Blog: http://weblogs.goshaky.com/weblogs/alexkli/
Re: Filter Scripting (was: POSTs and microjax)
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
>> - request handling
>> - error handling
>
> We have both, right ?
Right. And this is great.
>> - request filtering
>> - response filtering
>
> There is no difference in request and response filter - there is just
> filtering. Currently we implement this by requiring the registration
> of
> request-level or resource-level filters.
>
> The problem with filtering is, that it imposes certain performance
> degradation. So if you (or Michael) would be able to present a
> conceptor
> even a patch, we may certainly further discuss.
Let's start with a concept, then a patch and then care for
performance. No premature optimization.
>
>> - repository events
>
> This sounds, easy to implement, though there are certain ACL related
> open issues: What credentials are active for the scripted events ? Who
> is allowed to post scripted JCR event handlers ? In fact this has
> already been discussed [1] to a certain degree but without reaching a
> final target...
Everybody who can create scripts or servlets is allowed to post
scripted event handlers, a simple ACL on the events-tree is enough.
The event is executed with the credentials of Event.getUserId().
>> - timed events (cron jobs)
>
> Carsten ?
>
>> are scriptable. I think this is a reasonable request and would allow
>> users to build powerful web applications in the script language (or
>> even servlets) they prefer.
>
> Well, I think, there are things, for which scripting is very well
> suited
> - such as processing GET requests - and other things where scripts are
> not actually adequate. So to build powerful applications, scripting
> may
> certainly be used, but over time, you may realize, that the scripting
> language of your choice might simply not be adequate.
Right. But this realization should come from the user, not from the
framework that says for this certain feature, you have to forget
everything you learned about scripting and start using an IDE, Maven
and OSGi, even if you just want to implement a small filter that
validates your request parameter or overrides the content-type-header
in the response.
> And to just use
> scripting, because for a given limited tool it is the only way to
> "extend" it, is probably not right solution. I would suggest to move
> to
> Sling in this case. Just my very personal €0.02.
Right. But moving to Sling, should mean chosing the Servlet
implementation voluntarily over the script implementation. This
separation between Sling and Microsling will not prove helpful if we
do not understand that Servlet and scripts are two different, but
equally valid expression of one of the concepts listed above.
Lars
> [1]
> http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00948.html
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Filter Scripting (was: POSTs and microjax)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 11:51 +0100 schrieb Lars Trieloff:
> Hi Michael, Felix,
>
> I think what Michael needs when he refers to Microsling is a
> scriptable Sling. This means that all the core aspects of Sling:
>
> - request handling
> - error handling
We have both, right ?
> - request filtering
> - response filtering
There is no difference in request and response filter - there is just
filtering. Currently we implement this by requiring the registration of
request-level or resource-level filters.
The problem with filtering is, that it imposes certain performance
degradation. So if you (or Michael) would be able to present a conceptor
even a patch, we may certainly further discuss.
> - repository events
This sounds, easy to implement, though there are certain ACL related
open issues: What credentials are active for the scripted events ? Who
is allowed to post scripted JCR event handlers ? In fact this has
already been discussed [1] to a certain degree but without reaching a
final target...
> - timed events (cron jobs)
Carsten ?
> are scriptable. I think this is a reasonable request and would allow
> users to build powerful web applications in the script language (or
> even servlets) they prefer.
Well, I think, there are things, for which scripting is very well suited
- such as processing GET requests - and other things where scripts are
not actually adequate. So to build powerful applications, scripting may
certainly be used, but over time, you may realize, that the scripting
language of your choice might simply not be adequate. And to just use
scripting, because for a given limited tool it is the only way to
"extend" it, is probably not right solution. I would suggest to move to
Sling in this case. Just my very personal €0.02.
Regards
Felix
[1]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00948.html
Re: Filter Scripting
Posted by Carsten Ziegeler <cz...@apache.org>.
Lars Trieloff wrote
> Hi Michael, Felix,
>
> I think what Michael needs when he refers to Microsling is a scriptable
> Sling. This means that all the core aspects of Sling:
>
> - request handling
> - error handling
> - request filtering
> - response filtering
> - repository events
> - timed events (cron jobs)
>
> are scriptable. I think this is a reasonable request and would allow
> users to build powerful web applications in the script language (or even
> servlets) they prefer.
>
I'm not sure if we really need to do something special for scripts in
these areas. If it's possible to extend Sling with a Java
component/service then someone should be able to implement a bridge for
hooking in the favorite scripting language at this place.
The list above mentions "timed events (cron jobs)" - now, we have
support for this in Sling (the event and scheduler modules) based on the
OSGi event handling. In other words, it's possible to fire events at a
specific time. There can be a listener for this event - this is an OSGi
service. Now I think this is all we need to provide for users, if people
really want to script such a listener with a different language, then
it's possible to provide a bridge here.
But what is the benefit of using scripts in these places? Handling
events for instance is something which usually affects the business
logic and not the display logic. I see a point of using scripting
language for display logic :)
And especially in the case of filters this might all be very difficult
to setup, like getting access to the repository, using the right user
context etc.
I think, one is able to get and call (evaluate) a script using the
ScriptResolver, so writing a component that gets a script from a
specific path and executes it, its easy and imho sufficient for mosto f
these use cases.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org