i2b2 1.8.2 Upgrade Issue - Unable to Login (PM Cell Down / cellURL Error)

[Meghal Gandhi]

Hi,

I am currently upgrading i2b2 from version 1.7.12a to 1.8.2 using the official upgrade instructions provided on the i2b2 website. I am doing it for my institute based in Los Angeles, California.

At this point, I am unable to log in to the i2b2 webclient. The application consistently shows an error indicating that the PM cell is down or that the properties file should be checked.

Here is what I am observing:

• All cells (PM, CRC, ONT, WORK) appear to deploy successfully in WildFly.

• Data sources are configured and connections to SQL Server are working.

• Login attempts are reaching the backend, and session entries are being created in the PM_USER_SESSION table. I can also see PM_USER_LOGIN table with success entries.

• However, the webclient does not proceed past login and throws errors.

I have been troubleshooting extensively but have not been able to identify the root cause. WildFly logs are not showing any relevant errors related to this issue, which is making it difficult to pinpoint what might be going wrong.

Additionally, from the browser developer tools, I am seeing errors related to the PM cell configuration (e.g., cellURL not being recognized), which suggests a possible issue in how the webclient is resolving the PM endpoint after authentication.

For your reference, here is more details:

• Screenshots of the error message

• 
  

• Browser developer tools (console and network) screenshots:

•   

• Relevant configuration snippets: i2b2_config_domains.json:

• {
    "urlProxy": "proxy.php",
    "urlFramework": "js-i2b2/",
    "lstDomains": [
      { "domain": "i2b2cdu",
        "name": "i2b2_CDU_Test",
        "urlCellPM": "<server_ip_port>/i2b2/services/PMService/",
        "allowAnalysis": true,
        "ignorePasswordMgrs": true,
        "debug": true
      }
    ],
    "loginTimeout": 5
  }
  

Environment details:

• i2b2 version: 1.8.2

• Application server: WildFly 37

• Database: SQL Server

• Webclient hosted via IIS on Windows VM

Currently, IIS, wildfly and SQL Server are in the same windows VM.

I would really appreciate any guidance or suggestions on how to resolve this issue.

Thank you for your time and support.

Best regards,
Meghal Gandhi

[mabaj...@mac.com]

Hello, Meghal,

We know that your PM Cell is not down, because you have confirmed that it is recording the logins. There may be a cellURL error in your configuration.

In my experience, the most common place where the PM URL is missing is in the proxy.php file in the webclient. In that file, around lines 40-60, you will see settings for pmURL, WHITELIST, and BLACKLIST. You may need to update these items. 

Since your webclient is running on IIS on your WildFly host,  the only part of pmURL that may need updating may be the port number.

But since your i2b2_config_domains.json file names a <server-ip+port>, that entry should be added to the WHITELIST and BLACKLIST settings. Whatever WHITELIST/BLACKLIST shows for "127.0.0.1:8080," just repeat those settings for your fqdn-or-ip and port (that is, whatever you are using in your i2b2_config_domains.json).

 

I'm not certain that you require any changes in proxy.php, but that would be a good place to look.

Also, if/when you are using https for your WildFly connection, you will want to update these settings to reflect that in your proxy.php and your i2b2_config_domains.json.

Please let us know if this is helpful.

Kind regards,

Mark Abajian

Abajian Consulting, LLC
P.O. Box 8017, Glendale, CA  91224

www.abajian-consulting.com

[Meghal Gandhi]

Hi Mark,

Thanks for your response.

I am currently testing with localhost only. So I have this in my domain json file:   

"urlCellPM": "http://localhost:9090/i2b2/services/PMService/".

Below is the content from proxy.php:
$pmURL = "http://localhost:9090/i2b2/rest/PMService/getServices";
$pmCheckAllRequests = false;

$WHITELIST = array(
    "http" . (($_SERVER['SERVER_PORT'] == '443') ? 's' : '' ) . "://" . $_SERVER['HTTP_HOST'],
    "http://services.i2b2.org",
    "http://127.0.0.1:9090",
    "http://127.0.0.1:8080",
    "http://127.0.0.1",
    "http://localhost:8080",
    "http://localhost:9090",
    "http://localhost"
);

$BLACKLIST = array(
    "http://127.0.0.1:9090/test",
    "http://localhost:9090/test"
);

In short, I have entries already in proxy.php file. So I am not able to understand why it is still failing?

Thanks.

Best,

Meghal

[Meghal Gandhi]

After tons of troubleshooting efforts and trying multiple approaches after our meeting, I was finally able to successfully log in to i2b2 version 1.8.2. 

I am providing my findings below in case someone gets stuck in similar issues.  

I did in-depth debugging of many core I2b2 web client files: i2b2_cell_communicator.js, PM_ctrlr.js. First I found the parsing location code lines in PM_ctrlr.js file and print the parsed response, that's where I found issues. Mainly I print the parsed "data" to console to get the root cause under i2b2.PM._processUserConfig = function (data) in PM_ctrlr.js file after line 270 (i2b2.PM.removeLoginDialog();):

// Debug console.log("PM login response data:", data);

Summary of the issue:

• The PM cell was actually working correctly.
• Login requests were reaching the backend and entries were being created in the database.
• However, the webclient was failing after login with errors: "PM cell down".

Root cause:

• The issue was in the proxy.php file used by the webclient.
• PHP warnings (e.g., undefined array keys like query, port, and an undefined variable $pmCheckAllRequests) were being printed in the response.
• These warnings were appearing before the XML response from the PM service, which corrupted the XML response.
  • Example of the response being returned:
  • Warning... Warning... <?xml version="1.0"?> <ns2:response>...</ns2:response>
• As a result, the i2b2 webclient was unable to parse the XML response properly and failed during login.
• I believe newer PHP versions are stricter and surface these warnings (e.g., undefined array keys) more explicitly, which contributed to this issue. My PHP version is 8.2.9.

Fix applied:

• Suppressed PHP warnings from being displayed in the response by adding the following at the top of proxy.php:
  error_reporting(E_ALL & ~E_WARNING & ~E_NOTICE & ~E_DEPRECATED); ini_set('display_errors', 0); ini_set('log_errors', 1); $pmCheckAllRequests = false; // Make it global
• After this change, the response returned clean XML, and the login worked as expected.

Best,

Meghal Gandhi