#75 Add back configurable access token creation plugin support

[fmeschbe]

Description

Implementing the feature proposal of issue #75:

• Two methods setPlugins and getPlugins added to the Context class
• Overwriting implementation in the ConfigCliContext class using the plugins configuration property for pesistence
• StateActionContext does not overwrite these methods as configurable token creation plugins are not part of this proposal. They might be added in the future.
• Updated token-helper.js to support configurable plugins:
  • Merge default plugins with configurable plugins
  • Lazy load all plugins only as required (also applied to the default plugins for consistency and marginal performance improvement)

Related Issue

#75 Add back configurable access token creation plugin support

Motivation and Context

I have use cases for different ways of creation access tokens beyond what the default plugins offer. Having configurable token creation plugins solves my needs for easy extensibility.

How Has This Been Tested?

Added test cases and tested with my own token creation plugins.

Screenshots (if appropriate):

n/a

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #76 (7aa6b7e) into master (a4839cc) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #76   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          426       464   +38     
  Branches        56        62    +6     
=========================================
+ Hits           426       464   +38     

Impacted Files	Coverage Δ
src/context.js	100.00% <100.00%> (ø)
src/ctx/ConfigCliContext.js	100.00% <100.00%> (ø)
src/ctx/Context.js	100.00% <100.00%> (ø)
src/token-helper.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4839cc...7aa6b7e. Read the comment docs.

[moritzraho]

Have you had the chance to test the ims lib in a runtime action? Otherwise we will test it, the reason we do a static require is to let webpack optimizer know it has to include the '@adobe/aio-lib-ims-jwt' module when bundling/compiling the action code

[fmeschbe]

Nope, only tested the CLI, actually.

That is a good point regarding web pack. Can web pack be instructed to consider this dependency also in another way ?

If not we could revert this to be a static import and adapt the loadPlugin function accordingly.

[fe-lix-]

I'm trying to understand better how web pack is working, but a quick and dirty solution to this issue would be :

diff --git a/src/token-helper.js b/src/token-helper.js
index c2c37ae..9b774a3 100644
--- a/src/token-helper.js
+++ b/src/token-helper.js
@@ -13,7 +13,7 @@ governing permissions and limitations under the License.
 const { Ims, ACCESS_TOKEN, REFRESH_TOKEN } = require('./ims')
 const aioLogger = require('@adobe/aio-lib-core-logging')('@adobe/aio-lib-ims:token-helper', { provider: 'debug' })
 const { getContext } = require('./context')
-const imsJwtPlugin = '@adobe/aio-lib-ims-jwt'
+const imsJwtPlugin = require('@adobe/aio-lib-ims-jwt')
 const { codes: errors } = require('./errors')
 
 /**
@@ -80,6 +80,10 @@ async function getMergedPlugins (context) {
 function loadPlugin (name, location) {
   aioLogger.debug('loadPlugin(%s, %s)', name, location)
 
+  if (name === 'jwt') {
+    return imsJwtPlugin
+  }
+
   try {
     return require(location)
   } catch (error) {

[purplecabbage]

@fmeschbe Do you have pseudocode of how a plugin would be used here?

[fmeschbe]

Do you have pseudocode of how a plugin would be used here?

@purplecabbage I am not sure, where this question goes as the usage of plugins is here in the tokenhelper.js/_generateToken function and this looks pretty clear to me:

plugins = getMergedPlugins()
for plugin in plugins {
  pluginObject = loadPlugin(plugin)
  if (pluginObject.supports(config)) {
    try {
      return pluginObject.createToken(...)
    } catch {
      // log or fail
    }
  }
}

The main changes to existing code are (a) getting a merged list of plugins from the static configuration in the code and the dynamic configuration in the config and (b) on-demand loading the plugin as needed/required

[fe-lix-]

Updated the PR with current master branch.