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]
