ZE changes the way how it treats secure values in the Team Config between minor versions

[roman-kupriyanov]

Describe the bug

We are using the Profiles API from Zowe Explorer in our Explorer for Endevor extension to be able to provide connections to Endevor via API ML using the Team config for our client.

We got a report that the same Team Config that was worked together with Zowe Explorer v2.9.0 and Explorer for Endevor v1.5.2 is not functioning properly anymore after upgrade to ZE v2.18 and E4E v1.8.2. We did not change how we treat the profiles between the versions and we totally rely on the ZE API to provide us proper credentials (basic MF creds or API ML token) depending on the configuration is used, so I assume some behaviour is changed between Zowe Explorer versions.

An investigation on our side shows that with the upgrade to ZE v2.18, the same profiles that were used before started to report basic credentials, rather then API ML token that was in use before, so it seems to us that some rules around concatenation of the different fields in the Team Config have changed (see the examples of the configs are used by our client).

There is a big configuration that describes entire client's environment, so I reduced it to meaningful amount to represent the issue.

zowe.config.json

{
    "$schema": "./zowe.schema.json",
    "profiles": {
        "base": {
            "type": "base",
            "properties": {
                "rejectUnauthorized": true,
                "secure-ftp": true,
                "connectionTimeout": 10000,
                "protocol": "https",
                "encoding": 1146
            },
            "secure": [
                "user",
                "password"
            ]
        },
        "test-zowe": {
            "properties": {
                "host": "test.company.net",
                "port": 8080,
            },
            "profiles": {
                "zosmf": {
                    "type": "zosmf",
                    "properties": {
                        "port": 40443
                    }
                },
                "ndvr": {
                    "type": "endevor",
                    "properties": {
                        "basePath": "EndevorService/api/v2"
                    }
                }
            }
        }
    },
    "defaults": {
        "base": "base",
        "zosmf": "test-zowe.zosmf",
        "endevor": "test-zowe.ndvr"
    },
    "autoStore": false
}

zowe.config.user.json

{
  "$schema": "./zowe.schema.json",
  "profiles": {
    "test-zowe": {
      "profiles": {
        "zosmf-apiml": {
          "type": "zosmf",
          "properties": {
            "basePath": "/ibmzosmf/api/v1"
          }
        },
        "ndvr-apiml": {
          "type": "endevor",
          "properties": {
            "basePath": "/caendevorapi/api/v2"
          }
        }
      },
      "secure": ["token", "tokenValue"]
    }
  },
  "defaults": {
    "zosmf": "test-zowe.zosmf-apiml",
    "endevor": "test-zowe.ndvr-apiml"
  }
}

To Reproduce

Put a Team config files to ~./zowe folder and make sure that API ML token from the configuration is not used anymore.

Expected behavior

The config that is created between minor versions of the ZE extensions is expected to be working same way until the major version breaking changes or migration procedure is provided before such a change is happening in one of the minor version.

Is there a way to re-arrange the current config so it continues to work as expected?

Desktop (please complete the following information):

• OS: Windows, Mac
• Zowe Explorer Version: 2.18
• (Optional) Zowe CLI Version:
• (Optional) Are you using Secure Credential Store?

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[zFernand0]

Hey @roman-kupriyanov,

An investigation on our side shows that with the upgrade to ZE v2.18, the same profiles that were used before started to report basic credentials, rather then API ML token that was in use before, so it seems to us that some rules around concatenation of the different fields in the Team Config have changed (see the examples of the configs are used by our client).

History

There was a change in the imperative framework on how the AbstractRestClient (ARC) determined the type of authentication used. Since the release of Zowe V2, the ARC used to give precedence to the APIML token over basic authentication (token > basic). On Jul 26, 2023, we released version 5.16.0 of imperative which attempted to make the ARC consistent with the rest of CLI and ZE by preferring user:password over APIML tokens (basic > token). This was later reverted on Apr 30, 2024 with the Imperative version 5.23.1, where we introduced the concept of customizable authentication orders. With that new version (5.23.1), we went back to preferring APIML tokens over basic-auth (token > basic) but only on the ARC.

Action items

For a quick resolution, I recommend the following:

1. Re-publish/-upload any and all relevant V2 versions of Zowe Explorer to the marketplace:
   • Including, but not limited to: v2.9.0, v2.9.2, v2.10.0, v2.15.4, v2.16.0
2. Suggest E4E developers to advice their users to stay on ZE 2.15.4
   • That way they can move forward with the basic > token order.
3. Suggest updates to the E4E v1.8.2 extension to use the customizable authentication order feature.
   • This will allow future E4E V1 versions to work with ZE 2.18.x

Detailed information

ZE	E4E	CLI	Imperative	Notes
2.9.0	1.5.2	7.16.2	5.13.2	These are the version that used to work. This ZE version uses the token > basic order.
2.9.2	???	7.16.6	5.15.1	This ZE version uses the token > basic order.
2.10.0	???	7.18.0	5.18.0	This ZE version uses the basic > token order.
2.15.4	???	7.24.0	5.23.0	This ZE version uses the basic > token order.
2.16.0	???	7.24.3	5.23.2	This ZE version uses the token > basic order.
2.18.0	1.8.2	7.29.1	5.27.0	These are the latest V2 versions. This ZE version uses the token > basic order.

Sources

• Imperative 5.23.1
  • BugFix: Restore the previous precedence of token over password in AbstractRestClient
  • For a detailed description of the change, see
    • Reinstate token precedence over password in AbstractRestClient zowe-cli#2119