-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(api-server): ability to install plugins at runtime #764
Labels
API_Server
dependencies
Pull requests that update a dependency file
enhancement
New feature or request
Comments
petermetz
added
API_Server
dependencies
Pull requests that update a dependency file
enhancement
New feature or request
labels
Apr 2, 2021
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 3, 2021
The API server will now use npm as a dependency to install plugin packages before trying to import them (via require()) This is helpful in being able to ship a container image that contains the API server and does not need additional chores to be done in order to be able to use plugins (such as starting a new node package with its own dependencies). The security implications here are of course that we are pulling code form the internet at runtime and if npm's verification method for the code fails or if the plugin package is malicious to begin with then that's a full breach but these were security implications of the plugin architecture to begin with so there is not much additional that we can probably do here apart from a few addditional guard rails to protect users from themselves by maybe always requiring explicit versions so that auto-upgrade is out of the question. Fixes hyperledger#764 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 3, 2021
The API server will now use npm as a dependency to install plugin packages before trying to import them (via require()) This is helpful in being able to ship a container image that contains the API server and does not need additional chores to be done in order to be able to use plugins (such as starting a new node package with its own dependencies). The security implications here are of course that we are pulling code form the internet at runtime and if npm's verification method for the code fails or if the plugin package is malicious to begin with then that's a full breach but these were security implications of the plugin architecture to begin with so there is not much additional that we can probably do here apart from a few addditional guard rails to protect users from themselves by maybe always requiring explicit versions so that auto-upgrade is out of the question. Fixes hyperledger#764 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 5, 2021
The API server will now use npm as a dependency to install plugin packages before trying to import them (via require()) This is helpful in being able to ship a container image that contains the API server and does not need additional chores to be done in order to be able to use plugins (such as starting a new node package with its own dependencies). The security implications here are of course that we are pulling code form the internet at runtime and if npm's verification method for the code fails or if the plugin package is malicious to begin with then that's a full breach but these were security implications of the plugin architecture to begin with so there is not much additional that we can probably do here apart from a few addditional guard rails to protect users from themselves by maybe always requiring explicit versions so that auto-upgrade is out of the question. Fixes hyperledger#764 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
that referenced
this issue
Apr 5, 2021
The API server will now use npm as a dependency to install plugin packages before trying to import them (via require()) This is helpful in being able to ship a container image that contains the API server and does not need additional chores to be done in order to be able to use plugins (such as starting a new node package with its own dependencies). The security implications here are of course that we are pulling code form the internet at runtime and if npm's verification method for the code fails or if the plugin package is malicious to begin with then that's a full breach but these were security implications of the plugin architecture to begin with so there is not much additional that we can probably do here apart from a few addditional guard rails to protect users from themselves by maybe always requiring explicit versions so that auto-upgrade is out of the question. Fixes #764 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
API_Server
dependencies
Pull requests that update a dependency file
enhancement
New feature or request
Is your feature request related to a problem? Please describe.
If I'm deploying the API server onto a container in a k8s cluster for example, then I don't have the means to manually install the plugin packages prior to launching the API server so being able to specify the packages in the configuration file is just not enough to have a fully reusable API server container that doesn't need to be forked every time someone wants to add their own plugins that are not already dependencies in the package.json of the
@hyperledger/cactus-cmd-api-server
package itself.Describe the solution you'd like
Use npm as a dependency of the API server and install packages of plugins prior to trying to importing them.
Describe alternatives you've considered
There's a bunch of libraries out there also doing something similar, but I'd rather just keep it lean by depending on npm itself which - in a way - is already a dependency of the project anyway.
Another one I thought about is to just run shell commands so that whatever npm is installed globally gets used, but I also rejected this idea because then we lose control over what version of npm we are using to some extend and this can result in flaky tests in the future.
The downside of course is that pulling in npm as a dependency will probably blow up the package size significantly, but it is what it is, vendoring vs juggling deps on OS level will probably remain a debated question forever but nowadays vendoring seems definitely more well-liked if you just look at go and rust for example.
Additional context
The necessity of this feature became obvious very quickly once I started working on #540 and expect more issues like this to pop up as well.
This will also come handy for pluggable authentication so I added to that epic.
cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @jagpreetsinghsasan
The text was updated successfully, but these errors were encountered: