Updating your HCL Leap – Mind the Content Security Policy

Posted on by

We installed HCL Leap in 2024 as a replacement for the old community surveys. At that time, version 9.3.6 was the supported release. Later updates of HCL Connections gradually added support for newer Leap versions:

  • Connections 8.0 CR9 → Leap 9.3.8
  • Connections 8.0 CR12 → Leap 9.3.10
  • Connections 8.0 CR14 (expected) → Leap 9.3.12

Since our installation worked fine, we initially saw no reason to upgrade. That changed about six months ago when we encountered a user-identity issue.

Reused Login IDs

In our environment, login IDs can be reused about two years after a user leaves. In Connections this causes no problems, because applications rely on the PROF_GUID as the unique identifier.

In the Leap database, however, the link between Connections and Leap users is based on the Login ID. When a user is deleted from Connections, their record remains in the Leap database. If a new user later receives the same login ID, Leap still shows the name of the former user.

We opened a support case with HCL. The result was a new API in Leap 9.3.12 called “Decommission user.” The idea is that when a user is deleted in Connections, the corresponding Leap user can also be decommissioned through this API. We hope the Connections team will integrate this in CR14.

Since we now had a reason to upgrade, we moved our Leap installation to 9.3.12.

The Content Security Policy Issue

After the upgrade, we ran into a problem displaying Leap forms inside Connections. The cause turned out to be a change introduced in Leap 9.3.8: a stricter Content Security Policy (CSP). HCL does mention this in the system requirements.

If you embed Leap forms in another application, you must adjust the CSP configuration.

Relevant documentation includes:

The first document describes the parameter ibm.nitro.NitroConfig.runtimeCSP, which can be set in:

<path-to>/Leap/extensions/Leap_config.properties

In a Leap cluster, this setting must be applied on all Leap servers.

The Admin Configuration approach suggested by HCL did not work for us, but the third article described our issue exactly.

We added the following line to Leap_config.properties:

ibm.nitro.NitroConfig.runtimeCSP=default-src 'self' 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self' https://*.<YOUR_CONNECTIONS_DOMAIN>;

If this is not sufficient, the documentation suggests adding a header to IBM HTTP Server (IHS):

Header set Content-Security-Policy "frame-ancestors 'self' https://*.<YOUR_CONNECTIONS_DOMAIN>"

However, this change applies globally and reduces security because it is not Leap-specific. For that reason, we preferred not to use it—and initially we didn’t need to.

Error Forms and CSP

Later, we received another ticket reporting the same symptom: a Leap form would not load. Instead, users saw an unhappy face icon with the message:

“<connections_url> refused to connect.”

At first we suspected the CSP issue had returned, but the cause was different. Leap error forms are not covered by the CSP configuration.

After adding the IHS header, we finally saw the real error message: “No access possible.” In this case, the form’s ACL did not allow access for all users. A survey with a deployment period which doesn’t include the current date, is another potential reason.

The bigger problem is that when CSP blocks these error pages, troubleshooting becomes unnecessarily difficult. Adding the global IHS header is not an ideal workaround.

For that reason, we opened another case with HCL requesting that Leap error messages also respect the Content Security Policy configuration.