Repository navigation
Support auto-loading appropriate ims context based on program id mapping #198
Description
Activity
@kwin this is an interesting idea, but it seems like the workflow is already available in the
aio-cli-plugin-config/aio-lib-core-configwhere you have a different config per directory. Does that not work for you? In other words, you'd do$ cd accountA $ aio config:set --local ... $ cd ../accountB $ aio config:set --local ...And then
$ cd accountA $ aio cloudmanager:list-programs [programs for accountA]$ cd accountB $ aio cloudmanager:list-programs [programs for accountB]@justinedelson Thanks for that hint, I wasn't aware of that option. I have two concerns with that option
- It will distribute sensitive information on the hard disk as it won't encrypt the values. I opened Store sensitive data in system keychain aio-lib-core-config#52 for this.
- There is no recursive fallback to the local config of the parent directory (i.e. it only works in exactly that directory but not any subdirectories, https://github.com/adobe/aio-lib-core-config/blob/3d1dedc0f8d59e2d220d2d99ad298d0413595bb2/src/Config.js#L43)
In any case I think it would be good to extend the readme a bit in https://github.com/adobe/aio-cli-plugin-cloudmanager#authentication to clarify that by default only one JWT is stored and what the options are to store multiple ones.
- added 3 commits that reference this issue
on Feb 6, 2021 FYI @kwin I have taken this as a sign to go ahead and update the migration to @adobe/aio-lib-ims. I've been avoiding this because it is a breaking change (in an edge case, but still...) and supporting this use case would make migration impractical. I still have a bit of manual testing of the migration process to do before merging #130. But once that is merged you will be able to create N number of non-default ims contexts (see https://github.com/adobe/aio-lib-ims#configuration) and specify one of those by passing
--imsContextName=<non-default context>This is a nice improvement. Still I would like to have a mapping from imsContextName to programId built int aio-cli-plugin-cloudmanager . That way you only have to establish the mapping once, and there is no need to pass the imsContextName to every command.
Either one can use a naming convention for imsContextName or maintain a (persisted) mapping table.- changed the title
[-]Support storing multiple authentications in parallel[/-][+]Support auto-loading appropriate ims context based on program id mapping[/+]on Feb 6, 2021 OK. I've updated the title of this issue. I'm not fully sure I understand the workflow you are envisioning here so I would encourage you to submit a pull request.
Currently only one Adobe IO JWT can be stored inside the aio config (because only the key
jwt-auth) is used. For working with multiple accounts in parallel it would be beneficial if multiple JWT authentication configs could be stored in parallel and bound to specific Cloud Manager Program ID.Maybe supporting a key config naming scheme like
jwt-auth.<program-id>would be sufficient. If no such key is found, the fallback could be the keyjwt-auth.