http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7804 --- Comment #27 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- (In reply to comment #26)
I've been thinking about this issue all night. I can understand your motivations and thinking behind the necessity of using Module::Load::Conditional. Could you describe the changes that would need to be made in order to implement it correctly? Here is the current workflow:
1) A plugin is uploaded to the plugins directory. This will be unchanged, except the plugins directory wouldn't be +Exec, or even
2) The plugins.ini is parsed, this tells which which about the starting file only. There are two options here. For option 1, this would work basically the same,
Let's assume that we're going to be handling a reports plugin called "CoolStuff". I'm going to describe the workflow using Module::Load::Conditional. Everything could be done with just Module::Load, but that would require more work. directly accessible via Apache. though the exact meaning of of the "start" parameter would change slightly. Option 2 might be better though. In this case, we don't actually need the start parameter at all, because we require a consistent Perl interface, so our plugin implements Koha::Plugin::CoolStuff::Dispatcher, and the plugin manager knows that we always start with the dispatcher. I'm going to assume we're going with option 2 because it's easier to implement.
3) Koha gives a link to the plugin starting file. This is where things start *really* changing. Koha gives a link to /plugin/run_report.pl?plugin=CoolStuff, and when run_report.pl is called, it uses Module::Load::Conditional to load Koha::Plugin::CoolStuff::Main, and create my $plugin = Koha::Plugin::CoolStuff::Main->new()
4) The file is executed, is authenticates itself, and loads its template files independently of the internal Koha templating system ( TT is used for templates only because we can be sure TT is available, and also it is simply better than other templating systems, though a plugin could just as easily output html from the perl file or use HTML::Template ). Rather than executing the file directly, /plugin/run_report.pl runs
5) At this point, control is passed completely to the plugin, which is responsible for any subsequent perl file execution.
Step 5 is where things will definitely change. As it stands, step 4 can be modified to use M:L:C easily, but step 5, not so much. I think step 5 will involve the plugin itself calling M:L:C via Koha::Plugins to continue its execution. Yeah, I think this would be the easiest way to deal with things. The plugin will extend Koha::Plugin::Report (and if a plugin implemented both a Report and a Tool, it could extend Koha::Plugin::Tool, too) but use Koha::Plugin::Host, so
[this is where initialization code could get called] plugin->run_report(). This means that the plugin author doesn't have to worry about authentication. If it's required, it's already been done by the plugin host. The best way to handle non-Perl resources would be to have everything pulled from /plugin/resource.pl?plugin=CoolStuff&resource=image.png [and a TT plugin could make translating "image.png" to "/plugin/resource.pl?plugin=CoolStuff&resource=image.png" invisible to the user... this step would be optional, but it'd be a lot easier to manage things this way] that it could do something like my $cooler = Koha::Plugin::Host->load('CoolStuff', 'CoolerClass'); Then it makes use of $cooler in whatever way is necessary to implement the report functionality. For simple plugins, everything could be implemented in Koha::Plugin::CoolStuff::Main, and there wouldn't be any need for using Koha::Plugin::Host->load() from within the plugin. For fiendishly complex plugins, you could have a massive number of classes.
If you could describe the workflow necessary for implementing M:L:C, it would help me out greatly.
Does this help clarify? In response to your question about how using M:L:C would reduce security issues, there is obviously no way to prevent someone installing dangerous code, but by using M:L:C we close a few of the easiest vectors and make it so that bugs in a plugin are less likely to give an attacker complete access to the server. -- You are receiving this mail because: You are watching all bug changes.