Presence of tokenValue in profile should take precedence over user and password

[davidkjackson54]

In the cli plugin , I am using processWithSession that is being passed session:AbstractSession
The session looks like this: notice mISession

in my VsCode extension I use ProfileInfo.createSession(profile.mergedArgs.knownArgs); to create the session
When I hover over knownArgs:

and the resultant session that is created looks like this: Notice the presence of user, password, tokenType and tokenValue

My profile contents

"profiles": {
                "u820all": {
                    "type": "zmf",
                    "properties": {
                        "basePath": "/zmfrest",
                        "port": 9992,
                        "protocol": "https",
                        "zosmfProfile": "zosmf",
                        "tokenType": "JSESSIONID",
                        "tokenValue": "6033AA612A70926297D26E19840EC62A"
                    }
                },

secureArgs are not present in the system profile but instead defined in the default base profile

"default": {
            "type": "base",
            "properties": {
                "host": "d001.microfocus.com",
                "rejectUnauthorized": false
            },
            "secure": [
                "user",
                "password"
            ]

As a result, I am finding that when I issue my REST call passing session, the user and password are being used instead of the token. If I specify an invalid token this rest call still works. which would confirm that user and password are being used.

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

[davidkjackson54]

@t1m0thyj
I am also finding that after a Rest call, that the tokenValue is no longer the same value as it was on input. You mentioned that you had recreated the problem - did you also notice the change in tokenValue?

[t1m0thyj]

I am also finding that after a Rest call, that the tokenValue is no longer the same value as it was on input. You mentioned that you had recreated the problem - did you also notice the change in tokenValue?

@davidkjackson54 I recreated the problem in a slightly different way since I don't have access to ZMF, but this behavior seems consistent with user/password being used of token. When user/password are passed to the REST API, it likely returns a cookie with a new token in the response which causes Imperative to update tokenValue on the session.

Regarding the original issue you reported, I'm investigating it and will discuss with the team at our next standup.

[davidkjackson54]

@t1m0thyj
We certainly don't want a new token value returned. I have my own REST service that creates a specific product token that I then store in the profile. It is that token that should then be used for the session. It is being used correctly by my cli plugin using AbstractSession but being ignored by ProfileInfo.createSession - or rather the user /password are being used instead and the token value "corrupted".
Should be easy enough to recreate by simply adding tokenValue and tokenType with values for each into a profile and then use that profile in an Explorer and run it through ProfileInfo.createSession.

[davidkjackson54]

@t1m0thyj
If the user and password are in fact taking precedence over a token, then we need a means to be able to 'force' the token when required without resorting to a 'hack'.

[t1m0thyj]

@davidkjackson54 After investigating this issue further, I believe the expected behavior for Zowe CLI v2 is that user and password take precedence over tokenValue. I know this is the opposite of what you've requested, but will try to explain:

1. In Zowe CLI, the behavior I see when processWithSession is invoked for a "zos-files" command is the opposite of what you showed:
   
   Perhaps you've written a custom implementation of processWithSession that makes the token take precedence instead? I'm guessing this may be the case since processWithSession is not a method exported by the Zowe SDKs for extenders to use.
2. I was able to reproduce the ProfileInfo.createSession behavior where it includes both user/password and tokenValue on the session instead of picking one. This is a bug, and in order to be consistent with Zowe CLI the user/password should take precedence. I've opened a PR to fix this: Fix merging of profile properties in ProfileInfo.createSession #1010
3. Unfortunately, Zowe CLI and Zowe Explorer have inconsistent behavior - CLI gives precedence to user/password and Explorer gives precedence to tokenValue. At the time Zowe v2 was released, they were developed by different teams who made different design decisions. I recognize this inconsistency may be frustrating, but we can't change it until Zowe v3 since it would be a breaking change for either users of CLI or Explorer. In the meantime:
   • If you prefer for tokenValue to take precedence, you can implement that behavior by adding custom logic for session creation in your CLI plugin and VS Code extension.
   • I've created an issue to get community feedback on which order of precedence is preferred in v3 - feel free to express your opinion in the poll on v3: Should presence of tokenValue in profile take precedence over user and password? zowe-cli#1794

[davidkjackson54]

Timothy. I am not talking about Zowe Explorer but rather my own VSCode Extension and if I call profInfo then userid and password are taking precedence over the presence of a token. I need a means to be able to force the usage of a token without resorting to a hack in my extension code. David

…

On Mon, Aug 28, 2023 at 3:22 PM Timothy Johnson ***@***.***> wrote: @davidkjackson54 <https://github.com/davidkjackson54> After investigating this issue further, I believe the expected behavior for Zowe CLI v2 is that user and password take precedence over tokenValue. I know this is the opposite of what you've requested, but will try to explain: 1. In Zowe CLI, the behavior I see when processWithSession is invoked for a "zos-files" command is the opposite of what you showed: [image: image] <https://user-images.githubusercontent.com/22344007/263847948-0ed0ff19-16cb-4160-9b0d-fe420cd2715a.png> Perhaps you've written a custom implementation of processWithSession that makes the token take precedence instead? I'm guessing this may be the case since processWithSession is not a method exported by the Zowe SDKs for extenders to use. 2. I was able to reproduce the ProfileInfo.createSession behavior where it includes both user/password and tokenValue on the session instead of picking one. This is a bug, and in order to be consistent with Zowe CLI the user/password should take precedence. I've opened a PR to fix this: #1010 <#1010> 3. Unfortunately, Zowe CLI and Zowe Explorer have inconsistent behavior - CLI gives precedence to user/password and Explorer gives precedence to tokenValue. At the time Zowe v2 was released, they were developed by different teams who made different design decisions. I recognize this inconsistency may be frustrating, but we can't change it until Zowe v3 since it would be a breaking change for either users of CLI or Explorer. In the meantime: - If you prefer for tokenValue to take precedence, you can implement that behavior by adding custom logic for session creation in your CLI plugin and VS Code extension. - I've created an issue to get community feedback on which order of precedence is preferred - feel free to express your opinion in the poll on zowe/zowe-cli#1794 <zowe/zowe-cli#1794> — Reply to this email directly, view it on GitHub <#1008 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALAIHNE3IHLXXDSDYYODKL3XXUK2VANCNFSM6AAAAAA3DKOME4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[t1m0thyj]

The decision for user/password to take precedence over token was made to support the API ML - see Gene's comment here for more details.

For Zowe v3, we are considering changing the order of precedence or adding an option so that users can configure the order. This discussion is being tracked in zowe/zowe-cli#1794.

Until then, for Zowe v2 our recommendation is to resort to "a hack" in your extension code if you prefer for token to take precedence. That's what Zowe Explorer does:
https://github.com/zowe/vscode-extension-for-zowe/blob/main/packages/zowe-explorer-api/src/profiles/ZoweExplorerZosmfApi.ts#L59-L71

[davidkjackson54]

@t1m0thyj @zFernand0 . This is proving to be really painful. This in my VSCode Explorer code.
I am having to remove user and password before creating a Session in order to force zowe to create a type: token session instead of a type: basic session.
I do this using ProfileInfo.createSession
That in itself is OK - however the problem is that I use the userid field throughout my code and I get it from the currently active session - and now it is no longer present.

I can see no clean way of getting around how to 'force' creation of a type: token session without first removing user and password. Or a clean way of putting user and password back into the session after it has been created.

This seems somewhat of a hack

newSession.ISession.user = savedUser;
newSession.ISession.password = savedPassword;