Administrators should be able to prevent Koha web users from uploading/installing/uninstalling Koha plugins, and instead allow uploading/installing/uninstalling Koha plugins on the server-side from the CLI. This would allow Koha web users to "use" plugins, but it would require plugins to be vetted and managed by a server sysadmin. This should improve stability and maintainability.
Created attachment 106651 [details] [review] Bug 25672: use enable_plugin_browser_upload flag to control plugin upload This patch adds a enable_plugin_browser_upload flag to koha-conf.xml, which controls whether or not Koha intranet users can upload Koha plugins via their browser. Like "enable_plugins", it defaults to 0 for new installs. This is useful when you want to provide Koha intranet users with plugins that are pre-installed by administrators (by CLI) or restricting them to plugins from a Github repo. See the following for more information: Bug 23975 - Add ability to search and install plugins from GitHub Bug 23191 - Administrators should be able to install plugins from the command line To test: 1) Apply the patch 2) Set <enable_plugins>1</enable_plugins> in koha-conf.xml 3) Add <enable_plugin_browser_upload>0</enable_plugin_browser_upload> in koha-conf.xml 4) restart_all (in koha-testing-docker) 5) Go to /cgi-bin/koha/plugins/plugins-home.pl and note that you don't see an option to upload plugins 6) Go to /cgi-bin/koha/plugins/plugins-upload.pl and note that it says "Plugin browser upload disabled!" and gives instructions on how to enable browser upload
Looks good, but the default should be to allow plugin uploads to keep in line with current behavior.
(In reply to Kyle M Hall from comment #2) > Looks good, but the default should be to allow plugin uploads to keep in > line with current behavior. Agreed. I was thinking about that late last night and early this morning. While enable_plugins is 0 by default, all the in-Koha documentation says they just need to change it to enable_plugins 1. If they did that, and enable_plugin_browser_upload is 0, they won't even know they need to enable it. So I'll do a follow-up to enable it by default.
Created attachment 106671 [details] [review] Bug 25672: Enable enable_plugin_browser_upload by default This patch enables enable_plugin_browser_upload by default, since the current behaviour for Koha is to enable browser upload when enable_plugins is 1.
Created attachment 106673 [details] [review] Bug 25672: use enable_plugin_browser_upload flag to control plugin upload This patch adds a enable_plugin_browser_upload flag to koha-conf.xml, which controls whether or not Koha intranet users can upload Koha plugins via their browser. Like "enable_plugins", it defaults to 0 for new installs. This is useful when you want to provide Koha intranet users with plugins that are pre-installed by administrators (by CLI) or restricting them to plugins from a Github repo. See the following for more information: Bug 23975 - Add ability to search and install plugins from GitHub Bug 23191 - Administrators should be able to install plugins from the command line To test: 1) Apply the patch 2) Set <enable_plugins>1</enable_plugins> in koha-conf.xml 3) Add <enable_plugin_browser_upload>0</enable_plugin_browser_upload> in koha-conf.xml 4) restart_all (in koha-testing-docker) 5) Go to /cgi-bin/koha/plugins/plugins-home.pl and note that you don't see an option to upload plugins 6) Go to /cgi-bin/koha/plugins/plugins-upload.pl and note that it says "Plugin browser upload disabled!" and gives instructions on how to enable browser upload Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Created attachment 106674 [details] [review] Bug 25672: Enable enable_plugin_browser_upload by default This patch enables enable_plugin_browser_upload by default, since the current behaviour for Koha is to enable browser upload when enable_plugins is 1. Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
I like this. We at biblibre have our CLI script one can find there : https://git.biblibre.com/biblibre/tools/src/branch/master/koha/plugin.sh Note that you must flush memcached then reload starman : reload config and then recompile perl
(In reply to Fridolin SOMERS from comment #7) > I like this. > > We at biblibre have our CLI script one can find there : > https://git.biblibre.com/biblibre/tools/src/branch/master/koha/plugin.sh > That's cool! You should check out Bug 25671 where I'm writing a CLI tool for Koha. It's actually mostly done I think but I haven't uploaded the code yet, and I've had too many other tasks lately taking my attention. > Note that you must flush memcached then reload starman : reload config and > then recompile perl Mmm I forgot about that. I haven't had to that in my dev environment, but I think Starman might auto redeploy in dev...I should keep that in mind.
Created attachment 107172 [details] [review] Bug 25672: use enable_plugin_browser_upload flag to control plugin upload This patch adds a enable_plugin_browser_upload flag to koha-conf.xml, which controls whether or not Koha intranet users can upload Koha plugins via their browser. Like "enable_plugins", it defaults to 0 for new installs. This is useful when you want to provide Koha intranet users with plugins that are pre-installed by administrators (by CLI) or restricting them to plugins from a Github repo. See the following for more information: Bug 23975 - Add ability to search and install plugins from GitHub Bug 23191 - Administrators should be able to install plugins from the command line To test: 1) Apply the patch 2) Set <enable_plugins>1</enable_plugins> in koha-conf.xml 3) Add <enable_plugin_browser_upload>0</enable_plugin_browser_upload> in koha-conf.xml 4) restart_all (in koha-testing-docker) 5) Go to /cgi-bin/koha/plugins/plugins-home.pl and note that you don't see an option to upload plugins 6) Go to /cgi-bin/koha/plugins/plugins-upload.pl and note that it says "Plugin browser upload disabled!" and gives instructions on how to enable browser upload Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 107173 [details] [review] Bug 25672: Enable enable_plugin_browser_upload by default This patch enables enable_plugin_browser_upload by default, since the current behaviour for Koha is to enable browser upload when enable_plugins is 1. Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Works well and adds to plugin system security.. no regressions found, passes the QA scripts and no obvious code issues. Passing QA
Created attachment 107174 [details] [review] Bug 25672: (QA follow-up) Hide install after search button If plugin upload is disabled, but there are git repositories listed in the config for plugin searching, then you can search for a plugin and attempt to install it. The install leads to an error page. This patch removes the actions column and install button should the enable_browser_upload option be disabled Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Oops. forgot to attach my QA follow-up first time around.. it just hides the install button if you happen to have your system configured for no uploads but still allow searching for plugins via the UI.
(In reply to Martin Renvoize from comment #13) > Oops. forgot to attach my QA follow-up first time around.. it just hides the > install button if you happen to have your system configured for no uploads > but still allow searching for plugins via the UI. Firstly, thanks so much for QAing this, Martin! Really appreciated! Secondly, that's an interesting follow-up! I actually intended to let people install plugins from configured Git repos but just disable plugin file upload via their local browser. If I read your patch correctly, they wouldn't be able to do that with the follow-up, right? I don't mind either way, but I wonder if people should be able to search Git repos but not upload files via the browser?
We cannot upload but uninstall, is that ok?
(In reply to David Cook from comment #14) > (In reply to Martin Renvoize from comment #13) > > Oops. forgot to attach my QA follow-up first time around.. it just hides the > > install button if you happen to have your system configured for no uploads > > but still allow searching for plugins via the UI. > > Firstly, thanks so much for QAing this, Martin! Really appreciated! > > Secondly, that's an interesting follow-up! > > I actually intended to let people install plugins from configured Git repos > but just disable plugin file upload via their local browser. Ah, if that was your intentention, I don't believe it worked. I'm sure I tested it during QA and as expected, it failed at the plugin upload stage so I disabled the button as a follow-up. Hmm, maybe this needs a minor revisit then to clarify the case.
(In reply to Jonathan Druart from comment #15) > We cannot upload but uninstall, is that ok? Good catch, we should probably disallow that too here.
Removing from the PQA queue regarding the last comments.
(In reply to Jonathan Druart from comment #15) > We cannot upload but uninstall, is that ok? That's a good question. I was thinking that it was OK for them to uninstall them, but I suppose that could be annoying for vendors/administrators... But then plugins installed via Github should be able to be deleted. We don't want to remove the "uninstall" option for all plugins just because we're not letting them upload plugins via the browser. But then if we also block Github installs as well as browser upload/install, then that would be a bit of a moot point. (Although at some point I'm planning to create a plugin for managing plugins from external sources. Prosentient could have a plugin for downloading/installing Prosentient approved plugins, Bywater could have a plugin for downloading/installing Bywater approved plugins, etc.)
(In reply to Martin Renvoize from comment #16) > Ah, if that was your intentention, I don't believe it worked. I'm sure I > tested it during QA and as expected, it failed at the plugin upload stage so > I disabled the button as a follow-up. Hmm, maybe this needs a minor revisit > then to clarify the case. That's good to know! I thought that I'd tested it, but I was working pretty fast and furious at one stage. I'll have to review it.
David, any updates on this? :)
(In reply to Joonas Kylmälä from comment #21) > David, any updates on this? :) Ooops. Missed the email notification. While I still have an interest in plugins, we just don't use them enough to justify me working on them during my job hours. And outside my job I have so few hours available and those I'm putting towards authentication/Mojolicious controller things. So I'll abdicate as assignee.