Delivery Tier Users

Hippo's delivery tier (HST) ships with 4 different users:

• configuser

• liveuser

• previewuser

• sitewriter

configuser

This is the user that needs to be able to read pretty much all nodes in the repository. It does not need write access.

liveuser

The user that is used to render live content. Typically this user never needs write access to any node type.

previewuser

The user that is used to render preview content. The CMS channel manager preview is rendered with this user, optionally combined with the CMS editor/author user, see Channel Manager Preview With Security Delegation. Typically this user never needs write access to any nodetype

sitewriter

The user that is used to persist changes into the repository, for example form data nodes or workflow on documents. By default it only has write access to form data. If you want to use the HST workflow manager  WorkflowPersistenceManager, you need to grant the sitewriter more rights, as explained in Configure Permissions when using Workflow in the Delivery Tier.

Optional Separate Binaries User

The binaries session pool contains JCR sessions that are used by the binaries servlet if the request does not already have an HstRequestContext. If there is an HstRequestContext the user that is returned via  HstRequestContext#getSession is used, which is in general the liveuser for live content and the previewuser for preview content (for example in Channel Manager when looking at the preview of sites). By default, the binaries user is the same as the liveuser (same user name). If you want a different one (though in general not needed), you can configure this by overwriting the  binaries.repository.user.name property in your hst-config.properties file.

Passwords

Since Bloomreach Experience Manager 10.0 the password for all default site users can be left empty in hst-config.properties (or just not configured, that is best). This is because the users in the repository are configured with 

hipposys:passkey: jvm://

This means that if the HST site webapp and the repository run within the same JVM (which in always the case in common Hippo setups), the HST can achieve a JCR session without a password but just a user name. The supported JVM-enabled users are by default

1. configuser
2. liveuser
3. previewuser
4. sitewriter

If you want to use a JVM-enabled user not requiring a password, you must

1. make sure the user in the repository has hipposys:passkey = jvm://

   /hippo:configuration:
     /hippo:users:
       /configuser:
         hipposys:passkey: jvm://
       /liveuser:
         hipposys:passkey: jvm://
       /previewuser:
         hipposys:passkey: jvm://
       /sitewriter:
         hipposys:passkey: jvm://
   

2. make sure the password in the hst-config.properties for the users is either empty or completely missing (best just to remove them). Best in this case is to not have any of the user related properties like default.repository.user.name or default.repository.password in your hst-config.properties. 
   Remove all properties that are user related  from hst-config.properties if you want JVM-enabled users. 

Optional

If you have JVM-enabled site users, you can optionally remove the hipposys:password property from the users. Certainly in production this is preferable. The only reason in case of JVM enabled users to keep the password is if you want to login with a site user into the repository servlet below /repository.

Upgrade from Older Versions

If you upgrade from pre 10.0 versions and want to start using JVM enabled users, make sure to add the hipposys:passkey = jvm://, optionally remove the hipposys:password, and make sure to remove the passwords from local hst-config.properties.

Advantage of JVM-Enabled Site Users

The biggest advantage of JVM-enabled site users is that outside the repository you do not need to have a separate file (hst-config.properties) containing the passwords for every site user. The biggest problem with this is that if (by accident) a site user password gets changed in the repository, every cluster node separately had to have the site user passwords fixed. Another big advantage is that between different environments, no different passwords need to be maintained for the site users.