How to access a root untyped profile using profInfo.getAllProfiles?

[davidkjackson54]

I have a VSCode Explorer extension where I allow the user to manage credentials.
This works fine for the instance whereby the secureArgs are present in the system profile - or defined in the default base profile.

However, there is an article from the zowe folk - https://medium.com/zowe/password-management-for-zowe-cli-profiles-c57f64d1fe88
suggesting that the preferred method is to not use the base profile but instead specify a top level root profile that is untyped.

Something like this:

SecureArgs are present in the top level but also in a system profile to allow the user to specifically enter credentials for that system.
The problem arises in that there seems to be no obvious method in a VSCode extension to get that top level untyped profile . I use profInfo.readProfilesfromDIsk followed by profInfo.getAllProfiles but you can only retrieve typed profiles.

There doesn't seem to be any way of retrieving that top level untyped profile - or indeed know if such a top level profile exists.
Equally how do I update an untyped profile as profInfo.,updateProperty takes in propOpts one of which iso the profile name - so won't work for an untyped profile.

{
    "$schema": "./zowe.schema.json",
    "profiles": {
     "D001": {
       "properties": {
         "host": "myHost",
          "protocol": "https",
          "rejectUnauthorized": false,
       },
       **"secure": [
         "user",
         "password"
       ],**
       "profiles": {
           "u830all": {
             "type": "zmf",
             "properties": {            
               "port": 9990
             }
         },
           "u830dp": {
             "type": "zmf",
             "properties": {
              "port": 9991
             },
             **"secure": [
                "user",
               "password"
             ]**
          }
        }
       }
     }
  }

[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.

[t1m0thyj]

@davidkjackson54 Thanks for reporting this!

We plan to enhance the updateProperty method so that it supports typeless profiles. Even if getAllProfiles returns only typed profiles, this makes it possible to update credentials that are inherited and have a jsonLoc pointing to a higher-level typeless profile:

await profInfo.updateProperty({ profileName: "D001", profileType: null, property: "password", value: "XXX" });

[davidkjackson54]

Sadly that isn’t going to help in any great way.
It is still not going to retrieve the existing secure values already stored.
Are you saying that you will NOT enhance secureFields to optionally retrieve the secure args and the argType? As that solves the problems quite easily.
As it stands zowe config secure — gc is very basic and doesn’t offer the user any display of existing args and does no validation of what is entered so a user can enter any value to the Userid prompt and it is accepted regardless.

For the VSCode user I want to offer a webview that shows the existing values and allow the user to over type.

[t1m0thyj]

Are you saying that you will NOT enhance secureFields to optionally retrieve the secure args and the argType?

Would the desired behavior be a method that returns an array of all secure fields defined in the following format?

{
  argName: 'password',
  dataType: 'string',
  argValue: undefined,
  argLoc: {
    locType: 1,
    osLoc: [ '/Users/Timothy/Projects/zowe/zowe-cli/zowe.config.json' ],
    jsonLoc: 'profiles.D001.properties.password'
  },
  inSchema: true,
  secure: true
}

[davidkjackson54]

If we use secureFields and we are provided the argValue, argType and argName - that would suffice.
With that, we can present existing values and allow the user to overtype and then we can put the updates path values back into the vault in the same manner that zowe config secure —gc does currently.

I will be able to validate that an entered value is correct - if it is argType user I can ensure that it is a valid TSO format. If for example rejectunauthorized were a secure field and therefore presented by secureFields , I can ensure that the field is treated as a Boolean and validated as such.
I don’t thing much more would be necessary beyond that.

[t1m0thyj]

There seem to be 3 related fixes/enhancements which should probably be tracked as separate issues:

• Support access to untyped profiles using profInfo.getAllProfiles - this issue
• Enhance secureFields method to optionally retrieve argValue, argType and argName:
  Enhance secureFields method to optionally return arg value, type, and name #2206
• Allow setting properties in untyped profiles using profInfo.updateProperty:
  Support updating properties for typeless profiles in ProfileInfo API #2196

[davidkjackson54]

I think that probably makes sense .