Vscode-extension-for-zowe: Allow VS Code Extension Settings of Connection Information

[MikeBauerCA]

We should consider removing the strict dependency on Zowe CLI Profiles. As part of this effort, we would need to provide a means of entering connection details directly within the VS Code extension.

However, as a heavy Zowe CLI user I would like to continue having the ability to use profiles I defined in the CLI. Therefore, we should not remove the current integration.

• [x] Add Connection Details using (+) Button
  - [x] Set-up Default JSON Format for Profile Configuration
• [x] Add "Create New" Dialog boxes for profile creation
  - [x] Update JSON file "Create New" once the dialog boxes are successfully filled - @jellypuno
• [x] "Create New" dialog boxes should always be an option. Whether you have loaded profiles or not. - @jellypuno
• [x] New Profiles/ existing VSC Profiles are displayed in the containers - @crawr
• [x] Update JSOn file for the new error/informational messages - @crawr
  - [x] If you have existing profiles in the settings.JSON, it should be loaded as well when the add profile is selected. Follow the process with loading of CLI profiles
  - [ ] Edit profiles available in the containers -@jellypuno
  - [ ] Delete profiles available in the containers -@jellypuno
• [x] Refresh Connection - @jellypuno
• [x] We are asking for the URL, hostname and port should be trimmed if we use the new profile to call zowe functions
  - [x] Research VSCode Extension guidelines on how to modify settings
  - [x] Add connection details in settings.JSON
• [x] Password; Don't store PW > don't ask at creation of connection > prompt at 1st usage > store (in session variables?)
  - [ ] Implement order of precedence when loading default profiles (Zowe CLI followed by VSCode)
• [x] Test coverage

Notes:

VSCode Docs

• https://github.com/microsoft/vscode-extension-samples
• https://code.visualstudio.com/api/references/vscode-api
• https://code.visualstudio.com/api/references/contribution-points

[IgorCATech]

@jalel01 Does removing the dependency on CLI profiles mean that having Zowe CLI as a prerequisite is no longer needed?

[MikeBauerCA]

@IgorCATech yes, but we will want to document the CLI profile versions we have integration with.

[IgorCATech]

@MikeBauerCA I'm not entirely sure what you mean by this. Do you plan to have 2 versions of the extension: 1 - that allows using the Zowe extension without CLI profiles, 2 - the one that needs to have CLI profiles to be able to run? What does "CLI profile versions" mean?

[MikeBauerCA]

@IgorCATech, one version of the extension.

Users can store their connection details in VSCode directly so they do not need to have CLI profiles.
If users want to continue storing their connection details in CLI profiles as they do today, they do not need to change anything. The extension will be able to read from both locations.

Personally, I will continue to use CLI profiles since I am a CLI user and do not see a need to store connection details for use with the VSCode Extension but not with the CLI. That said, I recognize that others may wish to only use the VSCode extension and they should not have to install the CLI and create a CLI z/OSMF profile to do so.

Today, the VSCode extension does not depend on the CLI being installed. It only depends on the CLI profiles being defined. In the README, it is stated that Important! To use the VSC Extension for Zowe, you must install Zowe CLI version 2.0.0 or later. but we technically only need Zowe CLI z/OSMF profiles to have been created using version 2.0.0 or later. The z/OSMF profiles created before 2.0.0 were in a different format I believe.

[IgorCATech]

That makes perfect sense! Thanks for the explanation.

[MikeBauerCA]

We should also consider not storing the username as this may be considered sensitive information as well.

[MikeBauerCA]

During today's Zowe CLI Standup, it was decided to store the username until we hear feedback from users that they would rather not store this information.

If this feedback is received, we should consider making the username field optional when setting connection details. Then, if the username for a specific connection is not defined, when needed the extension could prompt the user for both their username and password.

[phaumer]

@MikeBauerCA Would it make more sense that the extension would actually create Zowe profiles instead of storing in a different format? Then extensions users can create profiles graphically, but also open a Terminal in VS Code and run CLI commands and scripts? What is the advantage of having something that can only be used in the extension? They would have to enter the same info twice if they want to switch between UI and CLI.

Standardizing on profiles in Zowe makes a lot of sense to me to be able to even add more editors in the future. The vision is that whatever your editor of choice is you can create your profile once and switch between them without reconfiguring and reentering your credentials.

[MikeBauerCA]

@phaumer I love the idea of enabling CLI users to be able to create their profiles graphically.

Adopting this strategy, a user could also start with the VS Code extension and then later adopt the CLI and be able to use the profiles they already created.

For users who do not want to store their username and password, we could elect to make these fields optional in the CLI z/OSMF profiles (and all profiles for that matter) and the VS Code extension could prompt for these fields when needed if they are not supplied.

In a Theia environment, do you see any difficulty with the extension being able to access the user's home directory?

@jalel01, what are your thoughts on this?

[phaumer]

@MikeBauerCA we did a lot of work with Docker containers with Theia, the Zowe VS Code Extension, and CLI. Works great.

[jalel01]

Yes, i can see how standardizing on this would remove some of the current complexity for end users.

[jelaplan]

@MikeBauerCA I'm glad you raised the possibility of optionally storing username and password. That came up this morning in a call. Some people are opposed to storing that information for security reasons and for practical reasons of the pw expiring and folks not knowing how to change. So, I think that that would be a firm requirement.

A benefit of the common profile approach is not only that folks could create profiles using a GUI but that they could edit profiles with a GUI. So even folks who create a profile with the CLI could edit that with the VS Code GUI. That does raise the question for me about securely storing those passwords and support editing those encrypted passwords.

[jelaplan]

I added a related issue about making user name and password optional in the profiles. This ties into efforts on the VS Code extension where a user can create a connection without storing the user name and password.
https://github.com/zowe/zowe-cli/issues/538

[phaumer]

I am looking at the https://github.com/zowe/vscode-extension-for-zowe/tree/NewProfiles branch and see that you removed the Profiles class and replaced it with several files of loose functions. Why not keep one clean abstraction of loading and managing profiles?

[jellypuno]

@phaumer Thank you for checking the branch. This is a work in progress. I have yet to merge the latest profile changes from the master branch.

[phaumer]

Thanks. Perhaps we can coordinate this work with an idea we have for supporting other CLI plugins in the VS Code extension, which would also be CLI profile based. I am working on a prototype based on the current master branch's Profile class.

I filed this issue describing the general idea: https://github.com/zowe/vscode-extension-for-zowe/issues/279

[phaumer]

@MikeBauerCA @jelaplan @zFernand0 based on the discussion in Slack, do I assume correctly that the password management needs to be implemented in @zowe/imperative and not only for the VS Code extension; so that password are always secure even if users only work with the CLI and not the extension?

[zFernand0]

Hey @phaumer, Then answer is yes.
Whether we go the route of Obfuscation (:+1:) or using the OS credential mechanisms (:+1: :+1:), it's better to implement it in @zowe/imperative since this implementation will be considered a breaking change and we cannot disrupt people using the @brightside/core@lts-incremental version.
I hope this helps 😄

[dkelosky]

Just so that it's not lost; longer term - we plan to move more into management of tokens (JWT & LTPA2) instead of username & password. This should help as we prepare to support MFA enabled use cases.