Support for multiple app installations is required

[gtema]

The plugin is really cool, sadly it does not fit our current needs and we would like to ask whether it is possible to:

• get rid of installation_id in the config
• get token should be able to get organization name, find installation_id and return token for this installation

Ideally it would be also cool if it is possible to have multiple apps maintained by the single plugin.

Thanks

[martinbaillie]

Please give the 2.0.0 RC a try and let me know if this is going to work for your use case. All credit to @grahamc if it does.

If it doesn't, as per https://github.com/martinbaillie/vault-plugin-secrets-github/pull/57#issuecomment-1030748313 let's explore what your use case is here and how we can accommodate it.

[gtema]

@martinbaillie, our use case is pretty simple. We have an app that manages GitHub organization (projects) settings. For that app has config in the form: org_name: {settings}. Integration of GH app inst_id sound to us absolutely unlogical, since it may change any time by uninstalling app and installing it again. On the other side figuring out installation id from the app logic already requires getting token what we want to avoid as much as possible. So what we need is a possibility for the app logic to request a token for particular organization by name without getting app token to fetch installation IDs or without saving installation IDs on the app side

[martinbaillie]

Ok I think I follow. We could add it back in as a parameter on /token and /permissionset as a compromise—would that work?

[gtema]

Yes, it should. Means plugin config should not require installation_id and requesting token through /token or /permissionset should accept org_name or inst_id. Configuring permissionset with org_name would be good, but not mandatory. Caching org_name to inst_id in the plugin can be also done - no problems with that, but in this case there must be some mechanism to trigger cache purge.

[martinbaillie]

Great. Ok I'll get something like that in the 2.0.0 RCs perhaps this weekend. I think caching is probably a premature optimisation and carries with it invalidation complexity as you said. Users of the org_name parameter will need to accept an extra round trip to the APIs and so should favour ins_id if calling the endpoint very frequently. I'll call that out in the documentation.