Platform Setup Hints

General Setup

Configuring the Author Host

Enable Access Control

To enable access control, it is necessary to enable and perhaps configure the following filter in the OSGI Configuration manager:

  • Composum Platform Access Filter: the "Access restriction" has to be switched on. Remember to check / change the "Author Hosts" to enable the author interface for the appropriate virtual hosts. Otherwise authors will not be able to login.

Enable the version resolver

The Platform supports an easy way to present the various releases out of the JCR version control (see Versioning of Pages). For that, access control has to be enabled (see above), and the following filter:

  • Composum Platform Release Resolver Filter : has to be enabled. It switches to a resolver presenting the release chosen by request attributes set by the:
  • Composum Pages Release Filter : if enabled, it reads out the URL parameters cpm.release or cpm.version.

This is essential to be able to compare releases and document versions.

Configuring a Public Host

Configure a public host with InPlace replication

In a basic setup with just one Sling instance or a homogenous Sling cluster, the most performant way to present the public release is to configure a virtual host accessing the Sling instance / Sling cluster, and set the publish policy to InPlace replication on the Site. This copies the public release of the site into a path configured in the Composum Pages Replication Configuration (by default /public). This replication is repeated on each change of the release marked as public / on each move of the public mark.

Besides setting up the virtual host (e.g. with a load balancer or apache, preferably caching requests), an appropriate mapping into the resource tree below /public needs to be configured (see URL Mappings for Resource Resolution). (It might be necessary to change the settings in the "Apache Sling Resource Resolver Factory".)

Caution: in an installation of Platform and Pages without the Tenants enterprise module, it will be neccesary to allow readability to the replicated release in /public and /libs/composum/pages/components for everyone.

Configure a public host with "Live immediately"

If no release management is wanted, it is possible to set a site to "Live immediately". Thus, all changes made to pages are immediately shown to the public. This setting requires a virtual host that is not configured as an author host, defining an appropriate URL mapping and making the required parts of /content readable for everyone.

Configure a public host with "Versions resolver"

When set to publish policy "Versions resolver", the site content is served directly from the checked in versions of the pages according the release marked as "public" via the StagingResolver described in Staging. This requires configuring the URL mapping for the (non author) virtual host according to the normal content path of the site.

Please keep in mind that this setting reduces the performance of the site, since the release JCR content is reconstructed from version storage on the fly.

This also requires opening the permissions of the site to everyone.


Configure a preview host in Author mode (InPlace replication)

If a special virtual host should be configured that presents the preview release, and this host needs to be access controlled, it needs to be configured in the Composum Platform Access Filter Configuration as an preview host. 

To separate several preview hosts for several sites, or to have convenient URLs like http://preview.composum/home.html (as opposed to http://preview.composum/preview/ist/composum/home.html), it is sensible to configure an appropriate URL mapping.

Logging improvements

To make it easier to follow the log entries one request generates through the various logfiles, some suggestions for configuring the logging.

  • For both the access log and the request log it is possible to log the thread name by setting the mesage pattern for the corresponding configuration to %msg [%t]%n . But please note that  the thead name is temporarily changed to something that describes the request, so it'll be different in error.log. Thus this just makes some crossreferences easier.
  • You can add another request data logger with a custom pattern to the "Apache Sling Customizable Request Data Logger". For example, to get another entry per request in the request.log you can use the logger name "log.request", type of  destination to "Logger Name", and a log format %t [%R] = %v %{X-Forwarded-For}i %{JSESSIONID}C %{Referer}i will write an additional line with the canonical hostname the request was received at (important in the case of several virtual hosts), the IP it comes from (if you got an apache as front end), the session id and the Referer header. (Please be aware that the session id is a security risk if an attacker is able to read this logfile. It would be better to somehow find another unique id to follow the requests of one session.)