- (TODO: breadcrumb here) -

Architecture

Architecture of Sling

The following is a short list of high-lights of Sling:

*OSGi
--- The Sling application is built as a series of OSGi bundles and makes -heavy use of a number of OSGi core and compendium services.
*#Sling API
--- To implement content based Web applications with Sling, an API has -been defined, this extends the Servlet API and provides more functionality -to work on the content.
*#Request Processing
--- Sling takes a unique approach to handling requests in that a request -URL is first resolved to a resource, then based on the resource (and only -the resource) it selects the actual servlet or script to handle the -request.
*#Resources
--- The central mantra of Sling is the Resource, which represents the -resource addressed by any request URL. It is the resource that is first -resolved when handling a request. Based on the resource, a first servlet or -script is then accessed to actually handle the request.
*#Servlets and Scripts
--- Servlets and Scripts are handled uniformly in that they are -represented as resources themselves and are accessible by a resource path.
*#Launchpad
--- Sling uses a very thin launcher to integrate with an existing servlet -container, launching Sling as a Web application or providing a main class -to represent a standalone Java application.

The following sections elaborate on each of these highlights.

OSGi

OSGi - is a consortium that has developed a specification to build modular and -extensible applications. This offers [various benefits|http://www.osgi.org/About/WhyOSGi] -. We deal mainly with two parts of the specifications: The Core -Specification, which defines the OSGi Framework and Core Services, and the -Compendium Services Specification, which defines a host of services that -extend the functionality of the OSGi Framework.

OSGi Framework

The OSGi Framework is made up of three layers -- Module, Lifecycle, and -Services -- that define how extensible applications are built and deployed. -The responsibilities of the layers are:

Module --- Defines how a module, or a Bundle in OSGi-speak, is -defined. Basically, a bundle is just a plain old JAR file, whose manifest -file has some defined entries. These entries identify the bundle with a -symbolic name, a version and more. In addition there are headers which -define what a bundle provides -- Export-Package -- and what a bundle -requires to be operative -- Import-Package and Require-Bundle.
Lifecycle --- The lifecycle layer defines the states a bundle may be in -and describes the state changes. By providing a class, which implements the -BundleActivator interface and which is named in the -Bundle-Activator manifest header, a bundle may hook into the lifecycle -process when the bundle is started and stopped.
Services --- For the application to be able to interact, the OSGi Core -Specification defines the service layer. This describes a registry for -services, which may be shared.

Compendium Services

Based on the OSGi Framework specification, the Compendium Services -specification defines a (growing) number of extension services, which may -be used by applications for various tasks. Of these Compendium Services, -Sling is using just a small number:

Log Service --- Sling comes with its own implementation of the OSGi Log -Service specification. The respective bundle not only provides this -implementation, it also exports the SLF4J, Log4J and Commons Logging APIs -needed for the Sling application to perform logging.
Http Service --- Sling leverages the OSGi Http Service to hook into a -servlet container to provide the Web Application Framework mechanism.
Configuration Admin Service --- To simplify configuration of services -in Sling, the OSGi Configuration Admin service is used. This provides a -uniform API to configure services and to build configuration management -agents.
Metatype Service --- The OSGi Metatype Service defines a way to -describe the data types. Sling uses this service to describe the -configurations that may be created using the Configuration Admin Service. -These meta type descriptions are used by configuration management agents to -present to user interface to manage the configurations.
Event Admin Service --- Sling uses the OSGi EventAdmin service to -dispatch events when scheduling tasks.
Declarative Services --- One of the most important (beside the Log -Service) services used by Sling is the Declarative Services Specification. -This specification defines how to declaratively create components and -services to have the Declarative Services runtime actually manage the -lifecycle, configuration and references of components.

Sling API

The Sling API is an extension to the Servlet API which provides more -functionality to interact with the Sling framework and also to extend Sling -itself and to implement Sling applications.

See the Sling API - page for more information.

Request Processing

Traditional Web Application framework emply more or less elaborate methods -to select a Servlet or Controller based on the request URL, which in turn -tries to load some data (usually from a database) to act upon and finally -to render the result somehow.

Sling turns this processing around in that it places the data to act upon -at the center and consequently uses the request URL to first resolve the -data to process. This data is internally represented as an instance of the -Resource interface. Based on this resource as well as the request -method and more properties of the request URL a script or servlet is then -selected to handle the request.

See the Servlets - page for more information.

Resources

The Resource is one of the central parts of Sling. Extending from JCR's -Everything is Content, Sling assumes Everthing is a Resource. Thus -Sling is maintaining a virtual tree of resources, which is a merger of the -actual contents in the JCR Repository and resources provided by so called -resource providers.

Each resource has a path by which it is addressed in the resource tree, a -resource type and some resource metadata (such as file size, last -modification time). It is important to understand, that a Resource -instance actually is only a handle to the actual data. By virtue of the -adaptTo(Class) method, a resource may be coerced into another -data type, which may then be used while processing the request. Examples of -data types are javax.jcr.Node and java.io.InputStream.

See the Resources - page for more information.

Servlets and Scripts

Scripts are usually provided as content in a JCR repository. But since -Sling is using a resource tree, a script actually is represented as a -Resource and may be provided from within a Bundle (by virtue of the bundle -resource provider) or even from the platform file system (by virtue of the -file system resource provider).

Accessing scripts in the resource tree, allows for a very easy to -understand mapping from resource type to some script path.

Having found the script resource, we still need access to the appropriate -script language implementation to evaluate the script. To this avail, Sling -is making use of the Resource.adaptTo(Class) method: If a script -language implementation is available for the extension of the script name -an adaptor for the script resource can be found, which handles the -evaluation of the script.

Besides scripting languages, such as ECMAScript, Groovy, JSP, Sling also -supports regular servlets. To be able to use servlets for request -processing, such servlets must be registered as OSGi services for the -javax.servlet.Servlet interface and provide a number of service -registration properties, which are used to use the servlets. In fact -servlets thus registered as OSGi services are mapped into the resource tree -by means of a servlet resource provider. This resource provider mapps the -servlets into the resource tree using the service registration properties -to build one or more resource paths for the servlet.

As a result of mapping servlets into the resource tree and the possibility -to adapt resource to an adaptor data type, scripts and servlets may be -handled completely transparently: The servlet resolver just looks for a -resource matching the resource type and adapts the resource found to -javax.jcr.Servlet. If the resource happens to be provided by a servlet -resource provider, the adapter is of course the servlet itself. If the -resource happens to be a script, the adapter is a servlet facade which -internally calls the script language implementation to evaluate the script.

See the Servlet Resolution - page for more information.

Launchpad

Sling may be launched as a standalone application using the Sling -Application or as a Web Application running inside any Servlet API 2.4 or -newer Servlet Container.

The Sling Application is a standalone Java Application which is really -small: Just the main class and some glue classes. The OSGi framework as -well as the OSGi API libraries are packaged as a JAR file, which is loaded -through a custom classloader. This enables to update the framework and/or -OSGi API libraries from within Sling by updating the system bundle.

The Sling Servlet is equally small as the Sling Application. It uses the -Felix HttpService bridge as the glue between the servlet container and -the OSGi framework.

As we have seen, Sling may be launched as a standalone Java Application or -as a Web Application inside any compliant Servlet Container. To hide the -differences of the launching mechanism, Sling internally registers a -Servlet with an OSGi HttpService. Regardless of how Sling is launched, -the Felix implementation of the OSGi HttpService specification is used. -When Sling is launched as a standalone Java Application, Felix HttpService -uses an embedded version of the Jetty servlet container. When Sling is -launched as a Web Application, the Felix HttpService Bridge is used.

Optionally, PAX Web's implementation of HttpService can be used when Sling -is launched as a standalone Java Application. See the Maven Launchpad Plugin - page for information on how to do this.

See The Sling Launchpad - for more information.

+Home

+ +

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/assembly.html ============================================================================== --- websites/staging/sling/trunk/content/assembly.html (original) +++ websites/staging/sling/trunk/content/assembly.html Sun Apr 22 17:09:56 2012 @@ -79,254 +79,10 @@

- (TODO: breadcrumb here) +Home

Assembly

Assembly: Bundling Bundles

{panel} -The Assembly concept grew out of a need to bundle together a set of OSGi -Bundles to deploy applications. The concept has been developped before the -OSGi Deployment Package Service Specification has been published in the -Release 4.1 Compendium Services Specification. It will have to be discussed -whether the Assembly concept is dropped in favor of the Deplyoment Package -Service. -{panel}

Introduction

This chapter discusses the units of deployment as well as the units of -functionality. The following contents is based on the Module and Service -specifications of the OSGi Service Platform Core Specification, Release 4 -but enhances functionality for ease of use and in terms of best practices.

The term Units of Deployment describes the idea of packaging up -functionality implemented by Java Classes into modules, so called -Bundles. For bigger and more complicated applications the fine grained -modularity of Bundles may be to complicated, so this chapter proposes an -extension called Assembly. The goal of the Assembly specification -presented below is to provide functionality to delivery a collection of -bundles belonging together.

The term Units of Functionality describes the idea of providing services -implemented by Java Classes, so called Services. A Service is an -abstraction and does not actually prescribe the implementation of specific -interfaces. Instead the OSGi specification states how functionality may be -provided to clients by registering objects implementing interfaces defining -the functionality in terms of a Java API.

Bundles

The core unit of deployment is the Bundle. The OSGi core specification -defines a Bundle to be a Java Archive (JAR) file whose manifest - the -META-INF/MANIFEST.MF file - contains specific headers identifying the -bundle. Most manifest headers are optional with defined default values - -only the Bundle-SymbolicName header is actually required and the -Bundle-ManifestVersion header should be set to 2 to identify the -bundle to be a R4 bundle. Other information defined in the manifest is the -bundle version, the list of packages exported - provided to other bundles - -and imported - used and required to be provided by other bundles. See -chapter 3.2.1 Bundle Manifest Header of the OSGi Service Platform Core -Specification for a complete list of the defined bundle manifest headers.

Bundles may be installed, updated , started, stopped and removed in an OSGi -framework individually.

Assemblies

For the deployment of bigger systems, the number of bundles may increase -very quickly. To ease the management of products consisting of multiple -bundles, this chapter introduces the Assembly. An Assembly is simply a -collection of bundles deployed together. An Assembly - like a Bundle - is a -JAR file whose manifest contains specific headers. In fact, an Assembly is -just a standard bundle, with additional functionality.

Assemblies are managed by the Assembly Manager which itself is a bundle -installed into the framework.

Assembly manifest headers

As an Assembly is a standard Bundle, all the defined Bundle manifest -headers may be specified. In addition, for the Assembly Manager to -recognize an assembly and for the OSGi Bundle Repository to support -dependency resolution, the following manifest headers are defined. All -headers are optional with documented default values except where noted.

Assembly-Bundles - The list of bundles contained in this assembly. See -below for the definition of the syntax of this header. This header is -required. The presence of this headers identifies an Assembly to the -Assembly Manager.
Assembly-BundleRepository - A comma-separated list of URLs pointing to -OSGi Bundle Repository descriptors. These bundle repositories will be used -to install bundles listed in the Assembly-Bundles header. This header -is optional with not default value.

Assembly Lifecycle

An Assembly, like all bundles, may be in any of the defined bundle states:

Installed - The Assembly bundle has been installed into the system but -not yet resolved. The Assembly Manager will try to install all bundles -listed in the Assembly-Bundles header. The start levels of the bundles -will be set according to the startlevel parameter. The bundles will not -be started. If installation of one or more of the bundles fails, Assembly -Manager logs an error message.
Resolved - The Assembly bundle is resolved, that is all imported -packages are wired into the framework. The Assembly Manager does not -handle this state change, rather the installed bundles will be resolved by -the framework either automatically after installation or when started -later.
Started - The Assembly bundle has been started by calling the -Bundle.start() method. The Assembly Manager will start all newly -installed and resolved bundles. Depending on the start level set on the -bundle(s) and the current system start level, the bundles will only be -permanently marked to start while actually starting the bundles may be -delayed until the system enters the respective start level. If any bundle -fails to start, an error message is logged.
Stopped - The Assembly bundle has been stopped by calling the -Bundle.stop() method. All bundles belong to the Assembly and linked to -the Assembly are also stopped.
Unresolved - The Assembly bundle has been unresolved by the system for -any reason, possibly any missing dependencies. Assembly bundles entering -this state are ignored by the Assembly Manager.
Uninstalled - The Assembly bundle is being uninstalled by calling the -Bundle.uninstall() method. The Assembly Manager will (try to) -uninstall all bundles listed in the Assembly-Bundles header.
Updated - The Assembly bundle will update all bundles installed -previously according to the Assembly-Bundles header. If this header -omits any bundle listed in the previous bundle version, the respective -bundle is uninstalled from the system. If a bundle is already installed -with the correct version, the installed bundle is not touched (It may -though be uninstalled together with the Assembly Bundle if the Assembly -Bundle is uninstalled).

Bundles referenced by multiple Assembly Bundles

It is conceivable, that bundles are listed in the Assembly-Bundles -header of more than one Assembly Bundle. If this is the case, the following -collision resolution takes place:

If the version of the bundle installed by the first Assembly bundle -handled matches the version specification of any later Assembly Bundle, the -installed bundle is not touched. Otherwise, if the later Assembly Bundle -lists a version specification, which is acceptable for the first Assembly -Bundle, the installed bundle is updated to the required version. If the -version specifications may not be matched one way or the other, the later -Assembly Bundle fails to install.
If the bundle is installed with a defined start level, the later -Assembly Bundle will not overwrite the already set start level. If the -start level has not been set yet it is set to the specified start level.
Bundles installed through Assembly Bundles remain installed as long as -there is at least one Assembly Bundle listing the bundle in the -Assembly-Bundles header. As soon as there is no referring Assembly -Bundle anymore, the bundle is uninstalled.
Bundles not referred to by any Assembly Bundle are ignored by the -Assembly Manager.
Bundles installed through the Assembly Manager may be updated and/or -uninstalled independently from their defining Assembly Bundle. If a bundle -has been installed it will be reinstalled the next time the Assembly Bundle -enters the installed state. If a bundle has been updated, it is not -touched by the Assembly Manager as long as the updated version matches -the version specification of the Assembly Bundle.

Bundle Installation

When an Assembly is installed into the framework, the Assembly Manager -checks to see whether the Assembly needs to be deployed. This is done by -checking the bundles listed in the Assembly-Bundles header whether they -are installed or not. All bundles not installed will be installed and -started if requested so.

The following BNF defines the syntax =Assembly-Bundles= header value:

Assembly-Bundles = Bundle { "," Bundle } .
-Bundle = Symbolic-Name { ";" Parameter } .
-Symbolic-Name = // The Bundle symbolic name 
-Parameter = ParameterName "=" ParameterValue .
-

+ - -

To control the selection and installation of bundles, the following -parameters may be used:

version - The version of the bundle to install. This is a version range -specification as per chapter 3.2.5 Version Ranges of the OSGi core -specification. When this parameter is declared as a single version - eg. -1.2.3 - it is interpreted as the version range ~[1.2.3, ∞~). The -default value is ~[0.0.0,∞~) to install the most recent version of -the bundle available.
startlevel - The start level to set for the bundle. This may be any -positive integer value. Default value is undefined to use the current -initial bundle start level of the framework.
entry - The path of the Assembly Bundle entry providing the data to be -installed.
linked - Defines whether the bundle should be started and stopped -together with the Assembly to which the bundle belongs. Default value is -true.

If resolving the bundles results in more bundles to be downloaded from the -bundle repository to resolve the dependency, these bundles are always -automatically started and assigned a startlevel which is smaller than the -smallest startlevel of any of the bundles listed.

Bundle Location

Generally bundles to be installed with an Assembly Bundle are retrieved -from an OSGi Bundle Repository. The Assembly-BundleRepository header -may list additional URLs which will be temporarily used to resovle the -bundles. Otherwise the system default bundle repositories will be used -only.

If a bundle is defined in the Assembly-Bundles header with an entry -parameter, the respective entry is first looked for in the Assembly Bundle. -If the entry exists, it is used as the bundle source to install. If no -entry parameter is present for a declared bundle or the entry is -missing, the OSGi Bundle Repository is used.

Restrictions when packaging bundles with the Assembly:

Dependency Resolution - Any missing dependencies of the bundles to be -installed will not be resolved. That is, if the bundles fail to resolve, -the Assembly fails to install.
version Parameter - The version parameter of the bundle -installation declaration is ignored because any JAR file whose name matches -the bundle symbolic name to be installed, is installed.

If the Assembly-BundleRepository header contains a comma-separated list -of URL to OSGi Bundle Repository descriptors and the OSGi Bundle Repository -Service is available in the framework, the bundles declared in the -Assembly-Bundles header are resolved through the OSGi Bundle Repository -Service using the URL from the Assembly-BundleRepository header.

If the bundles declare any dependencies, which may not be resolved by -bundles already installed in the framework or by any of the bundles to be -installed, the OSGi Bundle Repository is used to try to resolve these -missing dependencies. If this resolution succeeds, installation of the -Assembly succeeds. Any bundles not declared in the Assembly but installed -due to this dependency resolution will not be assumed to belong to the -Assembly. Hence, these bundles will not be uninstalled (or updated) if the -Assembly is uninstalled (or updated).

Example - Assume the Assembly-Bundles header is set to -org.apache.sling.sample1;entry=path.jar,org.apache.sling.sample2. The -bundle org.apache.sling.sample1 is then installed from the Assembly -Bundle entry path.jar, while the bundle org.apache.sling.sample2 is -resolved in the OSGi Bundle Repository.

Best Practices

Size of Bundles

There is no fixed formula to calculate the best size for a bundle: It all -depends on the contents and the intentions of the bundle and its -programmer. The following list provides some hints:

For ease of development follow the idea of One Bundle - One Project
Don't pack too much into a bundle but do not pack a single class into -a bundle (unless you have a very good reason of course :-) )
Do not mix and match everything into a bundle. Rather bundle things -together which belong together, for example create separate bundles for a -HTTP Client implementation and DB support classes
Use similar heuristics to decide on the contents of a bundle as you -would for the contents of a plain old JAR file.

Nomen est Omen

The symbolic name of a bundle should reflect its contents. A bundle should -generally only contain a single subtree in the virtual package tree. The -symbolic name of the bundle should be the root package contained within. -For example, consider a bundle containing the packages -org.apache.sling.sample, org.apache.sling.sample.impl, -org.apache.sling.more. The bundle would the be named -org.apache.sling.sample.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/authentication---actors.html ============================================================================== --- websites/staging/sling/trunk/content/authentication---actors.html (original) +++ websites/staging/sling/trunk/content/authentication---actors.html Sun Apr 22 17:09:56 2012 @@ -79,112 +79,10 @@

- (TODO: breadcrumb here) -

Authentication - Actors

Actors

{excerpt}The authentication process involves a number of actors -contributing to the concepts, the API and the particular -implementations.{excerpt}

OSGi Http Service Specification

The main support for authentication is defined by the OSGi Http Service -specification. This specification defines how an OSGi application can -register servlets and resources to build web applications. As part of the -servlet and/or resource registration a HttpContext may be provided, -which allows for additional support.

The main method of interest to the authentication process is the -handleSecurity method. This is called by the OSGi Http Service -implementation before the registered servlet is called. Its intent is to -authenticate the request and to provide authentication information for the -request object: the authentication type and the remote user name.

The Sling Commons Auth bundle provides the AuthenticationSupport -service which may be used to the implement the -HttpContext.handleSecurity method.

Sling Engine

The Sling Engine implements the main entry point into the Sling system by -means of the SlingMainServlet. This servlet is registered with the OSGi -Http Service and provides a custom HttpContext whose handleSecurity -method is implemented by the AuthenticationSupport service.

When the request hits the service method of the Sling Main Servlet, the -resource resolver provided by the AuthenticationSupport service is -retrieved from the request attributes and used as the resource resolver for -the request.

That's all there is for the Sling Engine to do with respect to -authentication.

Sling Commons Auth

The support for authenticating client requests is implemented in the Sling -Commons Auth bundle. As such this bundle provides three areas of support

AuthenticationHandler service interface. This is implemented by -services providing functionality to extract credentials from HTTP requests.
Authenticator service interface. This is implemented by the -SlingAuthenticator class in the Commons Auth bundle and provides -applications with entry points to login and logout.
AuthenticationSupport service interface. This is implemented by the -SlingAuthenticator class in the Commons Auth bundle and allows -applications registering with the OSGi HTTP Service to make use of the -Sling authentication infrastructure.

JCR Repository

The actual process of logging into the repository and provided a -Session is implementation dependent. In the case of Jackrabbit -extensibility is provided by configuration of the Jackrabbit repository by -means of an interface and two helper classes:

LoginModule -- The interface to be implemented to provide login -processing plugins
AbstractLoginModule -- A an abstract base class implementation of -the LoginModule interface.
DefaultLoginModule -- The default implementation of the -AbstractLoginModule provided by Jackabbit. This login module takes -SimpleCredentials and uses the repository to lookup the users, validate -the credentials and providing the Principal representing the user -towards the repository.

The Sling Jackrabbit Embedded Repository bundle provides additional plugin -interfaces to extend the login process dynamically using OSGi services. To -this avail the bundle configures a LoginModule with the provided -default Jackrabbit configuration supporting these plugins:

LoginModulePlugin -- The main service interface. Plugins must -implement this interface to be able to extend the login process. See for -example the Sling OpenID authentication handler -, which implements this interface to support OpenID authentication.
AuthenticationPlugin -- Helper interface for the -LoginModulePlugin.

Sling Applications

Sling Applications requiring authenticed requests should not care about how -authentication is implemented. To support such functionality the -Authenticator service is provided with two methods:

-
login -- allows the application to ensure requests are -authenticated. This involves selecting an AuthenticationHandler to -request credentials for authentication.
-
-
logout -- allows the application to forget about any -authentication. This involves selecting an AuthenticationHandler to -forget about credentials in the request.
-

Sling Applications should never directly use any knowledge of any -authentication handler or directly call into an authentication handler. -This will certainly break the application and cause unexpected behaviour.

{info} -If you want to know whether a request is authenticated or not, you can -inspect the result of the HttpServletRequest.getAuthType method: If -this method returns null the request is not authenticated. -{info}

+Home

+ +

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/authentication---authenticationhandler.html ============================================================================== --- websites/staging/sling/trunk/content/authentication---authenticationhandler.html (original) +++ websites/staging/sling/trunk/content/authentication---authenticationhandler.html Sun Apr 22 17:09:56 2012 @@ -79,99 +79,10 @@

- (TODO: breadcrumb here) +Home

Authentication - AuthenticationHandler

AuthenticationHandler

{excerpt}The AuthenticationHandler interface defines the service API -which may be implemented by authentication handlers registered as OSGi -services.{excerpt}

AuthenticationHandler services have a single required service -registration property which is used to identify requests to which the -AuthenticationHandler service is applicable:

- - - -

*path*

One or more (array or vector) string values indicating the -request URLs to which the *AuthenticationHandler* is applicable.

*authtype*

The authentication type implemented by this handler. This -is a string value property and should be the same as will be used as the -authentication type of the *AuthenticationInfo* object provided by the -*extractCredentials* method. If this property is set, the -*requestCredentials* method of the authentication handler is only called -if the *sling:authRequestLogin* request parameter is either not set or is -set to the same value as the *authtype* of the handler. This property is -optional. If not set, the *requestCredentials* method is always called -regardless of the value of the *sling:authRequestLogin* request -parameter.

+ -

Each path may be an absolute URL, an URL with just the host/port and path -or just a plain absolute path:

- - - - - -

URL part	Scheme	Host/Port	Path
Absolute URL	must match	must match	request URL path is prefixed -with the path
Host/Port with Path	ignored	must match	request URL path is prefixed -with the path
Path	ignored	ignored	request URL path is prefixed with the path

- -

When looking for an AuthenticationHandler the authentication handler is -selected whose path is the longest match on the request URL. If the service -is registered with Scheme and Host/Port, these must exactly match for the -service to be eligible. If multiple AuthenticationHandler services are -registered with the same length matching path, the handler with the higher -service ranking is selected{footnote}Service ranking is defined by the OSGi -Core Specification as follows: If multiple qualifying service interfaces -exist, a service with the highest service.ranking number, or when equal -to the lowest service.id, determines which service object is returned -by the Framework.{footnote}.

The value of path service registration property value triggering the -call to any of the AuthenticationHandler methods is available as the -path request attribute (for the time of the method call only). If the -service is registered with multiple path values, the value of the path -request attribute may be used to implement specific handling.

Implementations provided by Sling

Sample implementations

HTTP Basic Authentication Handler

extractCredentials -- Get user name and password from the -Authorization HTTP header
requestCredentials -- Send a 401/UNAUTHORIZED status with -WWW-Authenticate response header setting the Realm
dropCredentials -- Send a 401/UNAUTHORIZED status with -WWW-Authenticate response header setting the Realm

Interestingly the dropCredentials method is implemented in the same way -as the requestCredentials method. The reason for this is, that HTTP -Basic authentication does not have a notion of login and logout. Rather the -request is accompanied with an Authorization header or not. The -contents of this header is usually cached by the client browser. So logout -is actually simulated by sending a 401/UNAUTHORIZED status thus causing the -client browser to clear the cache and ask for user name and password.

Form Based Authentication Handler

extractCredentials -- Get user name and password with the help of a -special cookie (note, that of course the cookie should not contain this -data, but refer to it in an internal store of the authentication handler). -If the cookie is not set, check for specific login parameters to setup the -cookie.
requestCredentials -- Send the login form for the user to provide the -login parameters.
dropCredentials -- Clear the authentication cookie and internal -store.

{display-footnotes}

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/authentication---framework.html ============================================================================== --- websites/staging/sling/trunk/content/authentication---framework.html (original) +++ websites/staging/sling/trunk/content/authentication---framework.html Sun Apr 22 17:09:56 2012 @@ -79,229 +79,10 @@

- (TODO: breadcrumb here) +Home

Authentication - Framework

Framework

{excerpt}The core piece of functionality with respect to authentication in -Sling is contained in the Sling Commons Auth bundle. This bundle provides -the API for Sling and Sling applications to make use of -authentication.{excerpt}

This support encompasses three parts:

The AuthenticationSupport service provided by the -SlingAuthenticator class. This service can be used by implementations -of the OSGi HttpContext interface to delegate authentication.
The Authenticator service also provided by the -SlingAuthenticator class. This service may be used by Sling -Applications to help clients login and logout.
The AuthenticationHandler service interface. These services may be -implemented by extensions to support various ways for transporting -credentials from clients to the Sling server.

This page describes how the SlingAuthenticator class provides the -AuthenticationSupport and Authenticator services. For a -description of the AuthenticationHandler service interface and the -interaction between the SlingAuthenticator and the -AuthenticationHandler services refer to the AuthenticationHandler - page.

The SlingAuthenticator class is an internal class of the -org.apache.sling.commons.auth bundle and implements the -Authenticator and AuthenticationSupport services.

AuthenticationSupport

The AuthenticationSupport service interface defines a single method: -handleSecurity. This method is intended to be called by the -handleSecurity method of any HttpContext implementation wishing to -make use of the Sling Authentication Framework.

The Sling Authenticator implementation selects an AuthenticationHandler -service appropriate for the request and calls the -AuthenticationHandler.extractCredentials method to extract the -credentials from the request. If no credentials could be extracted, the -Sling Authenticator either admits the request as an anonymous request or -requests authentication from the client by calling its own login -method.

The implementation follows this algorithm:

Select one or more AuthenticationHandler for the request according -to the request URL's scheme and authorization part.
Call the extractCredentials method of each authentication handler, -where the order of handler call is defined by the length of the registered -path: handlers registered with longer paths are called before handlers with -shorter paths. The goal is to call the handlers in order from longest -request path match to shortest match. Handlers not matching the request -path at all are not called.
The first handler returning a non-null AuthenticationInfo -result "wins" and the result is used for authentication.
If any AuthenticationInfoPostProcessor services are registered, the -AuthenticationInfo object is passed to their postProcess() method.
If no handler returns a non-null result, the request may be handled -anonymously. In these cases, an empty AuthenticationInfo object is -passed to any AuthenticationInfoPostProcessor services.
(Try to) log into the repository either with the provided credentials -or anonymously.
If there were credentials provided and the login was successful, a -login event is posted if the AuthenticationInfo object contains a -non-null object with the key $$auth.info.login$$ -(AuthConstants.AUTH_INFO_LOGIN). This event is posted with the topic -org/apache/sling/auth/core/Authenticator/LOGIN. (added in Sling Auth -Core 1.1.0)
Set request attributes listed below.

Extracting the credentials and trying to login to the repository may yield -the following results:

- - - - - - -

Credentials	Login	Consequence
present	successfull	Continue with an authenticated request
present	failed	Select AuthenticationHandler and call -requestCredentials method
missing	anonymous allowed	Continue with a non authenticated request -using anonymous access to the repository
missing	anonymous forbidden	Select AuthenticationHandler and call -requestCredentials method

+ -

{note} -Only one AuthenticationHandler is able to provide credentials for a -given request. If the credentials provided by the handler cannot be used to -login to the repository, authentication fails and no further -AuthenticationHandler is consulted. -{note}

- -

The handleSecurity method gets credentials from the -AuthenticationHandler and logs into the JCR repository using those -credentials. If the login is successful, the SlingAuthenticator sets -the following request attributes:

- - - - - - - -

Attribute	Description
org.osgi.service.http.authentication.remote.user	The user ID of the -JCR Session. This attribute is used by the HTTP Service implementation to -implement the HttpServletRequest.getRemoteUser method.
org.osgi.service.http.authentication.type	The authentication type -defined by the AuthenticationHandler. This attribute is used by the -HTTP Service implementation to implement the -HttpServletRequest.getAuthType method.
org.apache.sling.commons.auth.ResourceResolver	The -ResourceResolver created from the credentials and the logged in JCR -Session. This attribute may be used by servlets to access the repository. -Namely the SlingMainServlet uses this request attribute to provide the -ResourceResolver to handle the request.
javax.jcr.Session	The JCR Session. This attribute is for backwards -compatibility only. Its use is deprecated and the attribute will be -removed in future versions.
org.apache.sling.commons.auth.spi.AuthenticationInfo	The -AuthenticationInfo object produced from the AuthenticationHandler. -

- -

NOTE: Do NOT use the javax.jcr.Session request attribute in your -Sling applications. This attribute must be considered implementation -specific to convey the JCR Session to the SlingMainServlet. In future -versions of the Sling Commons Auth bundle, this request attribute will not -be present anymore. To get the JCR Session for the current request adapt -the request's resource resolver to a JCR Session:

Session session = request.getResourceResolver().adaptTo(Session.class);
-

- - -

- -

The SlingAuthenticator provides high level of control with respect to -allowing anonymous requests or requiring authentication up front:

Global setting of whether anonymous requests are allowed or not. This is -the value of the Allow Anonymous Access (auth.annonymous) property of -the SlingAuthenticator configuration. This property is supported for -backwards compatibility and defaults to true (allowing anonymous -access).
Specific configuration per URL. The Authentication Requirements -(sling.auth.requirements) property of the SlingAuthenticator -configuration may provide a list of URLs for which authentication may be -required or not: Any entry prefixed with a dash - defines a subtree for -which authentication is not required. Any entry not prefixed with a dash or -prefixed with a plus + defines a subtree for which authentication is -required up front and thus anonymous access is not allowed. This list is -empty by default.
Any OSGi service may provide a sling.auth.requirements registration -property which is used to dynamically extend the authentication -requirements from the Authentication Requirements configuration. This may -for example be set by AuthenticationHandler implementations providing a -login form to ensure access to the login form does not require -authentication. The value of this property is a single string, an array of -strings or a Collection of strings and is formatted in the same way as the -Authentication Requirements configuration property.

The URLs set on the Authentication Requirements configuration property or -the sling.auth.requirements service registration property can be -absolute paths or URLs like the path service registration property of -AuthenticationHandler services. This allows the limitation of this -setup to certain requests by scheme and/or virtual host address.

Examples

-
The LoginServlet contained in the Commons Auth bundle registers -itself with the service registration property {{sling.auth.requirements = -"-/system/sling/login"}} to ensure the servlet can be accessed without -requiring authentication.
-
-
An authentication handler may register itself with the service -registration property {{sling.auth.requirements = -"-/apps/sample/loginform"}} to ensure the login form can be rendered -without requiring authentication.
-

Authenticator implementation

The implementation of the Authenticator interface is similar for both -methods:

login

Select one or more AuthenticationHandler for the request according -to the request URL's scheme and authorization part.
Call the requestCredentials method of each authentication handler, -where the order of handler call is defined by the length of the registered -path: handlers registered with longer paths are called before handlers with -shorter paths. The goal is to call the handlers in order from longest -request path match to shortest match. Handlers not matching the request -path at all are not called.
As soon as the first handlers returns true, the process ends and it -is assumed credentials have been requested from the client.

The login method has three possible exit states:

- - - - - -

Exit State	Description
Normal	An AuthenticationHandler could be selected to which the -login request could be forwarded.
NoAuthenticationHandlerException	No AuthenticationHandler could -be selected to forward the login request to. In this case, the caller can -proceed as appropriate. For example a servlet, which should just login a -user may send back a 403/FORBIDDEN status because login is not possible. Or -a 404/NOT FOUND handler, which tried to login as a fallback, may continue -and send back the regular 404/NOT FOUND response.
IllegalStateException	The response has already been committed and -the login request cannot be processed. Normally to request login, the -current response must be reset and a new response has to be prepared. This -is only possible if the request has not yet been committed.

- -

logout -1. Select one or more AuthenticationHandler for the request according -to the request URL's scheme and authorization part. -1. Call the dropCredentials method of each authentication handler, -where the order of handler call is defined by the length of the registered -path: handlers registered with longer paths are called before handlers with -shorter paths. The goal is to call the handlers in order from longest -request path match to shortest match. Handlers not matching the request -path at all are not called.

Unlike for the login method in the logout method case all -AuthenticationHandler services selected in the first step are called. -If none can be selected or none can actually handle the dropCredentials -request, the logout silently returns.

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/authentication---tasks.html ============================================================================== --- websites/staging/sling/trunk/content/authentication---tasks.html (original) +++ websites/staging/sling/trunk/content/authentication---tasks.html Sun Apr 22 17:09:56 2012 @@ -79,43 +79,10 @@

- (TODO: breadcrumb here) -

Authentication - Tasks

Tasks

{excerpt}Authentication of HTTP Requests is generally a two-step process: -First the credentials must be extracted from the request and second the -credentials must be validated. In the case of Sling this means acquiring a -JCR Session.{excerpt}

Extract Credentials from the Request

Implemented and controlled by the Sling Commons Auth bundle
Takes HttpServletRequest
Provides credentials for futher processing (basically JCR -Credentials and Workspace name)
Extensible with the help of AuthenticationHandler services

- -

Implemented and controlled by the JCR Repository
Takes JCR Credentials and Workspace name
Provides a JCR Session
Implementation dependent process. Jackrabbit provides extensibility -based on LoginModules; Sling's Embedded Jackrabbit Repository bundle -provides extensibility with LoginModulePlugin services.

Currently the credentials are always verified by trying to login to the JCR -repository. Once an ResourceResolverFactory - API has been added, the process of validating the credentials and logging -in is actualy replaced by a process of requesting a ResourceResolver -from the ResourceResolverFactory. Of course, the JCR Repository will -still be the main underlying repository and as such be used to validate the -credentials and get a JCR Session.

+Home

+ +

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/authentication.html ============================================================================== --- websites/staging/sling/trunk/content/authentication.html (original) +++ websites/staging/sling/trunk/content/authentication.html Sun Apr 22 17:09:56 2012 @@ -79,83 +79,10 @@

- (TODO: breadcrumb here) -

Authentication

{excerpt:hidden=true} -How requests are authenticated. -{excerpt}

This section describes the framework provided by Sling to authenticate HTTP -requests.

Let's look at generic request processing of Sling: Sling is linked into the -outside world by registering the Sling Main Servlet -- implemented by the -SlingMainServlet class in the Sling Engine bundle -- with an OSGi -HttpService. This registration is accompanyied with an implementation -instance of the OSGi HttpContext interface, which defines a method to -authenticate requests: handleSecurity.

This method is called by the OSGi HTTP Service implementation after the -servlet has been selected to handle the request but before actually calling -the servlet's service method.

{section} -{column} -!authentication.png|thumbnail! -{column} -{column} -1. First the OSGi HTTP Service implementation is analyzing the request URL -to find a match for a servlet or resource registered with the HTTP Service. -1. Now the HTTP Service implementation has to call the handleSecurity -method of the HttpContext object with which the servlet or resource has -been registered. This method returns true if the request should be -serviced. If this method returns false the HTTP Service implementation -terminates the request sending back any response which has been prepared by -the handleSecurity method. Note, that the handleSecurity method -must prepare the failure response sent to the client, the HTTP Service adds -nothing here. If the handleSecurity method is successful, it must add -two (or three) request attributes described below. -1. When the handleSecurity method returns true the HTTP Service -either calls the Servlet.service method or sends back the requested -resource depending on whether a servlet or a resource has been selected in -the first step. -{column} -{section}

The important thing to note here is, that at the time the -handleSecurity method is called, the SlingMainServlet is not yet in -control of the request. So any functionality added by the -SlingMainServlet, notably the SlingHttpServletRequest and -SlingHttpServletResponse objects are not available to the -implementation of the handleSecurity method.

The following pages describe the full details of request authentication in -Sling in full detail:

-
-
Tasks
-
{excerpt-include:Authentication - Tasks|nopanel=true}
-
-
-
-
Actors
-
{excerpt-include:Authentication - Actors|nopanel=true}
-
-
-
-
Framework
-
{excerpt-include:Authentication - Framework|nopanel=true}
-
-
-
-
AuthenticationHandler
-
{excerpt-include:Authentication - AuthenticationHandler|nopanel=true}
-
-

+Home

+ +

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/bundles.html ============================================================================== --- websites/staging/sling/trunk/content/bundles.html (original) +++ websites/staging/sling/trunk/content/bundles.html Sun Apr 22 17:09:56 2012 @@ -79,52 +79,10 @@

- (TODO: breadcrumb here) +Home

Bundles

Content

* [Content Loading (jcr.contentloader)](content-loading-(jcr.contentloader).html)
-* [Internationalization Support (i18n)](internationalization-support-(i18n).html)
-* [Manipulating Content - The SlingPostServlet (servlets.post)](manipulating-content---the-slingpostservlet-(servlets.post).html)
-

+ - -

Resource Providers

* [Accessing Filesystem Resources (extensions.fsresource)](accessing-filesystem-resources-(extensions.fsresource).html)
-* [Bundle Resources (extensions.bundleresource)](bundle-resources-(extensions.bundleresource).html)
-

- - -

Users, Groups, Access, Permissions

* [Managing users and groups (jackrabbit.usermanager)](managing-users-and-groups-(jackrabbit.usermanager).html)
-* [Managing permissions (jackrabbit.accessmanager)](managing-permissions-(jackrabbit.accessmanager).html)
-

- - -

Installer

* [OSGi Installer](osgi-installer.html)
-* [JCR Installer Provider](jcr-installer-provider.html)
-

- - -

Misc

* [Commons Thread Pools](slingxsite:apache-sling-commons-thread-pool.html)
-* [Commons HTML Utilities](commons-html-utilities.html)
-* [MIME Type Support (commons.mime)](mime-type-support-(commons.mime).html)
-* [Output Rewriting Pipelines (org.apache.sling.rewriter)](output-rewriting-pipelines-(org.apache.sling.rewriter).html)
-* [Sling Settings (org.apache.sling.settings)](sling-settings-(org.apache.sling.settings).html)
-* [Scheduler Service (commons scheduler)](scheduler-service-(commons-scheduler).html)
-* [Web Console Extensions (org.apache.sling.extensions.webconsolebranding, org.apache.sling.extensions.webconsolesecurityprovider)](web-console-extensions.html)
-

Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. Modified: websites/staging/sling/trunk/content/client-request-logging.html ============================================================================== --- websites/staging/sling/trunk/content/client-request-logging.html (original) +++ websites/staging/sling/trunk/content/client-request-logging.html Sun Apr 22 17:09:56 2012 @@ -79,200 +79,10 @@

- (TODO: breadcrumb here) +Home

Client Request Logging

Sling provides extensive support to log various information at the before -and after processing client requests. Out of the box, there are two loggers -configured to write traditional access.log and request.log files. -In addition more logging can be configured by providing OSGi Configuration -Admin configuration.

Traditional access.log and request.log Files

In the Web Console configure the Apache Sling Request Logger -(PID=org.apache.sling.engine.impl.log.RequestLogger) configuration.

In the Sling Web Console locate the Configuration page -(/system/console/configMgr) and click on the + (plus) symbol on the -Apache Sling Customizable Request Data Logger line. This opens a dialog -to enter the configuration whose properties can be configured as follows:

- - - - - - - - -

Parameter	Name	Default
Request Log Name	request.log.output	Name of the destination for the request log. The request log logs the entry and exit of each request into and out of the system together with the entry time, exit time, time to process the request, a request counter as well as the final status code and response content type. In terms of Request Logger Service formats, request entry is logged with the format {{%t \[%R](%r.html) - \-> %m %U%q %H}} and request exit is logged with the format {{%\{end}t -\[%R] <\- %s %\{Content-Type}o %Dms}} (See [#Log Format Specification] - below for the specification of the format).
Request Log Type	request.log.outputtype	Type of Logger named with -the Logger Name parameter. See [#Log Output](#log-output.html) - below
Enable Request Log	request.log.enabled	Whether to enable Request -logging or not.
Access Log Name	access.log.output	Name of the destination for the -access log. The access log writes an entry for each request as the request -terminates using the NCSA extended/combined log format. In terms of Request -Logger Service formats the access log is written with the format {{%h %l %u -%t "%r" %>s %b "%\{Referer}i" "%\{User-Agent}i"}} (See [#Log Format Specification](#log-format-specification.html) - below for the specification of the format).
Access Log Type	access.log.outputtype	Type of Logger named with -the Logger Name parameter. See [#Log Output](#log-output.html) - below
Enable Access Log	access.log.enabled	Whether to enable Access -logging or not.

+ -

Log Output

Output of client request logging is defined by the Logger Type and and -Logger Name where the use of the Logger Name property value depends on the -Logger Type:

- - - - - -

Type Code	Type Name	Description and Logger Name interpretation
0	Logger Name	Writes the logging information to a named SLF4J Logger. -The name of the Logger is defined in the Logger Name property. The actual -destination of the log messages is defined the SLF4J configuration for the -named logger
1	File Name	Writes the logging information to a file, on message per -line. The file name is an absolute or relative path name. If the name is -relative, it is resolved against the sling.home framework property.
2	RequestLog Service	Sends the logging information to a -org.apache.sling.engine.RequestLog service whose requestlog.name -service registration property must the same as the value of the Logger Name -property. If more than one such service is registered, all services are -called. If no such service is registered, the logging information is -discarded. Using RequestLog Services is deprecated.

- -

Note: If logging to a file, this file is not rotated and/or limited by -size. To get log file rotation use the Logger Name logging type. See #Rotating Logger Files - below for information on how logging information can be written to rotated -and/or size limited files.

Additional per-request Loggers

In the Web Console create Apache Sling Customizable Request Data Logger -(Factory PID=org.apache.sling.engine.impl.log.RequestLoggerService) -configuration.

- - - - - - -

Parameter	Name	Default	Description
Log Format	request.log.service.format	Specify a [#Log Format Specification](#log-format-specification.html) - as described below
Logger Type	request.log.service.outputtype	Logger Name/0	-Type of Logger named with the Logger Name parameter. See [#Log Output](#log-output.html) - above
Logger Name	request.log.service.output	request.log	Name of -the Logger to be used. See [#Log Output](#log-output.html) - above
Request Entry	request.log.service.onentry	unchecked/false	-Whether logger is called at the start of request processing or after -processing the request

- -

Log Format Specification

The log format specification follows the definition of the format argument for the LogFormat and CustomLog directives of Apache httpd -:

The characteristics of the request itself are logged by placing "%" -directives in the format string, which are replaced in the log file by the -values as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Format String	Description
%%	The percent sign
%a	Remote IP-address
%A	Local IP-address
%B	Size of response in bytes, excluding HTTP headers.
%b	Size of response in bytes, excluding HTTP headers. In CLF -format, i.e. a '-' rather than a 0 when no bytes are sent.
%\{Foobar}C	The contents of cookie Foobar in the request sent to -the server.
%D	The time taken to serve the request, in microseconds.
%\{FOOBAR}e	Not supported in Sling; prints nothing.
%f	The absolute path of the resolved resource
%h	Remote host
%H	The request protocol
%\{Foobar}i	The contents of Foobar: header line(s) in the request -sent to the server.
%k	Not supported in Sling; prints nothing.
%l	Not supported in Sling; prints nothing.
%m	The request method
%\{Foobar}n	Not supported in Sling; prints nothing.
%\{Foobar}o	The contents of Foobar: header line(s) in the reply.
%p	The canonical port of the server serving the request
%\{format}p	The canonical port of the server serving the request -or the server's actual port or the client's actual port. Valid formats are -canonical, local, or remote.
%P	The _name of the thread_ -process ID of the child- that -serviced the request.
%\{format}P	Same as %P; the format parameter is ignored.
%q	The query string (prepended with a ? if a query string exists, -otherwise an empty string)
%r	First line of request
%R	The number of requests processed by Sling since the last start. -
%s	Status.
%t	Time the request was received (standard english format)
%\{format}t	Same as %t; the format parameter is ignored -unless it is the literal value _end_ indicating to use the time of request -terminating (instead of the time of request receipt).
%T	The time taken to serve the request, in seconds.
%u	Remote user (from auth; may be bogus if return status (%s) is -401)
%U	The URL path requested, not including any query string.
%v	The canonical ServerName of the server serving the request.
%V	Same as %v.
%X	Not supported in Sling; prints nothing.
%I	Not supported in Sling; prints nothing.
%O	Not supported in Sling; prints nothing.

- -

Modifiers

Particular items can be restricted to print only for responses with -specific HTTP status codes by placing a comma-separated list of status -codes immediately following the "%". For example, "%400,501{User-agent}i" -logs User-agent on 400 errors and 501 errors only. For other status codes, -the literal string "-" will be logged. The status code list may be preceded -by a "!" to indicate negation: "%!200,304,302{Referer}i" logs Referer on -all requests that do not return one of the three specified codes.

The Apache httpd modifiers "<" and ">" are not supported by Sling and -currently ignored.

Some Notes

For security reasons non-printable and other special characters in %C, %i -and %o are escaped using \uhhhh sequences, where hhhh stands for the -hexadecimal representation of the character's unicode value. Exceptions -from this rule are " and \, which are escaped by prepending a backslash, -and all whitespace characters, which are written in their Java-style -notation (\n, \t, etc).

Rotating Logger Files

If you want to write the request (and access) logging information into a -rotated file, you should configure as follows:

Configure the Log Type to be a Logger Name and some usefull Logger -name. For example clientlog.request.
Create an Apache Sling Logging Logger Configuration for this Logger -name according to Logging Configuration - with the following setup: - Allow message at INFO (Information) level to be logged which is the -level used by the request loggers - Define the appropriate log file name, for example -logs/client.request.log - Use only {5} as the message format because request logger -messages are generally already fully formated with required timestamp etc. -
- Add any Logger names used for the client request log configuration, -clientlog.request in the example above, to the Logger field. By -clicking on the + (plus) button you may add more than a single logger -name whose messages are written to this file.
Optionally, you may create an Apache Sling Logging Writer -Configuration for the log file defined in the previous step to better -control rotation setup. See Log Writer Configuration - for full details.

Attribute	Description
org.osgi.service.http.authentication.remote.user	The user ID of the -JCR Session. This attribute is used by the HTTP Service implementation to -implement the HttpServletRequest.getRemoteUser method.
org.osgi.service.http.authentication.type	The authentication type -defined by the AuthenticationHandler. This attribute is used by the -HTTP Service implementation to implement the -HttpServletRequest.getAuthType method.
org.apache.sling.commons.auth.ResourceResolver	The -ResourceResolver created from the credentials and the logged in JCR -Session. This attribute may be used by servlets to access the repository. -Namely the SlingMainServlet uses this request attribute to provide the -ResourceResolver to handle the request.
javax.jcr.Session	The JCR Session. This attribute is for backwards -compatibility only. Its use is deprecated and the attribute will be -removed in future versions.
org.apache.sling.commons.auth.spi.AuthenticationInfo	The -AuthenticationInfo object produced from the AuthenticationHandler. -

Format String	Description
%%	The percent sign
%a	Remote IP-address
%A	Local IP-address
%B	Size of response in bytes, excluding HTTP headers.
%b	Size of response in bytes, excluding HTTP headers. In CLF -format, i.e. a '-' rather than a 0 when no bytes are sent.
%\{Foobar}C	The contents of cookie Foobar in the request sent to -the server.
%D	The time taken to serve the request, in microseconds.
%\{FOOBAR}e	Not supported in Sling; prints nothing.
%f	The absolute path of the resolved resource
%h	Remote host
%H	The request protocol
%\{Foobar}i	The contents of Foobar: header line(s) in the request -sent to the server.
%k	Not supported in Sling; prints nothing.
%l	Not supported in Sling; prints nothing.
%m	The request method
%\{Foobar}n	Not supported in Sling; prints nothing.
%\{Foobar}o	The contents of Foobar: header line(s) in the reply.
%p	The canonical port of the server serving the request
%\{format}p	The canonical port of the server serving the request -or the server's actual port or the client's actual port. Valid formats are -canonical, local, or remote.
%P	The _name of the thread_ -process ID of the child- that -serviced the request.
%\{format}P	Same as %P; the format parameter is ignored.
%q	The query string (prepended with a ? if a query string exists, -otherwise an empty string)
%r	First line of request
%R	The number of requests processed by Sling since the last start. -
%s	Status.
%t	Time the request was received (standard english format)
%\{format}t	Same as %t; the format parameter is ignored -unless it is the literal value _end_ indicating to use the time of request -terminating (instead of the time of request receipt).
%T	The time taken to serve the request, in seconds.
%u	Remote user (from auth; may be bogus if return status (%s) is -401)
%U	The URL path requested, not including any query string.
%v	The canonical ServerName of the server serving the request.
%V	Same as %v.
%X	Not supported in Sling; prints nothing.
%I	Not supported in Sling; prints nothing.
%O	Not supported in Sling; prints nothing.

Architecture

Architecture of Sling

OSGi

OSGi Framework

Compendium Services

Sling API

Request Processing

Resources

Servlets and Scripts

Launchpad

Assembly

Assembly: Bundling Bundles

Introduction

Bundles

Assemblies

Assembly manifest headers

Assembly Lifecycle

Bundles referenced by multiple Assembly Bundles

Bundle Installation

Bundle Location

Best Practices

Size of Bundles

Nomen est Omen

Authentication - Actors

Actors

OSGi Http Service Specification

Sling Engine

Sling Commons Auth

JCR Repository

Sling Applications

Authentication - AuthenticationHandler

AuthenticationHandler

Implementations provided by Sling

Sample implementations

HTTP Basic Authentication Handler

Form Based Authentication Handler

Authentication - Framework

Framework

AuthenticationSupport

Request Attributes on Successful Login

Anonymous Login

Authenticator implementation

Authentication - Tasks

Tasks

Extract Credentials from the Request

Login to the JCR Repository

Authentication

Authentication

Bundles

Bundles

Content

Resource Providers

Users, Groups, Access, Permissions

Installer

Misc

Client Request Logging

Client Request Logging

Traditional access.log and request.log Files

Log Output

Additional per-request Loggers

Log Format Specification

Rotating Logger Files