HCL Connections switch to allowlists

by Christoph Stoettner
Read in about 5 min · (words)

Grayscale Photo of Computer

Photo by Negative Space | Pexels

A long time ago, I wrote about the new implementation of allowlists in HCL Connections and that the documentation on customization and adding new rules was an absolute miracle for me.

I haven’t implemented allowlists at any customer at the moment, because the first tries in 2018 were horrible. Even formats from the builtin editors got deleted during the save procedure. During test deployments I often start with enabled allowlists, but later I always switch back to blocklists.

For a support ticket I had to check some settings today, and so I tried with enabled allowlist and blocklist. This let me remember the old blog post and I wanted to check if custom rules can be added now.

Allow <style>

Some environments allow formatting with style tags in the HTML source of documents. So this is the starting point, how can we allow <style>.

Let’s follow the official documentation Configuring active content filters first.

Locate the ojhs-whitelist-default.xml

Copy files

I decided to name my allowlist stoeps.

cd /opt/IBM/WebSpere/AppServer/profiles/Dmgr01/config/cells/cellname/LotusConnections-config/extern
cp ojhs-whitelist-default.xml ojhs-whitelist-stoeps
cp acp-configkey__default.xml acp-configkey__stoeps.xml

Now edit the copied files and change following lines:


sed -i 's/defaultKey=default/defaultKey=stoeps/g' acp-configkey__stoeps.xml


Here I replaced the watsonworkspace protocol with the file-protocol, and added the <style> tag.

In case of style this is not enough, because we need to allow text between the tags:

	<!-- Allow text within style tag -->
		<element name="style"/>
Here the diff of the original file and my customized one
 -- ojhs-whitelist-default.xml	2021-11-10 14:28:04.191941833 +0100
+++ ojhs-whitelist-stoeps.xml	2021-11-17 12:11:42.336626537 +0100
@@ -1,4 +1,4 @@
-<whitelist id="Default"
+<whitelist id="stoeps"
@@ -115,12 +115,13 @@
 		<element name="dir"/>
 		<element name="noembed"/>
 		<element name="xmp"/>
+		<element name="style"/>
 		<protocol name="ftp" />
 		<protocol name="tel" />
 		<protocol name="notes" />
-		<protocol name="watsonworkspace" />
+		<protocol name="file" />

@@ -905,5 +908,10 @@
 		<elementAttribute name="dir" val="ltr"/>
 	</transformElements> -->

+	<!-- Allow text within style tag -->
+	<allowTextIn>
+		<element name="style"/>
+	</allowTextIn>

To activate the allowlist we need to edit LotusConnections-config.xml and replace all occurrences of acp-configkey__default.xml with acp-configkey__stoeps.xml.

I couldn’t find a way to allow only specific elements within the style-tag. So allowing style with allowTextIn allows all CSS .

Best way to edit LotusConnections-config.xml is checking out and in, so you get syntax validation. In the article Using the Profiles database as the user directory are these steps explained.

Finally synchronize the nodes and restart all Connections Clusters.


I did some tests before I added the new rules. So I could add following code to a richtext widget on the overview page (or highlights).

<style type="text/css">
.someclass {
    color: white !important;
    background-color: blue;
    font-weight: bold;
.wheader, widgetTitle {
    background-color: lightblue;
    font-weight: bold;
<p dir="ltr" style="color:blue;background-color:yellow;font-weight:bold;float:right;font-size:2em;padding:5px;margin:2px;margin-top:20px;margin-bottom:20px">Test with style attribute within the p tag.</p>

<p class="someclass" dir="ltr">Test with a class name.</p>

<p dir="ltr">Additionally added css style to change background-color of widget title.</p>

With default allowlist, the following code is stored:

<p style="background-color:blue;color:green">Testing some code</p>
<p class="aaa">Testing some code</p>

To enable the style= attribute, have a look at Styling rules . The documentation tells us, that we have to enable this, but during my test with the default allowlist, styles were allowed. I doublechecked and in the default list it is already enabled. Style attributes are only styling the tag they are set in, so you can’t screw up the whole page.

Activate the customized allowlist and try again

After activation, the code is saved without changes, and so we can see the possible issue of allowing styles in user documents.

Saved richtext widget with code to change element all over the page

You see the users are able to change the color of the whole page (in this case the header background in Highlights). Not a big issue when they only change colors, but I already had users changing and hiding major parts of the connections overview page, so it can happen that they break widgets!

Fun with CSS - Hide a widget

Now I add display:none to hide the description widget. I use the aria-label to select the description widget here.

div[aria-label="description"] {display:none;}

Description widget div has aria-label=description, so adding css to hide it here

Here you see the saved code and the missing widget on the right side. Imagine you hide the RTE widget, so you need some knowledge to get the code changed.

A cool way to customize a community, but this opens the door for a lot of missuse from user side, but it is definitly easier to achieve than adding themes to communities.

To-do and summary

Activating allowlists in environments which were deployed before 6.0 can be a challenge, because you don’t know which protocols, or tags are used.

Why is this a problem?

So if users open documents that have been saved with active blocklists, the allowlist may be more restrictive and delete some of the content. This can only be styles, so that the document simply looks different, but links can also be deleted because the protocols are not explicitly allowed.

The reason for this is the different philosophy of blocklists and allowlists, so in blocklists everything is allowed what is not listed. Allowlists reverse this approach, they only permit content maintained in the list. So if you forget an element, it will be removed during save.

On the other hand the allowlist is a decent way to increase the security, because it prevents user from storing possible malicious code.

So my to-do is digging into the databases and build a script to find all used tags and protocols. As a bonus question I’m highly interested to allow the style tag, but allow only some special css rules within this tag.

Add a comment
There was an error sending your comment, please try again.
Thank you!
Your comment has been submitted and will be published once it has been approved.

Your email address will not be published. Required fields are marked with *

Suggested Reading
Card image cap

So up to IBM Connections 6.0 everything was allowed until it was not excluded in one of the blocklist files. This files are stored within the Deployment Manager profile/config/cells/<cellname>/LotusConnections-config/extern. Now with Connections 6.0CR1 everything is forbidden, until it is enabled in the allowlist. This concept is rolled out for widgets (homepage and communities) and active content. Active content means HTML content too. So everything you or your users add to Connections (blog-posts, wiki pages) gets filtered during the save procedure. This removes all HTML tags and attributes which are not explicitly allowed!

Read in about 5 min
Card image cap

Some time ago I got the tip from HCL Support, that the Create Community button will recognize the role community-creator only when the gatekeeper option CATALOG_CARD_UPDATED is set to false.

This is working, but I had to complain, that this option activates some code, which loads fonts from a CDN instead of the local Connections deployment.

Read in about 2 min
Card image cap

Connections 7 creates the Community Highlights page automatically and sets it as the start page for new communities.

That’s configured in the highway service, which is available for administrative users on https://your_connections_url/connections/config/highway.main.gatekeeper.tiles

Read in about 3 min