Revisit CMS Users

Due to CMS 12's Configuration Management mechanism, the way a project specifies and bootstraps CMS users needs to be revisited.

Users are 'system'

Typically, users are created and maintained by an administrator, in a production environment. In order not to (auto-)exported such users, add them to your project's bootstrap definition and bootstrap them into new or existing environments, Bloomreach Experience Manager categorizes users into the system category. The same categorization applies to groups, grouping together a set of users.

Prevent password reset

When upgrading to CMS 12, existing CMS users, which are not part of your bootstrap definitions are therefore left unchanged. CMS users that are part of your project, however, will be 'reset' to the values stated in your bootstrap definition, including these users' passwords. In order to prevent this reset, the following properties of a user should be categorized system (while the users are part of the config category):

  [...]
  hipposys:password:
    .meta:category: system
    value: <initial password, preferably encrypted>
  hipposys:passwordlastmodified:
    .meta:category: system
  hipposys:previouspasswords:
    .meta:category: system
  [...]

For the hipposys:password property, we're also specifying a value. Since the property is categorized as system, the value is used as an initial value only, such that you have a defined, valid state when bootstrapping a fresh repository. Once the property exists, you can change it, and the system category will ensure that the new value is not exported or overridden by subsequent deployments. We recommend to apply this change to any user defined in your repository-data/application module.

Designated development users

The Hippo archetype project used to provide the author and editor users out of the box, for testing purposes. Since their purpose is to facilitate (local) development of the project, you typically wouldn't want to deploy them into a production environment. If your project's repository-data/application module still contains these users, now would be a good moment to move them into the repository-data/development module in order to prevent them from affecting a production system. The same reasoning applies to project-specific users: if they are needed on production and bootstrapped by the project, prevent a password reset, otherwise, move them into the development module.