See RD-5403

When an author browses a website in the CM and then visits a Experience Page (s)he has role Author on, the Experience Page layout (HST Components) should become editable

Logical Implications

When someone browses to a channel in the Channel Manager, we do not know on beforehand whether the specific user can potentially modify some Experience Pages : we do not know on which pages (s)he might have the role hippo:author. This means that anyone who can navigate a channel in the CM potentially can modify some pages in the CM (the layout). Hence, the current global check when opening the CM whether the user is a webmaster or not doesn't hold any more: A user can be

• Webmaster and/or
• Author on some XPages

So when looking at a (x)page in the CM, it might be that the CMS user has write access to only the XPage container(items) or only the HST Config container(items) OR (s)he has write access to BOTH the XPage container(items) AND the HST Config container(items).

Note that even if the user has write access to the XPage container(items) and to HST Config container(items), (s)he is still NOT allowed to drag drop items from XPage containers to HST Config containers and vice versa: this is because they have a different life cycle

Technical Approach

First of all, for now, we mark that every user has write privilege during the UI call to #composerModeGet : We set

canWrite = true

However, the Channel mgr UI code should not even look at this property any more. Instead it should look PER component whether the user is allowed to modify it! For this, we include to the html comment (or in PMA to the meta data) the following attributes for EVERY HST container, and container item :

HST-Experience-Page-Component = true | false
HST-Component-Editable = true | false

Some users will only have editable for the container(item)s of an XPage, some only for HST Config container(item)s and some for both (eg a person in role webmaster on the hst config and in role hippo:author for the XPage document)

Technical Implementation Details

During the HST page rendering in the Channel Manager, we need per HST Component check whether the user is in the right role to be allowed to do so. For XPage components the required role is 'hippo:author' and for HST Config components the required role is 'hippo:channel-webmaster'. To be able to do so, we need to be able to access the JCR Session of the logged in CMS user. At this moment, during HST aggregation valve rendering, we do not have this user JCR Session. The user JCR Session is only created to be able to create a JCR Session which combines the preview HST Session with the CMS user Session (JCR Security delegation we call that). After that, the user JCR Session is logged out again. This needs to be done differently, we need to be able to access it during the aggregation valve (page generation) to check the privileges. For this, we need to hook into the CmsSecurityValve

Once we have the CMS User JCR Session available, we can in CmsComponentComponentWindowAttributeContributor simply check the above mentioned roles against the HST Component