HCL Connections – Orient Me “Loop”

In the course of the recent deployment of HCL Connections Component Pack 7.0.0.2, I ran into an issue with the Orient Me application.

After deploying Orient Me, every try to open the new Orient Me homepage would result in a “loop”, the user was being redirected from the Orient Me (/social) page to the Homepage application (/homepage) and back again to the Orient Me page. The root cause for the problem was not a bug or an error in the HCL Connections code, but rather the configuration of the HCL Connections Blue Stack and other components in the IT landscape of this environment.

After further investigating the issue, we have seen the following messages in one of the “orient-web-client” pods:

Mon, 14 Mar 2022 13:15:37 GMT hsts deprecated The “includeSubdomains” parameter is deprecated. Use “includeSubDomains” (with a capital D) instead. at node_modules/loopback/lib/server-app.js:74:25
{“pid”:7,”hostname”:”orient-web-client-57594bc9df-ck6qq”,”name”:”@connections/cachy-service/src/client/redis-client.js”,”level”:30,”time”:1647263737775,”msg”:”om-readiness-probe Initializing [%s]”,”v”:1}
Web server listening at: http://localhost:8000
2022-03-14T13:15:37.883Z – ESC[32minfoESC[39m: [orient-web-client] Cachy-gatekeeper register response: true
2022-03-14T13:17:41.020Z – ESC[34mdebugESC[39m: [auth-service] decodeJWT: no JWT found, returning no_jwt_token
2022-03-14T13:17:41.022Z – ESC[34mdebugESC[39m: [auth-service] >auth.service: about to call setJWT to generate or re-generate token…
2022-03-14T13:17:41.022Z – ESC[34mdebugESC[39m: [auth-service] Setting status to be 401
2022-03-14T13:17:41.024Z – ESC[34mdebugESC[39m: [auth-service] setJWT failed with err: [no_auth_token]: no_auth_token
2022-03-14T13:17:41.025Z – ESC[31merrorESC[39m: [orient-web-client] >server: ensureLogin callback with error: UnauthorizedError: [get_token_failed]: Unable to get token undefined
Unhandled error for request HEAD /social/auth/token: UnauthorizedError: [get_token_failed]: Unable to get token
2022-03-14T13:17:41.355Z – ESC[34mdebugESC[39m: [orient-web-client] ENTRY: AuthenticationMiddleware.handleAuthentication undefined
2022-03-14T13:17:41.356Z – ESC[34mdebugESC[39m: [orient-web-client] ENTRY: AuthenticationMiddleware.extractLDAPCookies undefined
2022-03-14T13:17:41.356Z – ESC[34mdebugESC[39m: [orient-web-client] EXIT: AuthenticationMiddleware.extractLDAPCookies for user id: undefined
2022-03-14T13:17:41.356Z – ESC[34mdebugESC[39m: [auth-service] decodeJWT: no JWT found, returning no_jwt_token
2022-03-14T13:17:41.357Z – ESC[33mwarnESC[39m: [auth-service] JWT token is bad, can not proceed for potential CSRF!
2022-03-14T13:17:41.358Z – ESC[34mdebugESC[39m: [orient-web-client] handleAuthentication ensureLogin error { [UnauthorizedError: [not_authorized]: Not authorized]
name: ‘UnauthorizedError’,
code: ‘not_authorized’,

What was obvious, was that the user didn’t have a JWT Cookie going to the Orient Me web client and the Orient Me web client could not generate the same as it could not recognize the username of the user “hitting” the service.

Thankfully, with the guidance and help of my colleague, Martin Leyrer, we managed to resolve this issue. In order to resolve the problem, we have done the following.

We checked and modified all DNS entries of all hosts and services (NGINX, IBM HTTP Server, etc…) involved and made sure these were resolving correctly.

The “dynamicHosts” property in the “LotusConnections-Config.xml” was enabled, as described in the official documentation, and we corrected the “interService” URLs (in our case the URL resolving to IBM HTTP Server), in the same configuration file.

On the WebSphere Application Servers, the LTPA Cookie names were not set to the default. As this could cause similar issues, we have changed those to default, “LtpaToken” and “LtpaToken2”.

Note: As version 2 of the LTPA Cookie is much more secure, we recommend only using this version as opposed to version 1.

The last change we have done was in the IBM HTTP Server configuration (“httpd.conf” file), here we have added the “ServerName” parameter to the <VirtualHost *:443> section, after that, the configuration looked like the following:
…
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443
<VirtualHost *:443>
ServerName ibm_ihs_hostname.domain.com
SSLEnable
RewriteEngine on
…

After doing all the changes mentioned above, we were able to resolve the issue and could successfully render and use the Orient Me application. 😉

I sincerely hope this will help and save you some pain! 🙂