Vscode-extension-for-zowe: Profiles not automatically updating contained values in VSCode when changed externally

[Colin-Stone]

When a profile is updated for example the password is changed, the new value is not pushed to the profile in VSCode and VSCode continues to use the old value.

Need to investigate why this is happening if possible remove any local storage of credential details Otherwise we will need a refresh option

[zFernand0]

I'm wondering if restarting VSCode serve as a workaround?

[Colin-Stone]

I'm wondering if restarting VSCode serve as a workaround?

That does work, yes. I will still look into this further as I managed to get my id revoked :-(

[bearou]

Hi @Colin-Stone ;
Further to this issue: is it just me or do you still have to key in the password for the zowe profile in plain text ? If so, this is a major obstacle for further roll-out of Zowe VSCode extension in our organisation.

[Colin-Stone]

Hi @Colin-Stone ;
Further to this issue: is it just me or do you still have to key in the password for the zowe profile in plain text ? If so, this is a major obstacle for further roll-out of Zowe VSCode extension in our organisation.

Yes, it's a good point.
When CLI was first conceived it was from the perspective of being integrated into a DevOps environment in which references such as user names and passwords can be hidden within the build tool itself. Within the VScode extension there is no obvious way we can do the same type of thing yet. However this is an area we are very keen to address and are very open to ideas and suggestions of how we should tackle this.

[MikeBauerCA]

The CLI does not strictly require profiles. All profile options can be provided directly on the command line or via environment variables. Therefore storing the password on disk is optional. Similarly, we intend to eliminate the need to store the password on disk to use this VS Code extension as part of #226.

The advantage of storing connection details and credentials is that you need to provide this information less frequently. There is a Zowe conformant (https://www.openmainframeproject.org/projects/zowe/conformance) Secure Credential Store Plug-in for Zowe CLI that lets you store your credentials securely in the default credential manager of your operating system.

[dboudreaux]

For context: The urgent issue is a password expires or is locked out. You get it unlocked, go to the CLI in VS Code terminal ... via CLI update your profile with new password (There is no way to refresh or update zowe explorer). I then click in Zowe explorer and it fails... so you keep trying other favorites (as you don't know why it failed)... then you lock out your id again ... and the loop continues.

[zFernand0]

Since we now have the ability to Create "profiles" within VSCode, Maybe editing, updating/refreshing, and/or deleting could be useful to resolve the issue?

[MikeBauerCA]

This is a significant issue. Creating profiles is also a difficult manual task so it is a candidate for automation. For example, in my projects I run gulp setupProfiles to setup several profiles for my project. This way onboarding developers do not need to spend time creating profiles. The task simply prompts for host, username, and password and the rest of the information is in a config file.

After this task is run, a refresh of the Zowe Explorer is required which is unintuitive. As @dboudreaux mentioned, this can cause password lock outs which are painful and would deter adoption if it occurred. @jalel01, can you please assign someone to this one?

[jellypuno]

What we could do is add a refresh button next to the profile name that you will have to manually click to call Profiles.refresh() function. Would this be okay? @MikeBauerCA @Colin-Stone @dboudreaux @jalel01

[Colin-Stone]

We already have a refresh button at the container level. It links to intended to refreshAll but I think it could also refresh the profile at the same time.

The problem in my mind is making sure we clear any cache that contains the information

[phaumer]

Some of the code I wrote last week contributed to the problem. It was related to the discussion we had in this PR https://github.com/zowe/vscode-extension-for-zowe/pull/440#issuecomment-577094581 related to the prompting behavior (that was added while I was working on my PR) that when you created an invalid profile manually without a password that Zowe Explorer would prompt you. If you then accidentally typed the password wrong then there was no way of resetting it; you have to stop and start VS Code. I was told that this was being worked on in another request. I therefore implemented the same behavior for Profiles: that they remember the passwords that got entered in memory and even add them back after a refresh. That has led to this defect that when user change the password the you still have the old password in the memory cache, which is consistent with the behavior from before.

What we have to do is to decide if our current Refresh button should make the manually entered password forgotten and the user gets prompted again next time or if we want a separate refresh command for reseting cached password. I think the former is the easiest solution and can be achieved by just removing my password cache in the Profiles.ts that is marked with TODO. Then when a refresh is performed and the user tries to open a file in a profile without credentials it would need to re-prompt the users.

As the promptCredentials() business logic is currently implemented redundantly in 14 different places throughout the codebase, and uses a JavaScript-styled approach for passing untyped objects, it is very hard to maintain and enhance. That's why I decided not to tackle it in my PR, but to reproduce the current behavior of not refreshing passwords. I think we need to rethink that workflow and rewrite the code in one central place.

[jelaplan]

Refresh is better than restarting but also, not always intuitive. If the user thinks to refresh then that great but if not, they are liable to try a variety of other things and either fail or get locked out.

If the ext loads the user and pass into memory, and in the mean time it becomes no-longer valid or no longer consistent with the stored profile, interactions like searching for a ds would produce an error for wrong password. The rub here is that user then needs to have in mind refresh the profile as a debug step which is a dubious assumption. So, how about we consider doing a few things

1. Add a manual refresh as is suggested. I'd prefer to re purpose the existing refresh All icon.
2. If the user gets a login error, auto-refresh the connection details from the profile. That way if the profile has changed and the user tries again, things should work the second time and the user might avoid the dread lockout. We might want to give the user some feedback that the profile was refreshed and new values were found.
3. Poll the profile periodically in the background to make updates. Once a minute or something like that. That will still leave a window time when the connection details aren't synced to the profile but it would probably catch most updates. I'd guess we'd want some feedback here as well to inform the user of a profile change. I don't know if polling like this would be a bad thing for performance etc.

Note, it would be nice if the Zowe Extension could listen for an event to happen when a profile is changed. That way, we could push the changes. I have no clue if that is even a thing that could be but my experience with events in JavaScript programming is that they solve this kind of problem.

[jelaplan]

Someone mentioned editing profiles. There is a story for that. I think that story would need to taken into account syncing between the in-memory values and the on-disk profiles.
link to https://github.com/zowe/vscode-extension-for-zowe/issues/319

[jelaplan]

@bearou I wonder how you feel about user name and password being stored in an encrypted manner on disk? We've talked to people who were ok with that and mentioned SSH and other similar situations. But, others were firmly opposed. @MikeBauerCA mentioned the use of the Secure Credential Store plugin to encrypt user and pass on disk which works with the Zowe Explorer extension.

Another effort around this is to implement a token based authentication scheme and encrypt the tokens to avoid storing user and pass on local disk. @dkelosky wrote a Medium article about the this topic.

[dboudreaux]

To me a fix is when a user clicks on zowe explorer (on-control) that changes like profiles should be checked. Using the refresh button is better than restarting the IDE, but only a workaround.

[jellypuno]

I would like to comment on few things:

1. Add a manual refresh as is suggested. I'd prefer to re purpose the existing refresh All icon.

I can do this now. This is the easiest solution. @jalel01 what do you think?

1. If the user gets a login error, auto-refresh the connection details from the profile. That way if the profile has changed and the user tries again, things should work the second time and the user might avoid the dread lockout. We might want to give the user some feedback that the profile was refreshed and new values were found.

Please take into consideration that some functionalities of Zowe Explorer fires 2-3 APIs or more. It will be locked out if you tried again the second time. #370 requests for re-prompting of credentials once 401 is encountered. For me, that is a better solution.

Poll the profile periodically in the background to make updates. Once a minute or something like that. That will still leave a window time when the connection details aren't synced to the profile but it would probably catch most updates. I'd guess we'd want some feedback here as well to inform the user of a profile change. I don't know if polling like this would be a bad thing for performance etc.

There will be performance issues if this will be implemented. Issue #327 already shows the capability of Zowe Explorer in regards to Large amount of datasets. If there is an auto-sync of profiles and you are working on large number datasets, expect performance issues.

[Colin-Stone]

I'd prefer to re purpose the existing refresh All icon.

Just to clarify. What I was originally thinking was not that it's re-purposed to do the profile refresh but it does the profile refresh in addition to currently refreshing the trees.

[jalel01]

@jellypuno Yes to adding profile refresh to the refresh all icon for now. We will need to consider a more permanent solution as part of an editing profiles enhancement.

[jellypuno]

Bug found #510

[jelaplan]

370 requests for re-prompting of credentials once 401 is encountered. For me, that is a better solution.

I looked up 401 which seems to mean the page you were trying to access cannot be loaded until you first log in with a valid user ID and password. So, in that situation, re-prompting seems like a good approach. The user who may have updated their profile with CLI may find this prompt slightly inconvenient because they have to once again enter credentials. But it seems like it will solve the problem. Question is whether entering that information will update the profile?

[jelaplan]

I'd prefer to re purpose the existing refresh All icon.

Just to clarify. What I was originally thinking was not that it's re-purposed to do the profile refresh but it does the profile refresh in addition to currently refreshing the trees.

That is what I meant as well.

[jellypuno]

Fix was added in #525