Avoid potentially destructive configuration

Avoid potentially destructive configuration

Potentially destructive configuration is accidentally bootstrapping yaml configuration as category config for which already runtime 'configuration' exists, classified as system (or content), see Configuration vs Content (vs System).

Especially in the context of security configuration such a mistake can be (more) easily made, because runtime security configuration changes are typical and to be expected!

A typical correct example is that you have in your yaml bootstrap the configuration for a custom group mygroup eg:

definitions:
  config:
    /hippo:configuration/hippo:groups/mygroup:
      jcr:primaryType: hipposys:group
      hipposys:system: true
      hipposys:members:
        .meta:category: system
        .meta:add-new-system-values: true
        type: string
        value: []
      hipposys:securityprovider: internal
      hipposys:userroles:
        .meta:category: system
        .meta:add-new-system-values: true
        type: string
        value: [xm.cms.user, xm.content.user, xm.channel.user, xm.report.user, 
                xm.dashboard.user, xm.channel.viewer]

The above is correct as it categorized the hipposys:members and hipposys:userroles with 

.meta:category: system
.meta:add-new-system-values: true

making sure that on a new deployment to production it will not wipe potentially runtime added members or userroles!

Note 1:  hipposys:members also is allowed to have initial (bootstrap) values, for example

hipposys:members:
  .meta:category: system
  .meta:add-new-system-values: true
  type: string
  value: [user1]

note 2: If they properties hipposys:members and/or hipposys:roles are not present, the configuration is also correct since by default they will only be processed (applied) when they are defined.

If instead of above example the group mygroup would be configured as below, it means that on a new deployment, any members or users that were added in production (runtime) will be replaced since the properties are defined to be config:

Note, below is an example of destructive wrong configuration
definitions:
  config:
    /hippo:configuration/hippo:groups/mygroup:
      jcr:primaryType: hipposys:group
      hipposys:system: true
      hipposys:members: []
      hipposys:securityprovider: internal
      hipposys:userroles: []

Validate no Destructive Configuration is present

To validate that your project authorization setup does not contain any destructive (security) configuration, search your local yaml files for the following strings (in *.yaml), as these properties generally need to be regarded and configured as system category:

  • hipposys:members:
  • hipposys:userroles:
  • hipposys:groups:
  • hipposys:users:

and when they are present, make sure they are configured with the following .meta classifiers:

hipposys:name-of-property:
  .meta:category: system
  .meta:add-new-system-values: true
  type: string
  value: [val1, val2, val2]

See also: System Properties with Initial Value(s)

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?