Composum Blog

various aspects of the Composum world

Nodes Restrictions

In order to make the use of the Composum Nodes tools usable in different environments and still ensure security against unintended or unauthorized manipulation in the repository, individual features or even complete modules of the Nodes console can be restricted or completely disabled.

Ralf Wunsch

All functions of the various nodes tools (browser, user manager, package manager) can be restricted via declared rules. These rules are configured via OSGi and can thus be varied for different systems depending on the runmode. Individual features can be disabled (none), protected against modifications (read) or even explicitly and completely permitted (write) in deviation from the general setting via these explicit, functional service restrictions using the associated key.

Key (Feature)



retrieval of permissions (ACLs) for the logged-in user; read only


retrieval of system parameters (property, node, mixin types); read only


API for querying the declared restrictions (read) or switching of the temporary default rules for the logged-in user (write)


retrieval of the translations for the currently used language; read only


API for job control, querying the job status (read) or manipulating job execution and starting new jobs (write)


applying of ACLs (permissions) by executing appropriate setup scripts (write); write only


component manipulation, e.g. create and remove component overlays (write); write only


retrieval (read) and create (write) scenes for testing components


display (read) and management (write) of installed content packages via the Nodes Package Manager


retrieval of the defined node types as configuration file (read); read only


retrieval (read) and manipulation (write) of the ACLs at the nodes of the repository


retrieval (read) and manipulation (write) of the properties of the nodes of the repository


retrieval (read) and manipulation (write) of the resources (JCR nodes or provided via provider) of the repository


display and download in the source view of the browser (read); read only


retrieval (read) and manipulation (write) of the versions of the versionable nodes of the repository.


display (read) and management (write) of users (system, service, regular users) via the Nodes User Manager


retrieval of a user's profile data (read); read only


analysis and retrieval of Composum clientlibs (read); read only


analysis and graphical representation of services and their dependencies (read); read only


display of OSGi bundles and their status (read); read only


display of files in the working directory of the sling instance (read), the path pattern of the allowed files can be further restricted via regular expressions; read only


analysis of the running threads (read); read only


proxy of the Sling Webconsole to analyze the available adapters (read); read only


proxy of the Sling Webconsole to analyze the last Sling requests (read); read only


proxy of the Sling Webconsole to analyze the Sling Resolver configuration (read); read only.


Sling Webconsole proxy to analyze the Sling servlet resolver (read); read only.


proxy of the Sling Webconsole to analyze the Sling jobs (read); read only.


iFrame of the Sling Webconsole (only if Webconsole is available)

For each of the features (keys) the general restriction - none / read / write - can be defined. For individual users or user groups, additional deviating rules can be defined. Individual features also allow additional patterns to further restrict access in detail.


The configuration of the service restrictions is done via matching OSGi configuration files to the implementing service - - in the respective preferred format. Below are a few examples in JSON format (

  1. Removable Restriction

    { "enabled": true, "defaultPermission": "read", "userOption": "write", "restrictions": [ "system/service/graph=none" ] }

    Configures 'read' as the default functional constraint for all services and allows the user to temporarily extend it to 'write' if they see fit. However, the service dependency visualization feature is completely disabled.

    This configuration is a kind of 'self-protection' against accidental changes.

    The 'enabled' property allows the service restrictions itself. An 'enabled=false' disables the functional restrictions!

  2. No Manipulation allowed and File Access Limited to log files

    { "enabled": true, "defaultPermission": "read", "userOption": "read,write:admin", "restrictions": [ "system/runtime/files=read:^/((sling|launcher)(/logs(/[^.]+\\.log(.[0-9-]+)?)?)?)?$" ] }

    The default 'read' restriction can only be temporarily disabled by the 'admin' user. Without the additional rule for the 'admin' user, no user could temporarily disable the 'read' restriction.

    For the retrieval (display or download) of the files of the working directory, a restriction to log files defined by a corresponding regular expression of the allowed file paths applies.

  3. Productive Use

    The following example only allows read-only browsing of the repository without ACL access. In addition, all 'system' features are prohibited except for access to the log files. Such a configuration could possibly allow the use of the nodes tools in a production system.

    { "enabled": true, "defaultPermission": "read", "userOption": "read", "restrictions": [ "core/job=none", "core/setup=none", "nodes/components=none", "nodes/packages=none", "nodes/users=none", "nodes/repository/permissions=none", "system=none", "system/runtime/files=read:^/((sling|launcher)(/logs(/[^.]+\\.log(.[0-9-]+)?)?)?)?$" ] }

    If the installations / updates are done via the package manager, then this feature and the used 'core' features must be explicitly allowed (write), if the default setting is reduced to 'read', otherwise the installation of a package and thus possibly also the change of this configuration is not (anymore) possible:

    { "enabled": true, "defaultPermission": "read", "restrictions": [ "core/job=write", "core/setup=write", "nodes/packages/manager=write" ] }

The functional service restrictions supplement the restrictions defined via ACLs in the repository. The ACLs continue to apply without restriction and in addition. They are not overridden in any case by any administrative permissions of the nodes tools. The functional restrictions of the Composum Nodes via ACLs on the Nodes components are also still possible.

Status display and status adjustment

The currently set default restriction is displayed in the Nodes Console in the navigation bar on the right-hand side next to the current user ID, provided that the tool currently used in the Console supports service restrictions.

The 'shield' symbol illustrates the 'read' restriction, a 'wrench' the 'write' status. If a different temporary user option is possible, the default restriction can be switched by clicking on the symbol. A colored background is used if the current status is a temporary user option. It is also possible to temporarily downgrade a configured 'write' restriction (everything allowed) as user to 'read', e.g. to exclude accidental changes.