access_token is stored in global conf not local .aio

Tylopilus commented 3 years ago

Expected Behaviour

If I set a local context the access_token should be stored in local config file .aio

Actual Behaviour

local context get rewritten to global config and access_token is stored there

Reproduce Scenario (including but not limited to)

If a user has access to multiple programs he cannot switch the programs as long as the old access_token is stored in the global config file. This is irritating when a local config has been setup

Steps to Reproduce

Create a local config for programA with

aio config:set ims.contexts.aio-cli-plugin-cloudmanager PATH_TO_CONFIG_JSON_FILE --file --json --local
aio config:set ims.contexts.aio-cli-plugin-cloudmanager.private_key PATH_TO_PRIVATE_KEY_FILE --file --local

execute a command within /programmA

aio cloudmanager:list-programs

check for the access_token in .aio

Platform and Version

❯ aio info                                                                                                                                                                                      18:25:30

  System:
    OS: macOS 11.2.2
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 24.42 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 12.20.1 - ~/.nvm/versions/node/v12.20.1/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.10 - ~/.nvm/versions/node/v12.20.1/bin/npm
  Virtualization:
    Docker: 20.10.5 - /usr/local/bin/docker
  npmGlobalPackages:
    @adobe/aio-cli: 6.0.0
  CLI plugins:
    @adobe/aio-cli 6.0.0 (core)
    @adobe/aio-cli-plugin-app 6.0.0 (core)
    @adobe/aio-cli-plugin-auth 2.4.0 (core)
    @adobe/aio-cli-plugin-certificate 0.2.1 (core)
    @adobe/aio-cli-plugin-cloudmanager 1.3.5 (user)
    @adobe/aio-cli-plugin-config 2.3.0 (core)
    @adobe/aio-cli-plugin-console 3.2.0 (core)
    @adobe/aio-cli-plugin-events 1.1.0 (core)
    @adobe/aio-cli-plugin-info 1.1.1 (core)
    @adobe/aio-cli-plugin-runtime 3.1.0 (core)
    @oclif/plugin-autocomplete 0.3.0 (core)
    @oclif/plugin-help 2.2.3 (core)
    @oclif/plugin-not-found 1.2.4 (core)
    @oclif/plugin-plugins 1.9.5 (core)
    @oclif/plugin-warn-if-update-available 1.7.0 (core)

Sample Code that illustrates the problem

Logs taken while reproducing problem

if a different program defined in .aio wants to be accessed the access_token in global config prevents it: › aio cloudmanager:list-programs
› Error: [CloudManagerSDK:ERROR_LIST_PROGRAMS] Cannot retrieve programs: https://cloudmanager.adobe.io/api/programs (403 Forbidden) - Detail: Profile is not valid (Code: 403025)

justinedelson commented 3 years ago

@shazron This seems to be a problem within @adobe/aio-lib-ims -- as far as I can tell, both the reading and writing of the configuration is internal to getToken although there is some extra access in this plugin to the context data (before calling getToken) to extract out the client_id and ims_org_id

Would you agree?

shazron commented 3 years ago

Here's what's happening in persisting the token, the local parameter used is the default (which is false):

The config data is consolidated from local/global/env -- when getting a config value (say from the ims context) the caller doesn't know whether the value is local/global. This should be filed as an enhancement for evaluation under the aio-lib-ims repo (I can move it there if you want).

justinedelson commented 3 years ago

moving it is fine with me @shazron although I assume eventually there will need to be an issue here to take advantage of that potential enhancement.

I'm also wondering if there needs to be an enhancement in aio-lib-config so that the configuration "source" (local/global/env) is available as part of the configuration object -- otherwise how would aio-lib-ims know how what parameter to pass. But perhaps that should be evaluated after moving.

meryllblanchet commented 3 years ago

cc @sarahxxu for feedback

aiojbot commented 3 years ago

JIRA issue created: https://jira.corp.adobe.com/browse/ACNA-1144

kwin commented 4 weeks ago

@shazron I think it should be possible to expose the config source from src/ConfigCliContext (https://github.com/adobe/aio-lib-ims/blob/0ba538fc712329b5b7a7b2aec8536b7275742417/src/ctx/ConfigCliContext.js#L55C11-L55C23). That could be leveraged inside https://github.com/adobe/aio-lib-ims/blob/0ba538fc712329b5b7a7b2aec8536b7275742417/src/token-helper.js#L155 to also persist the access_token/refresh_token in the same location. WDYT?

RemoLiechti commented 3 weeks ago

This prevents us from using our aio cli tooling in a multi tenant environment for AEM RDEs. We need to be able to store the login information in an own defines context within a local config, to switch between AIO user accounts properly. It's the last piece in the puzzle to reach an independent login functionality. @shazron please let me know when you can provide a fix and how I can help to test, thank you!

shazron commented 1 week ago

PR https://github.com/adobe/aio-lib-ims/pull/150

adobe / aio-lib-ims