Skip to content
This repository has been archived by the owner on Nov 13, 2023. It is now read-only.

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

Closed
davidkjackson54 opened this issue Aug 3, 2023 · 9 comments · Fixed by #1010
Closed
Labels
bug Something isn't working priority-medium Not functioning - next quarter if capacity permits severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex.

Comments

@davidkjackson54
Copy link

davidkjackson54 commented Aug 3, 2023

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

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

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

image

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.

@davidkjackson54 davidkjackson54 added the bug Something isn't working label Aug 3, 2023
@github-actions
Copy link

github-actions bot commented Aug 3, 2023

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 t1m0thyj added the for-review To be reviewed in an Eng & Prod Mgmt meeting label Aug 4, 2023
@davidkjackson54
Copy link
Author

@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
Copy link
Member

t1m0thyj commented Aug 7, 2023

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
Copy link
Author

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

@JTonda JTonda added priority-low Legit issue but cosmetic or nice-to-have severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex. priority-medium Not functioning - next quarter if capacity permits and removed for-review To be reviewed in an Eng & Prod Mgmt meeting priority-low Legit issue but cosmetic or nice-to-have labels Aug 7, 2023
@davidkjackson54 davidkjackson54 changed the title Getting different session created in VSCode Explorer compared to cli plugin session Presence of tokenValue in profile should take precedence over user and password Aug 8, 2023
@davidkjackson54
Copy link
Author

@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
Copy link
Member

t1m0thyj commented Aug 28, 2023

@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
    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:

@davidkjackson54
Copy link
Author

davidkjackson54 commented Aug 28, 2023 via email

@t1m0thyj
Copy link
Member

t1m0thyj commented Aug 29, 2023

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
Copy link
Author

davidkjackson54 commented Sep 18, 2023

@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;

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working priority-medium Not functioning - next quarter if capacity permits severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants