Securing users’ information in the staging when using remote publishing function

Liferay portal provides remote staging and publishing capability through which the users can select subsets of pages and data (both portal core assets and custom assets), and transfer them to the live site—that is, remote portal instance.

There are two types of staging: Local Live and Remote Live. Local Live - Within the current portal environment, a clone of the current site will be created. This clone contains copies all existing pages and data of portlets. This clone becomes the local Staging while the original becomes the local Live. Remote Live - A connection is built between this site and target existing in a remote instance. The connection settings cover persistent network configuration which defines how to locate the remote instance when a publishing event occurs. This site becomes the remote Staging while the remote site becomes the remote Live.

In the previous post, we have discussed how to apply LAR and remote publishing capabilities on custom assets in Plugins. We also addressed the new feature how to keep user password secure with LDAP integration when building the staging. This article will address a new feature: how to secure users’ information in the staging when using Remote Live mode.

Let’s take a look on a scenario. There are clustered-staging servers and clustered-product servers. By default, there is a dummy user in both the staging and the product. All editorial users exist in the staging only. Their daily work is to create / update press release, and schedule to publish to the product.

Use case I: secure the users’ information in the staging when using remote publishing function.

Solution

In the staging server, pre-define a dummy user screen name in the portal.properties. This dummy user will impersonate all users who have permission to handle remote publishing.

## Tunnel dummy user enabled;
tunnel.dummy.user.enabled=false

## tunnel dummy user screen name.
## The portal will consume this dummy user screen name for remote publishing
## if the property tunnel.dummy.user.enabled is set to true.
tunnel.dummy.user.screenname=test

Then before calling remote group, impersonate the current user using the dummy user. The following is code snippet.

User user = UserLocalServiceUtil.getUser(permissionChecker.getUserId());

if(_TUNNEL_DUMMY_USER_ENABLED)
            user = UserLocalServiceUtil.getUserByScreenName(
                    permissionChecker.getCompanyId(), _TUNNEL_DUMMY_USER_SCREENNAME);

Summary

As you can see, this fix is very useful when you want to secure the user password in LDAP server, and secure all users info in the staging. For more details, you may check the status of the ticket LPS-17251.

Last but not least, I'd like to send special thanks to Eduardo Carneiro and Mark Wynne who provided these requirements.

Challenges

The feature of staging and remote publishing is cool! But real use cases require more new features on top. The following are some of them.

Challenge I: Asset-level scheduling and remote publishing capability. For example, editorial User A created press release articles A1, A2, A3. He / She going to schedule to publish A1 in 30 minutes, A2 in 60 minutes and A3 in 120 minutes. And meanwhile, editorial User B created press release articles B1, B2, B3. He / She going to schedule to publish B1 in 5 minutes, B2 in 180 minutes and B3 in 360 minutes.  As you can see, the portal should provide asset-level scheduling and remote publishing capability. Refer to LPS-17235

Challenge II:  Asset-version-based scheduling and remote publishing capability. For example, editorial User A created press release article A and different versions Av1, Av2, Av3. He / She is going to schedule to publish Av1 in 30 minutes, Av2 in 60 minutes and Av3 in 120 minutes. Similar scenario happens for other editorial users. Refer to LPS-17395

Challenge III: Page-version-based scheduling and remote publishing capability. For example, editorial User A updated top story page and published this page in three time slots Pv1, Pv2 and Pv3. The final version of top story page in Remote Live is Pv3. For some reason, he / she are going to revert to the version Pv1. Refer to LPS-6431

Challenge IV: scheduling and remote publishing dashboard. Request an admin-dashboard to oversee remote publishing history and to manage on-going scheduled events.  As editorial administrator, he / she needs a dashboard where he / she could see all history – asset-level, asset-version-level , page-level and page-version-level  remote-publishing content; and see all on-going  scheduled events. In case, he / she would be able to cancel some events. Refer to LPS-17400

Your comments / suggestions / feedback?

Blogs
hi,dear jonas, could you contact me? i hope to get your answers of some question.my email: l_rj@hotmail.com