Nested configuration file issues seen by extenders

[JillieBeanSim]

Describe the bug

using a parent profile as opposed to a base profile. This is a problem implementing this in my VSCode Explorer extension . I provide the means to allow the user to set his credentials in my Explorer extension as an alternative to forcing the user to have zowe cli installed .
I have it working fine with various combinations of profile but not when using an untyped parent profile with typed profiles beneath.
if I put SecureArgs in that parent as per your article, there is no way as far as I can see of retrieving that untyped parent profile using ProfInfo as it is not typed and there is no easy way of knowing that a child profile is in fact a child .
zowe cli does all this without any issues but not so the VSCode Extensionwhwre it is proving to be a nightmare .
Any suggestions as to what I seem to be missing here?
Thanks
David !!

cont.

could do what the zowe config secure —gc does by using profInfo.getTeamConfig().api.secure.secureFields()
It returns the full pathname of the arg which is fine but it still leaves the problem of identifying what the argument type is and then how to update it back to the vault.
So the arg could be ‘user’ but we need to know if it is a string etc and putting it back to the vault isn’t easy as profInfo.updateProperty requires a profile type and again the root profile is untyped !
It seems way more complicated than it needs to be in my humble opinion.. even more so for us trying to get this to work in the VSCode Extension world

may be related to #2264

We cannot assume how the team configuration file is laid out with the schema supporting so many different ways of configurations. Not sure if this should be solved at our API level or the imperative's IProfileInfo level and should be discussed across squads to determine the best solution for all CLI and VSC ZE extenders for profile management.

To Reproduce

Expected behavior

Screenshots

Desktop (please complete the following information):

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

Additional context

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

This may be related to:

• How to access a root untyped profile using profInfo.getAllProfiles?  zowe-cli#2185

[davidkjackson54]

I have spent a little time looking at zowe config secure —gc and I think I see why it doesn’t show existing values but instead the user must enter new values without knowing what is there currently.
You can issue the secureFields method and it returns the pathnames of the entries in the vault and you can change a value and issue config.set to replace the value then follow that with config.save to update the vault.

But sadly there seems to be no method that can retrieve the secure values after having issued the secureFields . Hence why I suspect that zowe config secure —GC doesn’t show the values…

Can you confirm?? So I can stop searching and scratching my head

It appears the only way to get the secure values is to issue the mergeArgsForProfile which seems way overkill and doesn’t really help when it comes to promoting the user specifically for type profiles as in the case of top level parent profiles.

My only workaround is that I simply go and access the vault directly outside of zowe and retrieve the path names directly plus the associated secure value . Kludgy to say the least

To me, issuing secureFields should/could have provided the additional option that the other methods provide and added { getSecureVals=false} and allow the user to override.. that would make it so much easier and wouldn’t break anything. And provides the benefit of giving the arg values for the associated pathnames and could also help the clinuser with zowe config secure —gc and display existing values (except for password)

[zFernand0]

After some discussion, we plan to investigate a workaround in the Zowe Explorer APIs to address this issue in V2. However, a more robust implementation (where ProfileInfo APIs are schema-independent) will be considered for V3 😋

[davidkjackson54]

Hi Fernando- I think that allowing SecureFields to optionally return the argValue and argType would go some way to alleviating the problem.
As it is currently with an untyped profile we don’t know the arg type for an untyped profile as there is no schema and mergeargsForProfile is quite a convoluted approach.
Even zowe config secure —gc doesn’t actually validate the entered value for an arg - e.g. if the argType is ‘user’ - any value can be entered which can easily be invalid as it doesn’t go through any validation. With the argType it would be easy to validate the entered value to be a valid TSO userid.
We can of course surmise the argType by extracting the part of the pathname from secureFields but still a little kludgy.
Equally I could get the current value by going directly into to the vault and extracting the value myself - but zowe should really be providing this again as part of the secureFields method.

[zFernand0]

This issue should be addressed by:

• Enhance secureFields method to optionally return arg value, type, and name zowe-cli#2206

[zFernand0]

The PR linked in this issue should address this since it contains the latest version of the vNext SDKs that introduced the new secureFieldsWithDetails to ProfileInfo.

• Update next with latest Zowe SDKs #3087