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 <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > > >
