ok. thanks for the clarification. in this case, i would avoid the auth filter as well. regards, toby
On 10/17/07, Felix Meschberger <[EMAIL PROTECTED]> 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 <[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] > > > > > > > > > -- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
