You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/10/17 09:23:52 UTC
To Filter or not to Filter
Hi all,
Currently, we love using filtering in both Sling and microsling: Every
part of request processing is implemented using a filter. This was not
always the case: In the days when Sling was still private, there was no
filtering at all.
Probably we must come to a mix of both: There are some tasks, which have
to be executed all the times and there are some tasks which may or may
not be executed. Examples of the former are authentication, proper error
handling, resource resolution and servlet/script resolution. Examples of
the latter are locale resolution, default setting of the response
content type etc.
So, for microsling, I propose to not implement resource resolution as a
filter, in fact leaving default response content type setting the only
filtering task (currently).
For Sling I propose to not implement filtering for authentication
(replace AuthenticationFilter by a service called directly),
errorhandler (replace ErrorHandlerFilter), contentresolution (replace
ContentResolverFilter) and component resolution (replace
ComponentResolver). These tasks are always executed in the listed order
by the Sling request processor. After the component is resolved the
registered filters are called and finally the component itself is
called.
WDYT ?
Regards
Felix
Re: To Filter or not to Filter
Posted by Christophe Lombart <ch...@gmail.com>.
I have the same feeling here. Filter are flexible. Specially for making
processing like authencitation
I would like to say that microsling is very simple to understand as it is. I
like the combinaison of the different serlvets & filters. Cool & great job.
On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Felix Meschberger wrote:
> > Hi all,
> >
> > Currently, we love using filtering in both Sling and microsling: Every
> > part of request processing is implemented using a filter. This was not
> > always the case: In the days when Sling was still private, there was no
> > filtering at all.
> >
> > Probably we must come to a mix of both: There are some tasks, which have
> > to be executed all the times and there are some tasks which may or may
> > not be executed. Examples of the former are authentication, proper error
> > handling, resource resolution and servlet/script resolution. Examples of
> > the latter are locale resolution, default setting of the response
> > content type etc.
> >
> > So, for microsling, I propose to not implement resource resolution as a
> > filter, in fact leaving default response content type setting the only
> > filtering task (currently).
> >
> > For Sling I propose to not implement filtering for authentication
> > (replace AuthenticationFilter by a service called directly),
> > errorhandler (replace ErrorHandlerFilter), contentresolution (replace
> > ContentResolverFilter) and component resolution (replace
> > ComponentResolver). These tasks are always executed in the listed order
> > by the Sling request processor. After the component is resolved the
> > registered filters are called and finally the component itself is
> > called.
> >
> > WDYT ?
> >
> Hmm, filters have the great advantage being very flexible. You can
> combine them in any order, make them optional etc. On the other hand I
> agree that some things are required for sling to work, so a filter
> doesn't seem quiet right.
>
> I agree for resource and content resolution. But I'm not sure about
> authentication. Having a filter which does the authentication is very
> transparent. If we are using the servlet filter interface for these
> filters, its easy to use other authentication mechanisms like for
> example spring authentication (aka acegi) which is based on servlet
> filters as well.
> So for now, I personally tend to go with filters except where something
> is really required for Sling core to work. There we could use an
> explicit service instead.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: To Filter or not to Filter
Posted by Tobias Bocanegra <to...@day.com>.
ok. thanks for the clarification.
in this case, i would avoid the auth filter as well.
regards, toby
On 10/17/07, Felix Meschberger <fm...@gmail.com> wrote:
> Am Mittwoch, den 17.10.2007, 16:49 +0200 schrieb Tobias Bocanegra:
> > i disagree...eg. when running in a appserver that does authentication
> > sling does not need the default http auth filter, but maybe a
> > jaas-auth filter or sso filter or whatsoever.
> >
> > bottom line: the authentication mechanism needs to be configurable.
>
> This is not question here. Sling is in fact built such, that the method
> of building the credentials is configurable and filters is not the only
> way how sling mechanisms can be "configured" in a flexible way.
>
> So in the case of authentication: We will have an Authentication service
> used by Sling, which in turn may make use of additional helpers. Both
> the helpers can be added/removed at will and the Authentication service
> may be implemented however we wish.
>
> This is something different than whether we call the authentication
> service directly or as part of some filtering.
>
> Regards
> Felix
>
> > regards, toby
> >
> > On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > > Felix Meschberger wrote:
> > > > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
> > > >> I agree for resource and content resolution. But I'm not sure about
> > > >> authentication. Having a filter which does the authentication is very
> > > >> transparent. If we are using the servlet filter interface for these
> > > >> filters, its easy to use other authentication mechanisms like for
> > > >> example spring authentication (aka acegi) which is based on servlet
> > > >> filters as well.
> > > >> So for now, I personally tend to go with filters except where something
> > > >> is really required for Sling core to work. There we could use an
> > > >> explicit service instead.
> > > >
> > > > Not sure, whether this is the level authentication we require. Sling's
> > > > main purpose, which is also made strongly visible through the upcoming
> > > > Resource interface, is to provide a web application front-end to JCR
> > > > repositories. As such, I assume, that the JCR repository will be used
> > > > for authentication and access control purposes.
> > > >
> > > > As such, the only moving target of authentication is the question on how
> > > > to extract credential data from the request to use it as input to the
> > > > JCR Repository.login method. Currently Sling has an AuthenticationFilter
> > > > which makes use of AuthenticationHandler services (only HTTP Header
> > > > Authentication is implemented for now) to get the credentials or request
> > > > the credentials from the client. How authentication is handled in the
> > > > repository is completely out-of-scope for Sling.
> > > >
> > > > This is why I proposed to not use a filter for authentication.
> > > >
> > > Yes, you're right - so no filter for authentication.
> > >
> > > Carsten
> > >
> > > --
> > > Carsten Ziegeler
> > > cziegeler@apache.org
> > >
> >
> >
>
>
--
-----------------------------------------< 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: To Filter or not to Filter
Posted by Felix Meschberger <fm...@gmail.com>.
Am Mittwoch, den 17.10.2007, 16:49 +0200 schrieb Tobias Bocanegra:
> i disagree...eg. when running in a appserver that does authentication
> sling does not need the default http auth filter, but maybe a
> jaas-auth filter or sso filter or whatsoever.
>
> bottom line: the authentication mechanism needs to be configurable.
This is not question here. Sling is in fact built such, that the method
of building the credentials is configurable and filters is not the only
way how sling mechanisms can be "configured" in a flexible way.
So in the case of authentication: We will have an Authentication service
used by Sling, which in turn may make use of additional helpers. Both
the helpers can be added/removed at will and the Authentication service
may be implemented however we wish.
This is something different than whether we call the authentication
service directly or as part of some filtering.
Regards
Felix
> regards, toby
>
> On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > Felix Meschberger wrote:
> > > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
> > >> I agree for resource and content resolution. But I'm not sure about
> > >> authentication. Having a filter which does the authentication is very
> > >> transparent. If we are using the servlet filter interface for these
> > >> filters, its easy to use other authentication mechanisms like for
> > >> example spring authentication (aka acegi) which is based on servlet
> > >> filters as well.
> > >> So for now, I personally tend to go with filters except where something
> > >> is really required for Sling core to work. There we could use an
> > >> explicit service instead.
> > >
> > > Not sure, whether this is the level authentication we require. Sling's
> > > main purpose, which is also made strongly visible through the upcoming
> > > Resource interface, is to provide a web application front-end to JCR
> > > repositories. As such, I assume, that the JCR repository will be used
> > > for authentication and access control purposes.
> > >
> > > As such, the only moving target of authentication is the question on how
> > > to extract credential data from the request to use it as input to the
> > > JCR Repository.login method. Currently Sling has an AuthenticationFilter
> > > which makes use of AuthenticationHandler services (only HTTP Header
> > > Authentication is implemented for now) to get the credentials or request
> > > the credentials from the client. How authentication is handled in the
> > > repository is completely out-of-scope for Sling.
> > >
> > > This is why I proposed to not use a filter for authentication.
> > >
> > Yes, you're right - so no filter for authentication.
> >
> > Carsten
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
>
>
Re: To Filter or not to Filter
Posted by Tobias Bocanegra <to...@day.com>.
i disagree...eg. when running in a appserver that does authentication
sling does not need the default http auth filter, but maybe a
jaas-auth filter or sso filter or whatsoever.
bottom line: the authentication mechanism needs to be configurable.
regards, toby
On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Felix Meschberger wrote:
> > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
> >> I agree for resource and content resolution. But I'm not sure about
> >> authentication. Having a filter which does the authentication is very
> >> transparent. If we are using the servlet filter interface for these
> >> filters, its easy to use other authentication mechanisms like for
> >> example spring authentication (aka acegi) which is based on servlet
> >> filters as well.
> >> So for now, I personally tend to go with filters except where something
> >> is really required for Sling core to work. There we could use an
> >> explicit service instead.
> >
> > Not sure, whether this is the level authentication we require. Sling's
> > main purpose, which is also made strongly visible through the upcoming
> > Resource interface, is to provide a web application front-end to JCR
> > repositories. As such, I assume, that the JCR repository will be used
> > for authentication and access control purposes.
> >
> > As such, the only moving target of authentication is the question on how
> > to extract credential data from the request to use it as input to the
> > JCR Repository.login method. Currently Sling has an AuthenticationFilter
> > which makes use of AuthenticationHandler services (only HTTP Header
> > Authentication is implemented for now) to get the credentials or request
> > the credentials from the client. How authentication is handled in the
> > repository is completely out-of-scope for Sling.
> >
> > This is why I proposed to not use a filter for authentication.
> >
> Yes, you're right - so no filter for authentication.
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
-----------------------------------------< 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: To Filter or not to Filter
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
>> I agree for resource and content resolution. But I'm not sure about
>> authentication. Having a filter which does the authentication is very
>> transparent. If we are using the servlet filter interface for these
>> filters, its easy to use other authentication mechanisms like for
>> example spring authentication (aka acegi) which is based on servlet
>> filters as well.
>> So for now, I personally tend to go with filters except where something
>> is really required for Sling core to work. There we could use an
>> explicit service instead.
>
> Not sure, whether this is the level authentication we require. Sling's
> main purpose, which is also made strongly visible through the upcoming
> Resource interface, is to provide a web application front-end to JCR
> repositories. As such, I assume, that the JCR repository will be used
> for authentication and access control purposes.
>
> As such, the only moving target of authentication is the question on how
> to extract credential data from the request to use it as input to the
> JCR Repository.login method. Currently Sling has an AuthenticationFilter
> which makes use of AuthenticationHandler services (only HTTP Header
> Authentication is implemented for now) to get the credentials or request
> the credentials from the client. How authentication is handled in the
> repository is completely out-of-scope for Sling.
>
> This is why I proposed to not use a filter for authentication.
>
Yes, you're right - so no filter for authentication.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: To Filter or not to Filter
Posted by Felix Meschberger <fm...@gmail.com>.
Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler:
> I agree for resource and content resolution. But I'm not sure about
> authentication. Having a filter which does the authentication is very
> transparent. If we are using the servlet filter interface for these
> filters, its easy to use other authentication mechanisms like for
> example spring authentication (aka acegi) which is based on servlet
> filters as well.
> So for now, I personally tend to go with filters except where something
> is really required for Sling core to work. There we could use an
> explicit service instead.
Not sure, whether this is the level authentication we require. Sling's
main purpose, which is also made strongly visible through the upcoming
Resource interface, is to provide a web application front-end to JCR
repositories. As such, I assume, that the JCR repository will be used
for authentication and access control purposes.
As such, the only moving target of authentication is the question on how
to extract credential data from the request to use it as input to the
JCR Repository.login method. Currently Sling has an AuthenticationFilter
which makes use of AuthenticationHandler services (only HTTP Header
Authentication is implemented for now) to get the credentials or request
the credentials from the client. How authentication is handled in the
repository is completely out-of-scope for Sling.
This is why I proposed to not use a filter for authentication.
Regards
Felix
Re: To Filter or not to Filter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> ...So for now, I personally tend to go with filters except where something
> is really required for Sling core to work. There we could use an
> explicit service instead....
I think that's a very good criteria: if something's always required by
Sling, make it a service, *and* make sure its interface exists in the
api package, to make it well visible.
I agree that authentication might be better handled by a filter, as
it's a common way of doing that.
-Bertrand
Re: To Filter or not to Filter
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi all,
>
> Currently, we love using filtering in both Sling and microsling: Every
> part of request processing is implemented using a filter. This was not
> always the case: In the days when Sling was still private, there was no
> filtering at all.
>
> Probably we must come to a mix of both: There are some tasks, which have
> to be executed all the times and there are some tasks which may or may
> not be executed. Examples of the former are authentication, proper error
> handling, resource resolution and servlet/script resolution. Examples of
> the latter are locale resolution, default setting of the response
> content type etc.
>
> So, for microsling, I propose to not implement resource resolution as a
> filter, in fact leaving default response content type setting the only
> filtering task (currently).
>
> For Sling I propose to not implement filtering for authentication
> (replace AuthenticationFilter by a service called directly),
> errorhandler (replace ErrorHandlerFilter), contentresolution (replace
> ContentResolverFilter) and component resolution (replace
> ComponentResolver). These tasks are always executed in the listed order
> by the Sling request processor. After the component is resolved the
> registered filters are called and finally the component itself is
> called.
>
> WDYT ?
>
Hmm, filters have the great advantage being very flexible. You can
combine them in any order, make them optional etc. On the other hand I
agree that some things are required for sling to work, so a filter
doesn't seem quiet right.
I agree for resource and content resolution. But I'm not sure about
authentication. Having a filter which does the authentication is very
transparent. If we are using the servlet filter interface for these
filters, its easy to use other authentication mechanisms like for
example spring authentication (aka acegi) which is based on servlet
filters as well.
So for now, I personally tend to go with filters except where something
is really required for Sling core to work. There we could use an
explicit service instead.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org