-
Notifications
You must be signed in to change notification settings - Fork 28
Presence of tokenValue in profile should take precedence over user and password #1008
Comments
Thank you for creating a bug report. |
@t1m0thyj |
@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. |
@t1m0thyj |
@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:
|
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:
***@***.***>
|
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: |
@t1m0thyj @zFernand0 . This is proving to be really painful. This in my VSCode Explorer code. I can see no clean way of getting around how to 'force' creation of a This seems somewhat of a hack
|
In the cli plugin , I am using
![image](https://private-user-images.githubusercontent.com/46171060/258235114-df3ccb66-2a0c-4c02-8a3a-20e859d177a5.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5NjM1ODIsIm5iZiI6MTcyNTk2MzI4MiwicGF0aCI6Ii80NjE3MTA2MC8yNTgyMzUxMTQtZGYzY2NiNjYtMmEwYy00YzAyLThhM2EtMjBlODU5ZDE3N2E1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTEwVDEwMTQ0MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg5MDBkMzBiYzBlNTk4MDk5NjM1ODE1ZjU2NjE5Y2JkNDhlOTg5ZjQ5NTNjNjk1MjgwZDM3NDZlNWVkYmEzYjQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.am3iY3cYLDnRwa-iWF0-M0g29S9scI5V7K73GBDlHm4)
processWithSession
that is being passed session:AbstractSession
The session looks like this: notice mISession
in my VsCode extension I use
![image](https://private-user-images.githubusercontent.com/46171060/258236512-f3e7db15-44aa-4e97-864f-19efd2f59a56.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5NjM1ODIsIm5iZiI6MTcyNTk2MzI4MiwicGF0aCI6Ii80NjE3MTA2MC8yNTgyMzY1MTItZjNlN2RiMTUtNDRhYS00ZTk3LTg2NGYtMTllZmQyZjU5YTU2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTEwVDEwMTQ0MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWJhODk0MDM5ZDI2OTM0ZTM0YWNmYzFkOTVhM2Q3NmM5OWM0OWViNWM2ZWY5ZjI1NDFkYTRlOGE5ZTgzZGRlZTImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.DFVCnFZ1bNg4P7renD_ve-dIjAHAsy3r7JD0T5EuaOk)
ProfileInfo.createSession(profile.mergedArgs.knownArgs)
; to create the sessionWhen 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
secureArgs are not present in the system profile but instead defined in the default base profile
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.
The text was updated successfully, but these errors were encountered: